Luis VillaRamblings on software, law, and the spaces in between.

“Free software… refers to four kinds of freedom, for the users of the software…”
–Free Software Definition, emphasis mine

“closing the [ASP] loophole would infringe on certain peoples rights and he [Moglen] didn’t see any way to preserve everyone’s rights…”
– Eben Moglen, as paraphrased here

[The rest of this post is not based on any conversations with FSF/SFLC folks on this issue, but merely on readings of essays/interviews/etc., and so their position here may represent a bit of a strawman. To the extent that the representation is inaccurate I apologize and will strive to fix it if someone points out the inaccuracies. That said, if it is a strawman, it is a useful strawman which helped me sort out my own thinking on the subject.]

who has the freedoms and the rights?

In one of my GPL posts, I mentioned that I thought that the question of ‘who holds the rights’ is a critical distinction between the ‘free’ and ‘open/pragmatic’ licensing camps. To the free camp, rights are held by users; and to the open/pragmatic camp, rights are held primarily by developers- who then grant most (but not necessarily all) rights to users. I thought I’d dig a bit more into that notion, particularly into the question of what a ‘user’ is in this day and age, because I think it helps explain the current dilemma around free software as deployed over the web.

who ‘users’ used to be

FSF has always insisted that “users” are the locus of all rights. In practice, to FSF, “users” has really meant “the people who install the software”- what I’ll call “user-deployers” or “deployers”, in comparison to “the people who use the software”- what I’ll call “user-consumers” or “consumers.”

In the beginning, this was not problematic- anyone who deployed free software also consumed it, so giving rights to all deployers also gave rights to all consumers.

As free software got more popular, this got a little more complicated- deployers were often systems administrators in an organization (who had full rights to modify the code) and the software was used by consumers in the same organization. These user-consumers were given the binaries but were not given enough permissions to install new versions of the binary, or access to source (though they could presumably obtain them for their personal, non-work PCs if they were skilled enough.) And so there was a gap between the rights of deployers (who could modify) and consumers (who could not)- a small gap, but a gap nonetheless.

In practice, this worked OK. The interests of user-deployers and user-consumers were not perfect aligned, but they were pretty close- deployers mostly wanted consumers to get things done and get out of the way, so they protected consumers to a large extent. In addition, even if they weren’t always exactly aligned, consumers and deployers were clearly both on the same side against the software vendors- both consumers and deployers wanted more freedoms than the vendors would necessarily have chosen to give. Given this combination, for most purposes it is fair to say that in practice user-consumers had the freedoms to use and modify- even if in practice those rights were granted to and proxied through the deployers hired by their organizations.

who ‘users’ are now

That brings us to the present day. With the advent of the LAMP-powered web, user-deployers and user-consumers of free software are often no longer in the same organization- the deployer, who was once the local sysadmin, is now the sysadmin of Google or Yahoo. As a result, the interests of the user-deployer and user-consumer are often poorly aligned or in outright conflict. In addition, the old tension between vendors and user-deployers, which helped protect user-consumers, has to a large extent vanished- since the deployer of the free software (the party that runs the compiled code) is now also the vendor.

In a web world, then, user-deployers have the same rights they’ve always had to use and modify. The FSF apparently believes that should not change. But since the deployers and consumers aren’t part of the same organization anymore, the deployers no longer protect the user-consumers, and so user-consumers end up frequently making use of free software without even the slightest ability to use and modify the software- and often even without the right to use and modify their own data!

This is, I think, part of why Matt Asay wants to call GPL ‘the new BSD‘- like the BSD, the GPL lets software vendors (in the BSD case, Apple; in the GPL case, Google) deliver software to consumers without also delivering the freedoms to use, modify, and redistribute. Some freedom is preserved- the freedom of the deployer to use and customize- but this is not, at least in my mind, the kind of freedom I’m aggressively interested in working towards.

so how to restore freedoms to user-consumers?

