Domain 3 Legal - Bankruptcy

[xhee...@googlemail.com]

Concerning Bankruptcy of the Cloud or SAAS provider. An idea we have
is to mitigate this risk by having the SAAS service put under a
different legal entity like for instance a foundation. We would obtain
the service from the foundation and the SAAS provider would put the
service under the foundation.
In case of bankruptcy of the SAAS provider the foundation would be
banktrupt and we could still access data.

Does any body have experience with setting up a foundation ?
What are the legal and other consequences of this solution ?

[xhee...@googlemail.com]

The risk we want to mitigate is that we can't access our data and
setup our own or another hosting platform with the valuable data
assets we build up over time. The source code and executable code we
can cover with Escrow. Regualrly downloading the data woudl defat the
SAAS purpose.

On 7 jul, 11:32, "xheem...@googlemail.com" <xheem...@googlemail.com>
wrote:

[James Blake]

You can also provide service escrow, contigences are made for a third-
party to continue to run the service in the event of insolvency - at
least long enough for data to be exported.

The issue is that for some types of service is, while you can export
the data, you can't easily export a workflow if the business logic is
tied to the platform.

Regards

James

--
Sent from the mobile device of James Blake

On 8 Jul 2009, at 15:31, "xhee...@googlemail.com" <xhee...@googlemail.com

[Bruce Durling]

2009/7/8 James Blake <jimmy...@gmail.com>:

>
> You can also provide service escrow, contigences are made for a third-
> party to continue to run the service in the event of insolvency - at
> least long enough for data to be exported.
>
> The issue is that for some types of service is, while you can export
> the data, you can't easily export a workflow if the business logic is
> tied to the platform.

Free Software and (some) Open Source licenses would also be an
alternative to escrow. You'd have to find someone else to perform the
service (running the servers, dealing with bugs, etc), but at least
you'd have the data and the logic to process it.

cheers,
Bruce

[James Blake]

This is not aimed as an open source vs proprietary response but more
as a open source commodity vs integrated/adapted open source.

The issue with supplying a service purely based on unadapted open-
source would be differentiation.

All compatible suppliers would, for all intents and purposes, only be
able to offer the same service leaving price as the only
differentiator. Paring price down to the bone for all but commodity
services would lead to more insolvencies in service providers as the
market matures. This is further compounded by the low barrier of
entry for new service providers as there is no/little IP to develop,
further increasing commercial pressures.

If the service provider is extending the open source platform however,
then the data formats and business logic could remain tied to the
platform due to subtleties in the implementation. The new service
provider importing the data would have needed to have integrated or
extended the open source components in exactly the same way to be
compatible.

We have open source components in our platform (along with a majority
proprietary code and a few OEMed components), but they are heavily
extended to provide differentiation from the other players in our space.

Regards


James

--
Sent from the mobile device of James Blake

[Bruce Durling]

James,

You raise some interesting points about commodity software that I agree with.

I'm not talking about unadapted open source either. The adapted or
original code could be provided under an open source license as well.
The differentiator would be customer service, uptime, community mind
share. You could still charge for the service. There are licenses
(such as the Affero GPL) that would mean that anyone taking your code
and modifying it would also have to release their changes which could
then be incorporated back into your code.

Lots of software that seemed to be immune to commoditisation
eventually succumbed to it. People are still willing to pay for good
execution though. I'm not saying that going with an Affero GPL license
is correct for all situations but it is an alternative that solves the
issue of client security against a supplier going bankrupt.

I would be happier to see that as an end user as well. I would prefer
there to be a community around the services I use. Code in an escrow
service could be brittle and hard to maintain and I wouldn't know it.
FLOSS code could be inspected and I would know if other people
understood it.

cheers,
Bruce

2009/7/8 James Blake <jimmy...@gmail.com>:

[Khürt Williams]

Should this issue be framed more in terms of Business Continuity
Planning or Data/Service Portability?

On Jul 8, 12:49 pm, Bruce Durling <bruce.durl...@gmail.com> wrote:
> James,
>
> You raise some interesting points about commodity software that I agree with.
>
> I'm not talking about unadapted open source either. The adapted or
> original code could be provided under an open source license as well.
> The differentiator would be customer service, uptime, community mind
> share. You could still charge for the service. There are licenses
> (such as the Affero GPL) that would mean that anyone taking your code
> and modifying it would also have to release their changes which could
> then be incorporated back into your code.
>
> Lots of software that seemed to be immune to commoditisation
> eventually succumbed to it. People are still willing to pay for good
> execution though. I'm not saying that going with an Affero GPL license
> is correct for all situations but it is an alternative that solves the
> issue of client security against a supplier going bankrupt.
>
> I would be happier to see that as an end user as well. I would prefer
> there to be a community around the services I use. Code in an escrow
> service could be brittle and hard to maintain and I wouldn't know it.
> FLOSS code could be inspected and I would know if other people
> understood it.
>
> cheers,
> Bruce
>

> 2009/7/8 James Blake <jimmybl...@gmail.com>:

>
>
>
>
>
> > This is not aimed as an open source vs proprietary response but more
> > as a open source commodity vs integrated/adapted open source.
>
> > The issue with supplying a service purely based on unadapted open-
> > source would be differentiation.
>
> > All compatible suppliers would, for all intents and purposes, only be
> > able to offer the same service leaving price as the only
> > differentiator.  Paring price down to the bone for all but commodity
> > services would lead to more insolvencies in service providers as the
> > market matures.  This is further compounded by the low barrier of
> > entry for new service providers as there is no/little IP to develop,
> > further increasing commercial pressures.
>
> > If the service provider is extending the open source platform however,
> > then the data formats and business logic could remain tied to the
> > platform due to subtleties in the implementation.  The new service
> > provider importing the data would have needed to have integrated or
> > extended the open source components in exactly the same way to be
> > compatible.
>
> > We have open source components in our platform (along with a majority
> > proprietary code and a few OEMed components), but they are heavily
> > extended to provide differentiation from the other players in our space.
>
> > Regards
>
> > James
>
> > --
> > Sent from the mobile device of James Blake
>

> > On 8 Jul 2009, at 16:19, Bruce Durling <bruce.durl...@gmail.com> wrote:
>
> >> 2009/7/8 James Blake <jimmybl...@gmail.com>:

[xhee...@googlemail.com]

Should be BCP.

> > >> you'd have the data and the logic to process it.- Hide quoted text -
>
> - Show quoted text -

[xhee...@googlemail.com]

There are in deed companies providing SAAS Escrow, Technically they
are delivering insurance that will take over the hosting liabilities
when the SAAS provider goes banktrupt.

On Jul 10, 3:16 pm, Khürt Williams <khurtwilli...@gmail.com> wrote: