social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Social-discuss] Re: Freedom in the Cloud - Defining the


From: Orton AKINCI aka .-_-.
Subject: [Social-discuss] Re: Freedom in the Cloud - Defining the
Date: Thu, 13 May 2010 05:37:30 -0700 (PDT)

is a "p2p cloud" possible? Serivce running on peer computers...

.another internet is possible!_
http://www.nettime.org/Lists-Archives/nettime-l-1005/msg00002.html


.-_-.

http://httpdot.net/.-_-./



Message: 1
Date: Wed, 12 May 2010 12:13:17 -0700
From: David Sterry <address@hidden>
Subject: [Social-discuss] Fwd: Freedom in the Cloud - Defining the
    Freedom    to Migrate
To: social-discuss <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hello GNU Social mailing list. I just joined after reading about
Diaspora but I've been thinking about freedom online, the AGPL. and the
four freedoms there for a while. In any case, I wrote this which I hope
is helpful to point out from a fundamental perspective how freedom
online requires a different approach than on our own desktops and
servers. I look forward to your comments...

Software freedom is being able to choose and customize the software you use
without limit. In a world filled with network applications, software
freedom
also requires that we can choose the host of our network applications.
For a
user to have that choice they must have access to a full export of their
account and the configuration settings necessary to setup the
application on
another host.

The Free Software Foundation has addressed the four freedoms [1] in the
network context with the GNU Affero General Public License [2] but freedom
for users of network services requires a fifth, broader freedom: the
freedom
to migrate.

*Convenience at a price*

Not since the printing press has society been faced with a technology as
useful and therefore important as the network application.
Internet-connected
applications can be accessed instantly from myriad devices around the
world.
Users are able to ignore development, maintenance, and administration of
network applications as well as the resources required(servers,
electricity)
to run the application. For the purely practical user, this arrangement is
ideal. They can use the application with a minimum of operational overhead
and cost.

For the user who values their freedom, however, network applications can be
disasterous. The original four freedoms may exist in degrees ranging from
none with a proprietary, tightly-controlled network application to all with
an application licensed under a network-oriented free software license like
the Affero General Public License(AGPL). A network application may store
user
data, configuration settings, and may have connections with other systems
that can lock the user into the host of the application.

Since the program runs on a remote computer, there is no binary to examine,
no data files to decipher and no internal network traffic to analyze.
Without
the four freedoms in addition to full export of account information and
configuration settings, it is impossible to have freedom while using a
network application.

*Requirements for Freedom*

To have freedom, a user must be free to switch to another host without
losing
data or functionality. This requires a user be assured the four freedoms
and
have access to at least the following:

1. The user must be able to export any data required to operate their
account
on another system. This would include both the public and private data
about
their account that affects their utility and experience with the
application.
For example, profile information, internal messages, notes, conversations,
uploaded files, credentials to access other systems, and settings they have
customized in the application should all be available in the export. To
support this feature continuously during development, import and export of
each bit of data should be functional before the data is used by the
application.

2. Some applications create relationships between accounts such as friend,
group membership, and administrative hierarchies. These relationships
should
continue to work even when accounts are served by independent hosts. If
relationships break due to account migrations, a facility to reconnect them
should exist that is robust enough to reconnect multiple accounts moving to
their own instances. To guard against a single point of failure, such a
facility should not rely on a centralized directory.

3. Finally, networked applications often have settings that have affect the
way a particular instance of the application works. It should be
possible to
export that configuration data to any user of the system.

4. Some network applications connect to other network applications by means
of an API. For an application to have the freedom to migrate, any API
providers used by the system must also give the user the freedom to
migrate.

The above requirements represent a first attempt to secure user freedom
against the lock-in possible with a network application. As an ethical
society, we must choose and build systems that respect user freedom and
offer
the freedom to migrate. There are many free network applications licensed
under the AGPL that can be enhanced with the freedom to migrate. Other,
non-free applications must be rejected and replaced if users are to
maintain
and extend freedom into network applications.

Further reading:

GPL's Cloudy Future [3]

Eben Moglen Interview [4]

Diaspora [5]

[1] http://www.gnu.org/philosophy/free-sw.html
[2] http://www.gnu.org/licenses/agpl-3.0.html
[3] http://www.zdnet.com/blog/btl/gpls-cloudy-future/15855
[4]
http://www.h-online.com/open/features/Interview-Eben-Moglen-Freedom-vs-the-Cloud-Log-955421.html

[5] http://joindiaspora.com

This artcle is available online at http://trygnulinux.com/action/?q=node/69
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nongnu.org/archive/html/social-discuss/attachments/20100512/c55a314e/attachment.html

**************


reply via email to

[Prev in Thread] Current Thread [Next in Thread]