This problem isn’t easy to resolve systematically- since they are in conflict, any attempt to guarantee rights to user-consumers would seem to require some compromise of the rights of user-deployers. I admit I myself am a bit stymied on the issue, though I have some ideas.

Prof. Moglen and FSF’s position seems to be that the freedoms of user-deployers will trump those of user-consumers until someone comes up with a principled and rights-centric way to draw the line between the two. Unfortunately, Moglen seems skeptical this line can be drawn- and experience shows that he is usually right.

I remain interested in the problem, though, since in the end I’m much more interested in the freedoms of users than the freedoms of sysadmins. I hope that better understanding that there is more than one type of user takes me one step closer to figuring out where the line can and should be drawn.

Thinking about the Open Service problem

As Havoc mentioned, I’m putting in some time on thinking about what an Open Service Definition (to parallel the Open Source and Free Software Definitions). I present here a rough draft of a framework for evaluating such a definition. It is not the definition itself, nor a license/technology/business model/etc. which follows the definition, merely a framework which will generate questions to ask and issues to cover when creating such things. It is not the only possible framework, either, but I think it is probably a good starting point to think about what questions must be addressed.

Some of these evaluation criteria will be familiar from the older definitions; some will have been implied by them but not widely discussed. All will still need elaboration, but I think it will be useful to write down how I’m thinking about the problem. Comments are welcome; email preferred, because of the complex nature of the problem, which I don’t think lends itself well to linear wordpress comments yet. If I’ve reached out to you recently about this problem, expect personalized email or phone calls in the next few days :)

All of these criteria involve sliding scales- obviously if a licensor moves any of them all the way to the closed/unavailable side you have proprietary or semi-proprietary software, but depending on where the lines are drawn, you have more or less onerous requirements with different outcomes- much like the current differences between more protective licenses like GPL and less restrictive but still meeting the definition licenses like BSD.

Goals
The point of having open/free systems:

• user freedom. results in security/autonomy/self-actualization/moral development/customer satisfaction/what-have-you. (Interestingly, neither the OSI nor the FSF definitions really go into why freedom or openness is actually good, which I think contributes to the lack of clarity around each.)
• direct contribution to the codebase or otherwise to the community. Includes the free rider problem and possibly other collective action problems as well.
• ecosystem participation. e.g., application development or API consumption. May include network effects and stickiness (both as a benefit and detriment.)

Evaluating these criteria differently will result in different values for the next two categories (preconditions and rights). For example, when in doubt the FSF favors user freedom, which means much stricter restrictions on redistribution than might otherwise be ideal for direct contribution; when in doubt Linus favors contribution and ecosystem participation and hence prefers GPL v2 to v3. And of course the Open Source/Free Software split was precipitated in part by an increased emphasis on ecosystem participation and decreased emphasis on user freedom.

I’m not entirely sure yet that direct contribution and ecosystem participation are really all that different in practice, but it seems they might be (particularly in an online context) so I’m keeping them separate for now.

Preconditions

If these preconditions are not met, then you can’t meaningfully achieve the rights listed below or the goals listed above:

• data access: taken for granted until recently because our data has always lived on local drives, or on servers we controlled. As a result, this is implied by the Free Software Definition and yet not protected by the GPL (even v3). DRM falls into this area- the software or hardware takes away your data access, and hence deprives you of the user rights. Sliding scale includes not having any data access (many web services), having access to the data, but only as a binary blob (most end-user proprietary software), or having access to the data stored in standardized or otherwise open formats.
• source access: as noted in the Free Software definition, this is a precondition for all other user rights. Sliding scale can include (among other options) mandatory provision (GPL v2), mandatory provision and reuse (v3′s tivo clauses), or no such (BSD.)
• hardware access: never much discussed because, unlike everything else here, hardware actually is scarce, and so can’t be provisioned merely by good intent or good licensing. May make some sense to discuss in the context of servers, though- for example, if all your source is available, but it can only be run on multi-billion dollar server farms, is it actually meaningfully open? Does dealing with this angle require p2p solutions, or will single-point of failure solutions (with other safeguards) be sufficient?

