Re: Please let's not talk about "clouds"
On 04/22/2013 11:46 PM, Brian Gupta wrote:
> would love to discuss this further.
Me as well! Freedom on the cloud isn't easy to understand fully for me
as well.
> As I don't believe your definition of SaaS fits either the definition
> that Richard has an issue with, or the general definition used by the
> industry as a whole. It is my understanding that a SaaS service
> completely abstracts away the underlying software, such to the point,
> that the users of such a service have no control or real influence
> over the underlying software (whether built on Free Software or not.)
I believe you are under the influence of seeing too much use of Google
docs and such type of software.
How would you see it if you had the source code of Google Docs to keep
on that example, and if you were able to run a copy on your own servers?
Sure, you would still not have the control over what runs at google, but
you could at anytime opt out and run your own service. I think that's
key here.
Also, the fact that it is practically impossible to check what is
running on the provider infrastructure is problematic. But so it is for
IaaS, PaaS and other types of clouds.
> In the case of Debian's infrastructure, even if an individual does not
> have administrative access to one of these services, they can talk to
> the admins, influencing the service, and even may, if they have the
> project's trust, combined with the ability and interest, gain
> administrative rights. (Depending on the service, this bar may be
> higher or lower than others.)
In the case of Debian, you can download what makes packages.debian.org
and set it up for your own derivative. I think that's even more
important than being able to access what is running/hosted, which IMHO
is impractical.
> In my mind (and presumably Richard's) SaaS is really about a lack of
> *control* over the application, and your own data, in exchange for
> divesting oneself of the responsibility of managing and developing
> said application and data.
I believe things are a bit more complicated than just that.
Let's make a dream for 5 minutes... Let's say you had a Google Docs
version that would always save the documents into an RTF format (which
is free, open and standard) on your local computer (eg: not on the
server at all). This would still fit the definition of SaaS (Software As
A Service), though you would have control over your data. If on top of
that, we had the source code of what was running on the server, and
released under a reasonable license, then what would be the problem
exactly? None for me. If the service goes away, or I'm happy with it, I
can set it up on my own server if I wish to. Data would be interoperable
as well.
Though, we all know what I described above isn't what is currently
happening. This is what gives the (IMO false) impression that all SaaS
is evil. Both types of implementation (free and non-free) really are
possible.
> Perhaps, following your line of logic, the one exception to this might
> be a SaaS provider that does not own the copyright to the software
> they are providing as a service and that software has been released
> under the aGPL. I would consider this a SaaS offering, but perhaps one
> that I don't feel challenges Debian's values. (It's tricky as one
> still potentially loses control of one's data, and one still has to
> trust that the organization will follow the terms of the aGPL, so the
> question of trust really comes into play.)
Exactly. Very tricky indeed, and you need to have trust in the
organization which provides the service. Though that's truth for every
hosted/online services you may register with.
This isn't specific only with SaaS, though such kind of evilness has
been spreading around and is now fully part of the most popular sites (I
don't think I need to list them... we all know where my finger points
at). It is also probably more easy to implement evilness with SaaS,
which is why we should care more when using it.
To sum-up: it would be very confusing and dangerous to point out that a
technique is evil. It is not. It is its non-free implementation that is.
> P.S. - If anyone hasn't read the NIST doc, please consider doing so.
>
> [1] - http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
Having a rapid look, they seem indeed quite accurate (and more concise
than what I tried to explain).
Thomas
Reply to: