Network services/Meeting notes

Agenda

1. Introductions - Who are we and why are we here?
2. Sharing Utopian Visions - "We'll know we've succeeded when..."
3. Review of reference service list - What are our thoughts and intuitions?
4. Problems: What's between us and our visions becoming real? What was wrong with the reference services we previously outlined?
5. Review of suggested approaches: General thoughts on shortcomings and benefits?
6. Personal or group recommendations: What should we do? What can or should the FSF do?
7. What should this group do moving forward?

Attendees

• Aaron Swartz: open library, reddit, web standards like RSS
• Kragen Sitaker: been thinking about these issues for some time (especially thinking about decentralized services
• Bradley Kuhn: former executive director of the FSF, currently president of Software Freedom Conservancy, focusing on the software side of the issue and authored original AGPL clause
• Brett Smith: FSF licensing guy working on this issues from within the FSF
• Mike Linksvayer: Creative Commons likes decentralized services and is interested in helping out with any content component
• Henri Poole: FSF Board Member who has been having this conversation with RMS for many years and who pioneered the AGPL
• Benjamin Mako Hill: FSF Board Member who handled some AGPL and network service related issues in the GPLv3 and AGPLv3 drafting process
• Luis Villa: protolaywer interested in this and finding out the best way to be both a lawyer and a free software advocate. has worked on some of these issues at Red Hat in relation to MugShot [1]
• Gabriel Burt: works at Novell seriously interested in this issue after talking about this issue in GUADEC
• James Vasile: SFLC lawyer thinking and speaking and writing about this issue. works with a series of webservice company (His clients include: Joomla, Drupal, etc.)
• Evan Prodromou: Debianista, CC participant, software developer, Free Web service entrepreneur (Wikitravel, Vinismo, Keiki)

Visions of Utopia

Kragen's short answer: when people have the same assurance of freedom and autonomy when they're using networked social s/w that they currently have when they use local software, then [we've won]?

luis likes the word autonomy; his idea is very similar. We want to let people self-direct and choose their own outcomes like they do currently with free software.

Poole: People who use these systems should have the werewithal (maybe not education) to make sure that it works the way they expect. They should be able to look at it. If you create something, having the ability to continue to work on that is a big deal.

Kragen asks if Henri is focused more on developer (as opposed to the user) point of view....

secure global and memorable (all at once)

Mike: Increase in user autonomy and understanding where autonomy is coming from.

 Web services are now much easier in many classes for users, in a non-ethical sense.  Gmail is easier than standard mail clients, don't need to worry about installing, don't need to configure it, etc.  What if there could be a similarly large jump to go along with that increasing usability?  Just as easy to migrate your data, your computation, etc. to places you control.  It'd be nice if it was just as easy to use that as use Gmail.
 

Brett: there are multiple ways we can move forward. Alternative technological develompent just as valuable as legal frameworks?

Mako: f.s. (in my view) is about control by people who use it. When used by groups, technology should be controlled by groups in ways that are democratic.

Bkuhn: This issue is fundamentally broader than any scope of licensing for Free Software.

This issue is fundamentally broader than any scope of licensing for software and content previously considered. For example, It's trivial to look at a company that does mostly Free Software work and use a clear litmus test on "how Free" the work is they're doing. RMS himself didn't have clear positions on this for may years.

I therefore think we should be careful about setting the goals of this committee as endorsements or final publicatcions of single guidelines. Our own history on the narrower problem of software freedom has shown us that even the philosophers of software freedom took time to reach the conclusions we take as perfectly for granted now.

Kragen: Mako's desire for communitarian view of software freedom is not as easy to find metrics for as individual freedom. Oppressed groups may want access to information that the larger group doesn't, i.e., queers in Iran. Mako agrees.

James: We've always looked to control of the physical platform as a shortcut to control over a series of values. Now that we're losing that shortcut, we need to disaggregate those values. In my utopian dream, these values are protected with very little overhead or user initiative.

These values are largely (but not perfectly) orthogonal, and I'd like to pursue solutions to each of these separately, with different tools, leverage and policies for each. There will be places to cooperate, of course, and we should merge it all later.

Mako: Meta-utopia: likes Kragen's pendulum of de/centralization, and wants a view of freedom that doesn't depend on where we are on the pendulum. James agrees.

Luis: Traditional free software freedoms are no longer working for us because we took data locality, transparent identity proxies for granted. No longer the case, so we're faced with this situation.

techniques and issues

Kragen: Specific technical techniques that can get us closer to this utopia:

• decentralized data storage -- exists but slightly immature.
• distributed computation
• maximize control of thigns that aren't particularly user specific
• give group control over things that affect everyone (at the moment,this is mostly done through social convention and that was part of the original free software vision but it might be nice to have more formal democratic structures built into the software
• cryptography in general can facilitate a whole bunch of different types of private competition without making a large number demands on the underlying social system

Current services and how they rate

Wikipedia

Data and software are freely available. How are APIs licensed?

• users have very little individual autonomy in the context of wikipedia (you can't reorganize things unless "the community" agrees
• many of the images are itself not free and cannot be downloaded in total (this is a technical issue -- even text hasn't been available for the past year because exporting the data takes three weeks). To what extent is technical failure in implementation a freedom problem?
• wikipedia doesn't do as good a job as it should or it could
• users of wikipedia can't add things to the site or change things
• people can't take their reputation with them and move it there: if you moev to a different place, it's hard to link your edits on wikipedia to the things you've done in a different place

Kragen says these issues are created by centralized nature of WP. There's an opportunity to charge rent. Providing dumps is not a priority because it's not the normal way of using the site.

But decentralization has its own costs.

Some of the obstacles here are purely technical. Wikimedia sometimes has trouble running normal Wikipedia. This is why Kragen wants to focus on technical aspects.

Sometimes it's hard to know exactly why any service provider isn't providing a certain service: technical difficulty, financial incentive, just not a priority, etc. Mako says it's okay to impose inconvenience (freedom standards) if it's worth it for the community, but of course deciding that is hard.

Geonames

http://www.geonames.org/

Mostly a data server for geographical names. All data available under the CC Attribution license, version 2.x. Unknown whether the software is Free.

Hostip.info

skipped until someone knows those

GMail

Server software is proprietary (but we assume it is based at least in part on some free libraries) Data is available via free protocols (imap and pop) You can send with SMTP -- you can use GMail as your e-mail provider without using their web client at all You can relay data through GMail as well. Contacts data is exportable.

Unlike HOTMAIL and Yahoo, it runs mostly on the client side (via JavaScript) that allows you to customize the way it works in deeper ways (i.e., with greasemonkey and similar systems) that you can with previous system. To a large extent gmail is already a distributed application but it is set up so that all of hte code can be compromised by Google.

Kragen: In that sense, a Gmail has been a step forward in practical software freedom and many people have been distributing modified releases and Google is sending an XML object that it can manipulate.

15:21 <@AaronSw> I want to qualify Kragen's praise of Gmail -- Google controls

                the API in such a way that their particular interface style is 
                fairly tightly coupled to the server

15:22 < luisv> agreed

James: People talk about having privacy from Google. When you use Gmail you give up privacy google but what you get is privacy from their employeer or institution. Google might sell your marketing data but your boss is might fire you for using your email for disapprovedb purposes.

Luis: Their underlying OS is highly customized GNU/Linux; Google engineers swear that the source is not really usable to people in the outside world without that OS. If we assume there are thousands of man-years invested in the difference, how valuable would a source release be? Traditionally we assume we have a copy of the OS.

Things Gmail is doing right:

• object code is semi-distributed -- the JavaScript is compiled
• modification of the client code itself, which is quite clunky
• some identity portability (if you want it and are willing to put in some work)
• they use a standard api

Sets of wrongs:

• access to code might not give us much because the OS itself is not something that we have access to
• there is some data that is in there that is hard to get out (some of things that the address book can getout)
• arbitrary account cancellations (your account may be cancelled at any time and its hard to fine out why)
• security problems that allow people to get into your account and change your password
• it was rumored that google was crawling urls
  • the above is a rumor and we don't know whether or not it's true -- this reflects an accountability problem
• javascript client code is obfuscated

eBay

Reputation and identity are tied to the platform.

you can take your name out

how could a group move out of ebay?

ebay's south american operation has much stricter control over one's identity. attempts to block transactions outside the system to block use

No code released, lots of restrictions on user actions, user communication.

How could we replicate this service in a free sense? Especially in a world where there's a lot of network effects behind eBay. You can sell your stuff on your own site but it's a lot harder to get buyers. This even influences the market -- prices tend to be better on eBay because there are more sellers, etc. eBay interacts with PayPal, which gives them a lot of competitive advantages.

Network effect gives a huge benefit.

Could you have a free alternative: there are issues of financial services; credit card services and such requires a high degree of trust which is based on a high degree of control

LiveJournal

LiveJournal was the blog before blogging was popular. Much of their code is released under the GPL. Small groups of users have been frusterated with governance and forked (e.g., dead journal). You can export all of your posts but it's not possible to export comments.

If you are a talented enough programmer, you can mirror everything including all of your comments. However, because that is not an easy to use application it is a technology have/have-not applications. (Luis and James argue that this part of it must/might be out of scope for the goals of this committee)

• you can't take your social network with you (no ability to export relationships)
• Changing terms of service over time, even after promises to the contrary exacerbates the problem.

 however, it is possible to compete with livejournal because we have the code and are able to do it
 there are documented cases of the livejournal account changing
 there are also issues of dead livejournal users or just people who have moved on
 

Second Life

kragen:

• unlike most other network services: they declare that you own everything that you make in the service
• they sell virtual land in second life that you can continue to use without continuing to pay them (except for the monthly fee)
• they are trying to turn second life into a decentralized service (they want to be able to put land on different servers around the net which is part of their strategy to ensure that their users have the types of freedom that we are used to in free software)
• they promised to let users sell copies of scripts, textures, etc. without letting other users copy those -- but now that's technically impossible with a free software client

Mako: one big diff. b/w SL and other things: people own land. It's basically theirs. It's easier to say "You have your own server where you have control." Analogs to more traditional forms of property make the libertarian position more feasible. But managing the community spaces is harder. (I'm having trouble here; mako should flesh this out.) If people don't like your island it may be possible to move it to a different server (at least in the future) -- while still interacting with your old friends, etc.

Mako: If SL succeeds in all their wildest dreams, are we free?

Kragen: Person who owns your rack can spy on it, etc. (Kragen should flesh this out too.)

Savannah/SourceForge

Mako: There are particular problems with using non-free services to develop free software. SF.net goes back and forth between releasing their code as free software. Currently it is not free. Savannah is based on a fork of previous SF.net code.

Luis: Savannah is interesting because all value there is communally owned in a peer sense. There are individual copyright holders, etc., but all the data is communally owned, if source is available, to what extent do I need to be able to copy everything practically?

Kragen: There was a security breach, services were unavailable, and that caused forks.

bkuhn: We had basic consensus on the GNU side to keep things down, but probably hurt the broader (hosted non-gnu projects) community as a consequence. We couldn't get things to them because of lack of resources. This is an inevitable consequence of a centralized service, even with the best of intentions. In centralized systems, the consequences of failure scale with the project, even when intentions were clear that a desire to export to the community in the right way existed.

OpenStreetMap

Service	personal data?	public/collaboratively-created data?	source code?	permanence?	identity?	comments?
Wikipedia	personal data?	public data?	source code?	permanence?	identity?	data and software are freely available. How are APIs licensed?
geonames.org	personal data?	public data?	source code?	permanence?	identity?	comments?
hostip.info	personal data?	public data?	source code?	permanence?	identity?	comments?
gmail	personal data?	public data?	source code?	permanence?	identity?	server source is proprietary, but all (email) data is available via standardized/open protocols, and users can make the service transparent (from an identity perspective) by using other email addresses.
ebay	personal data?	public data?	source code?	permanence?	identity?	comments?
Amazon EC2:	personal data?	public data?	source code?	permanence?	identity?	server images are ~ standard xen images. If you can move your data and computation transparently between S3 and completely Free xen-based servers, is it open/free/autonomous service?
GNU Savannah	personal data?	public data?	source code?	permanence?	identity?	comments?
Second Life	personal data?	public data?	source code?	permanence?	identity?	client is Free; service is not.
audioscrobbler/last.fm	personal data?	public data?	source code?	permanence?	identity?	comments?
altlaw.org:	personal data?	public data?	source code?	permanence?	identity?	comments?
chicagocrime.org (defunct, mashed up government data (free) with google maps (non-free)	personal data?	public data?	source code?	permanence?	identity?	what happens when you mash up Free data with non-free services like google maps?
OpenStreetMap	personal data?	public data?	source code?	permanence?	identity?	comments?

things we might do

 * a standing committee or something (perhaps endorsed/sponsored by FSF) that:
       ** publishes regular critiques of existing known web services, perhaps rating them on various axies (somewhat like the list Luis began putting together),
       ** a strong, ongoing campaign that:
            *** encourages improvements in network services that seem problematic to the committee
            *** fosters and inspires the release of new SaaS systems that are not only under licenses like AGPL but also have good user control features that would force default deployments to rate very well on whatever axies of freedom considerations we've developed.

Values

Henri notes: AGPL critics since we wrote it and promulgated have said "that's not freedom". Therefore, the values question is centeral. Technical issues should be figured out, and we need to know which ones to solve. Push forward both values and the software solution together.

Kragen: RMS's value is simply to stop anybody from dominating anybody else. Bradley: Seeing AGPLv3 and the values discussion move aside was disappointing in GPLv3 drafting process. Laying out values has been tried before and hasn't worked. James: GPL is victim of its own success. Community of GPL users include people who don't share our values, just doing it for the ecosystem. To what degree do they have a say? To what degree do we owe an obligation to them? Values discussion is necessary but will not solve problem of this technology reaching people who don't share our values. Bradley agrees that values discussion might not be helpful, but that we have to be careful that values don't get tossed aside either. Brett thinks the values metadiscussion might be the most fundamental issue we discuss.

Brett: What powers do we have to state our values?

Discussion of conflict that lead to AGPL/GPL split.

   Some people thought that AGPL was changing the rules in the middle.
   

Henri: underneath, what are the problems: transparency and empowerment Bradley agrees. We need to understand the concerns and be responsive to them. We need to articulate the case for web services freedom. Some discussion of the asp problem happened in 2002, but it fell off the table. (and it doesn't need to be codified in a values list, it can be less formalized than that as long as it's out there early and often).

Mike: Means of FSDef have "reverse-reified." We need to be practice and accept that "means" have become "values".

RMS defined harms, and then provided a solution out of them. That's why basing our discussion in concrete cases is helpful.

We might benefit from clear examples of problems and the harms associated with them, as well as a case for how our values address these harms.

List of Values We *May* Care About

Things we care about may not be worth enshrining in a document, recommendations, definitions, etc. We all care about kittens, but we won't be talking much about kittens today.

This list needs to be separated into two lists. One is values that are powerful because they are means to the ends. The ends are the separate list. Privacy/reliability/cultural transparency are likely ends. Mobility and transparency are likely means. There might be some overlap in these lists. [We are not attached to the means/ends terminology. Other terms we might use would be "first order" vs. "second order" values.]

Kragen: List of ends should stay constant. List of means may change substantially depending on where we are on the pendulum of de/centralization.

• Privacy (logging, keep data private unless given explicit permission; also controversial)
• Reliability (uptime, service meeting expectations)
  • Security/Cryptography -- not having your data stolen -- Mako: not convinced that's what we're talking about here
  • cancel accounts and for non-payment
  • availability of source (has an impact)
  • Freedom to keep using the service
• Data Ownership/Control
  • easy access to all data, in a format that's standard/documented and/or implemented in FOSS
• Freedom to leave
  • Mobility -- identity and data
  • "Data portability"/control/ownership (can you erase it after you leave?) http://www.dataportability.org/
    • Although a generic-sounding term, it's come to be a catchword for what we seem to be calling "mobility" here
• Freedom to modify the service
• Ability to keep using the service
• Transparency (lack of visibility leads to helping people see what's going on in the system) and may also let you see what's going -- also relates to the ability
  • Cultural transparency (company, organization, individual...? n/a if p2p, and what about anonymous services?)
    • Democratic control of the service
    • terms of service (and its longevity and assurances)
    • identity of entity controlling the service
  • Technical transparency
    • Disclosure of dependence on other services - no reliance on non-free services?
    • freedom to run the service
    • Licensing under something that permits forked versions of service
    • Business-model patents may come into play here
    • Copyleft for public access to data/API?

review of different approaches

agpl model

good at ensuring access to source code but bad at ensuring access to data (it says nothing about data)

bkuhn thinks AGPL gets unfairly disparaged because it's only a partial solution, and we should be careful not to do that. If an AGPL service doesn't let you get a data, there can be a fork that does provide data export. (In other words, it makes the possibility of a more free service more quickly even if a mostly non-Free service happens to have a Free code under AGPL).

The AGPL is a key component in solving the various problems with network services, but is only addressing one part. We should neither ignore it as "unimportant" nor treat it as a panacea.

auditing

trust-e -- a website that audits websites for privacy but all their revenue comes from the people who are being audited

consumer reports

a consumer reports for the web would useful (see Site Advisor) which is limited to issues of spam and such but it would be nice to have that describes issues of free

persuading people individually that it would be useful to change their sites

copyright licensing generally

James: This tool doesn't go as far as people think. (Contract licenses are a bad idea too.)

other contract agreements

Flickr and Zoomr have a bilateral agreement that they'll provide data export to each other. Before things blew up with the users, Flickr refused to provide an API key to Zoomr. But now they do.

identity commons

lookup: identity rights agreement charter

defining freedom approach

Luis: It gives you a starting point. May not agree, but at least gives you a starting place for discussion. The hard thing -- besides reaching the definition itself -- is appealing to many parties. FSD/OSD allow different approaches -- permissive, copyleft, different patent licensing schemes, etc. -- writing something that broad while still capturing the core issues is *really* hard.

Kragen thinks we're about 5-10 years premature for this. Can write manifestos, software, etc. -- these may not be most effective things to move freedom forward but not sure we know enough about what services are going to look like in the near future.

Luis: Think we know about freedom to get close. Mako agrees. Think we should figure out what our options are (which is what we're doing now) and then do things that help other people (I think... mako shuold flesh out)

James: We made a really long list of lots of different values. There are probably different axes, and get into apples and oranges comparisons. Freedom in SL means something very different from freedom in Flickr. Don't see any value in a definition. Think it can't be applied except in extreme cases -- the middle will always be hard.

bkuhn: Agree 100% with Kragen and 95% with James. We didn't even have FSD until mid-90s, while start of GNU was long before.

James: Different web services are going to respect our values to different degrees and in different combinations. It's hard to evaluate all these values at once and come up with one value for on a freedom scale. Evaluating a service on 6 or more different freedom value scales, and comparing those combined values against a freedom standard will inevitably involve comparing apples to oranges (how much privacy protection = how much mobility protection?). Because freedom isn't binary, and because it is evaluated across many axes, a freedom definition that enables us to identify free and non-free things is inherently problematic.

Luis: This delay is why we end up with open source. (Whoa controversy!)

Henri: Maybe we can define a *part* and should just focus on that for a bit.

Next steps

bkuhn: FSF (and to some extent, OSI and Debian too), who are the authorities on Free Software (and Open Source) established themselves as authorities by talking, publishing and sharing ideas (for FSF, starting in 1984 with GNU Manifesto and GNU Emacs development) to become an authority on Free Software and be listened to as a software freedom authority. We should consider the possibilities (for us, perhaps as a committee of FSF) to be able to make that creditibilty on the network services issue possible so that we'll be believed and heeded when we need to say that a web service has issues with freedom, etc.

Kragen: FSF got credibility by leading software development to show that it was possible.

Mako: Maybe it could be an FSF high-priority project.

Evan: Encourage existing free software network services to DTRT. Maybe use an existing definition as a minimum, while acknowledging that it's not the whole thing. Encourage people to make alternatives to existing popular services that meet that standard.

Kragen: Free services will be a lot more practical if we have platform for it. HTTP URLs encourages centralization. Note Wikipedia has many practical problems meeting our standards even though they're friendly. Hard to persuade people that this is plausible if there's nothing out there. GNU Emacs was written when GNU Manifesto came out.

Mako wants Kragen to help him build a list of high priority projects for FSF to list that are related to these issues.

Aaron: What can we do as a group? Abolishing copyright would be nice but that's not practical. Our strengths are moral leadership, galvanizing programmers. 20 years of research in p2p applications seems impractical.

Luis: There is lots of free software for services, including services that are close to being free, like Wordpress, Wikipedia, etc. (Kragen thinks there's a flaw in the OSD in that it requires you to have access to, i.e., other bloggers' data. This is contentious.) FSF could gain some credibility by getting involved in Wordpress development, running a Wordpress install, etc. (again, not a perfect example). Savannah is one good example -- what was the point of rolling it out?

bkuhn summarizes Sourceforge/Savannah/Gna (answering a question as to why FSF did savannah -- slightly off-topic): Loic was SF.net contributor, they tried to get (c) assignment from him so they could proprietarize, he refused so they forked the last free version and made Savannah. Then one developer forked Gna! off three years later (due to security problem previously discussed). Interesting case study in early web services problems and freedom issues in our own Free Software development community.

Network services to work with: openstreetmaps.org, wikipedia, AltLaw, Second Life, LiveJournal, p2p systems (Bittorent) Projects used by network services that can be changed to be more free-service friendly: Apache (logging defaults), WordPress

Establishing credibility

• analyze existing network services and describe whether they were free or non-free and publish a series of articles that describe the issues. this might be a good way establish credibility and might create concrete set of artifacts that people can see.

• AGPL advocacy may be helpful. While it's more important to developers than users, FSF often has more success advocating to developers than users anyway, so that's not a problem. Especially for GNU projects (eg GNU units)

• best practices around agpl and how to use it (i.e., use revision control)

Aaron is skeptical that we need to build credibility at all. There are three kinds of service runners: aligned with us, neutral, and against us, and doesn't think we need to build credibility with any of them.

Some discussion about what FSF will and won't do, other groups that could do this, etc.

Making a declaration/announcement

Evan: FSF merely saying that they're looking at this may be valuable. Brett agrees.

Wrapping Up

Things that are easy to do:

• promote AGPL
• high-priority projects list -- reflect our priorities here in that
• manifesto/public statement
• continue developing examples of harm, and why they're bad
  • mako interested in Facebook code exposure
  • could go in FSF Bulletin, Free Software Supporter
  • page on these issues

Proposal: keep mailing list private, Wiki (and freenode IRC) is open to read but we will ask others not to make major edits. We can propose new list members to the list. We can revisit all this later. We seem to have consensus on this.

technical issues

build distributed systems to replace centralized system

identify projects that we think will be necessary or important to enabling free services and then perhaps identify them as FSF high priority projects