It may make sense to speak of skills to manipulate source as being a precondition, alongside but distinct from source access. For the time being, though, I’m content to do what the FSF has done and say that as long as you have access to the source, you can buy skills from elsewhere and hence approximate the freedom of someone with the skills.

User data privacy is clearly important to the analysis of online services, but I’m not yet sure how this fits into the analytical model. It is often spoken of as a constraint on data access, so perhaps it fits as part of that criteria or sliding scale. Note also that there is a similar problem with the data which is created as a shared value- e.g., obviously my password is private when I contribute to Advogato, and so should not be shared, and my Advogato diary entries should probably (though not certainly) be removable, but what about the trust metric ratings I have contributed? Should they remain irrevocably available? Not yet clear where this fits in the criteria/discussion.

Rights

Rights available to participants in the commons.

• use: this includes a temporal dimension, which open source has typically taken for granted, but which is now relevant for discussion in the case where servers/services go away (either maliciously or for other reasons.) This temporal aspect may make more sense elsewhere, since it has implications for things like server ownership and server governance. Note also that the v3 now includes some potential restrictions on use (where, for example, the network is damaged by modified clients.)
• modify: as in FSF/OSI, pretty much, including sliding scale of options. May have some implications for APIs/service guarantees in an online context which are not readily comparable with the traditional model.
• redistribute: as in FSF/OSI, pretty much, including sliding scale of options.

These are pretty much straight out of the Free Software Definition. I tend to think FSF freedoms 1, 2, and 3 have a fair amount of redundancy, so they get collapsed to modify/redistribute, with the assumption that redistribution means either modified or unmodified.

FSF calls these freedoms; I call them rights here because I personally tend to think of them as inalienable things which should be provisioned rather than optional things which can be taken or not. But neither term is completely satisfactory for this analysis, since saying that these are rights or freedoms implies taking a position on where on the sliding scale restrictions should be made.

Not clear where the question of who gets access to these things fits into the analytical model; OSI’s definition leaves that up to the license, and even FSF allows some fairly strong restrictions on who gets source access and hence gets to exercise these rights, so perhaps it is merely implied that that is part of the spectrum of options for each criteria.

Where to from here

I’ll be working with a number of people (both inside and outside Red Hat) to try to flesh this out in the next few weeks. I don’t expect we’ll really have pragmatic outcomes (i.e., licenses, business models) in that time, but I hope that we’ll at least be able to frame the discussion so that those writing code and running servers (including, but obviously not limited to the online-desktop) can think about the issues more easily and more transparently. As such, if there are other axes/criteria that need evaluation, I’m happy to discuss them with anyone- email or by any other way you can get a hold of me.

I’ll obviously be participating where appropriate in similar efforts- I’m not a fan of duplication of effort or NIH problems, so I welcome pointers to any advanced and pragmatic efforts I should be working with. But so far it is my observation that most open service definition proposals either have specific goals (i.e., they think there is a particular technical solution that must be used, or a particular policy agenda which must be advanced) or they have no code in the game, or both. I want to avoid the first problem, at least right now, by advancing a framework for discussion, and then allowing people with specific technologies/agendas/etc. to reason within that framework, rather than picking an outcome and then discussing a framework. I also want to take advantage of the opportunity to work with online-desktop in order to have someone implement the outcome- I think that it is only by implementing such technologies that we’ll actually get a good understanding of what licenses, business models, governance systems, etc., are really appropriate. So far it seems that other such proposals have not had this key element of real-world application in place. (Plan to throw one away; you will, anyhow.)

I’ll probably be wikifying this all soon as well (as soon as I can figure out where, and figure out how to keep the signal/noise ratio high); the wiki will include source links to the various places that have provided background or information for this, as well as some more details and questions that are still very much unanswered. In the meantime, thanks to various people, including Kragen, Mako, Mike Linksvayer, Gabriel Burt, Havoc, and many more who have influenced my thinking on this. (Including Stallman- who, whatever else you may think of him, is the reason we’re all here.)