Wesabe’s Marc Hedlund is speaking at the Princeton Cloud Computing seminar I’m at. Their ‘data bill of rights’:
This Data Bill of Rights is our promise to you.
You can export and/or delete your data from Wesabe whenever you want.
Your data is your data, not ours. Our job is to help you understand and act on your data.
We’ll keep all of your data online and accessible for as long as you have an account. No “archive access” charges.
Any data you want us to keep private, we will.
If a question comes up not covered by these rights, we will answer it remembering that your data belongs to you.
Interesting. My intuition is that this is a really good start in the right direction for web apps; he himself notes, though, that it isn’t legally binding. They are considering doing that- will be very interesting to see that if/when it happens.
No one should be surprised that social network users can’t ‘vote with their feet,’ because most users give up a portion of their autonomy when they choose to use web services. This post will suggest that protecting autonomy is desirable and should be designed in to software, and outline five qualities that such software would have.
[The rest of the post will not be brief; it is in part a draft of an essay for my class in ‘Law in the Internet Society’.]
“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.
I’m obviously interested in what is going on at OSCON this year, since the overlap between web 2.0 and free/open software seems to be a major theme. Unfortunately, I couldn’t go, so I’m left lurking from afar.
“talking about real freedoms … requires a discussion about public policy and long-term consequences of all this technology we’ve all put into the world”
I couldn’t agree more. We are standing at the brink of a huge change in how people store the data that makes up the emotional content of their lives. We must start coming to grips with the policy implications of that, just as government once struggled to come to grips with the impact of people storing the economic content of their lives in banks, and I’m excited to think that free and open services could be part of that. (We also need to think about other policy issues- patents, etc.- that can’t really be dealt with in isolation, but those aren’t my focus right now, even if they are Eben’s :)
That said, from John’s notes on Eben’s talk today:
The fundamental right with which Stallman has always begun is anyone’s right to run any program anywhere at any time for any reason – this has to include the right for people to run a program at any time *for anyone* – that is, provision of software as a service for other people. …
If the discussion about service provision is a rights conflict issue, it is critically important to frame that discussion in clear terms based on the rights perceived to be in conflict.
No rights based argument sufficient has been articulated which should compel the release of code which some people choose to run for third parties benefit. That doesn’t mean such an argument doesn’t exist…
I had already begun to try to formulate my argument in terms of rights, so I’m part way along this road already, but once you have such a broad interpretation of the rights of the user who execs the software, it becomes very difficult to convincingly articulate the rights of the user who puts data into the software, the value of the commons, and the rights of developers. I’m sure Eben is right that it will be worth the effort to try, but I’m not confident that I can succeed within that initial set of assumptions. Keep your eyes on this space, I suppose :)
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.
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.
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 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.)
I did the right thing by not going to GUADEC, but man, I wish I were at GUADEC.
Havoc (and others saying the same thing) are completely right that we must move towards deep web integration. I have no strong opinion on whether online-desktop is the right technological approach for that, but we have to start somewhere. Moving the battle to a development platform based on an open, widely-implemented standard (HTML/JS/etc.) maximizes our strengths and minimizes the strengths of our competitors.
Many web services are proprietary, but we can’t just twiddle our thumbs while the Apache/rails/django/etc. people work on this problem. Like free software in the 80s, we must realize that our options are (1) work with proprietary (web services|kernels) or (2) become completely irrelevant while we wait for free (web services|kernels) to be built. I know which one I’d rather do. As a bonus, I don’t believe we’ll have to wait for good free services nearly as long as we had to wait for a good free kernel.
Hopefully I’ll get to do some interesting stuff with a Free Services Definition in the remaining weeks I have at Red Hat, now that GPL v3 work has mostly wrapped up. Am very excited about that.
This deserves to be developed more fully, but perhaps the thread that ties together my irritation with the MS-Novell deal, my irritation with the Mozilla TM licensing, and what worries me about the push against copylefted DB data, is the creation of (or in the DB case, allows the creation of) artificial scarcity. I’m OK with charging for things that really are scarce- cars, service, etc., but creating artificial scarcity, either through the use of patents, copyrights, or trademarks, or by allowing others to use trade secret and SaaS tactics to take data from the commons and then proprietarize it, seems problematic.
(This is hardly an original thought; I just wanted to get it out and searchable later, since I’m wrestling with the trademark demon again.)
These are the last odds and ends of my GPL Q&A series. I may or may not find the energy to elaborate on the patent and DRM provisions tomorrow, since those seem to have generated the most questions, but I may not- I’m completely destroyed right now, and I plan on going to a baseball game tomorrow night and having a beer instead of writing. Generally, I do not recommend writing about something at work all week, and then coming home at night and writing more, in a different voice, for a different audience, and all while trying to maintain your impartiality and mental walls on both sides. Draining.
Q: Tell us how you really feel about the ‘pragmatism v. idealism’ framing of the Linus v. FSF camps.
A: Argh. While it certainly isn’t untrue, I think it is a lot more useful to frame the camps in terms of being split by focus on rights of developers v. rights of users. Both camps get pretty irritated when they feel their real rights are being violated- plenty of members of both camps have tromped around enforcing their copyrights when they feel they need to, and both camps feel very strongly about their visions of how the world will or should be (Linus may not say ‘should’ a lot, like Richard does, but the world domination talk is most definitely a driven vision of a specific world that he likes.) And both sides are willing to compromise on methods as long as their goals are reached. (Do you really think RMS consulted with IBM and Sun on v3 just because he is a nice guy? No; he’s just a ruthless pragmatist when he wants to be.) This isn’t to say there isn’t a lot of truth there; the meme wouldn’t be so pervasive otherwise. But both parties have a lot more in common than recent coverage and discussion would have you believe.
The pragmatist/idealist framing not only isn’t terribly accurate, it isn’t very useful. It makes for an easy story for journalists, but past that what is mostly does is to encourage both sides to think of the other side as either crazy or immoral, when in fact they share a ton of common ground. (If their mechanisms and goals didn’t overlap, the fundamentally user-focused v2 wouldn’t have been so wildly successful with developers.) If the FSF spoke specifically of user rights instead of generic rights (which are easier to mischaracteriz/ridicule), and addressed developer rights as a complementary set of rights instead of something secondary, it would help bring everyone together as peers using the same language instead of frequently ridiculing each other. Similarly, if the ‘pragmatist’ camp had admitted that they too were concerned with rights- just a different, perhaps more limited set- it would have helped them get more of what they wanted (simpler language, for example) out of the FSF. Of course, it is too late now for this round, but I think both sides should work on expanding those common grounds in the future. In the meantime, the rest of us will have to sit back and watch while they snipe at each other and Microsoft has the last laugh.
Q: While you’re venting a bit, have a blast: how do you feel about the claims that the v3 is ‘political’?
A: The use of ‘political’ as a slur against v3 demonstrates an abysmal understanding of both the specific history of free software and the general history of how rights evolve.
Yes, v3 is certainly political, in the sense that it claims the existence of “rights” that are controversial, and hence whose existence (or non-existence) has to be resolved via political/social means instead of judicial/analytical means. But all of these things were also true of v2. We’ve now reached the point where even Microsoft has mostly accepted that developers have the right to share if they want, and that community development is a valid and respectable way to develop software. Given that, it is easy to forget that in 1991, the notion of sharing and openness in code was controversial, and that as recently as a few years ago Microsoft was denouncing it as unamerican. If we’d listened to those who dismissed v2 as ‘political’ (or worse) in 1991, we wouldn’t be where we are today. So dismissing anything now because it is ‘political’ (instead of actually discussing the merits, which I fully admit are arguable) would be silly.
More generally, the v2’s transition from ‘political’ to accepted right is a fairly common trend in Western political history, as rights go from non-existent to hotly politically contested to taken for granted. Again, to dismiss something as ‘political’ demonstrates a great deal of ignorance of these broad historical and political trends. A good comparison is women’s voting. We take it for granted, and don’t think of it as ‘political’ anymore- it is now a core right, very broadly accepted. But when women first proposed that they should be able to vote, the question was very much ‘political’- protest marches were held, proponents were scorned, and the process took decades to go from proposal to accepted fact. Now, of course, you could be raised and come to adulthood without ever being aware that it women ever were denied this fundamental role in our society. As it has with the attempted creation of new rights in v3, new issues have evolved from the suffrage movement, like the rights of women in the workplace and affirmative action. The historical question is not whether it is wrong to bring these issues up for being ‘political’, but rather whether in 15 years we’ll see DRM as being more like the rights of women to work (was “political” after voting rights passed, now no longer controversial) or like affirmative action (was “political”, still is in many places.) Either way, the right way to tackle the issues is on the merits- not to use political as a slur.
Q: Back up a bit to day 1 and get off your high political horse. You said GPL v2 is incompatible with GPL v3? That doesn’t make sense.
When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job, because GPLv2 would need a similar clause.
Because of this clause, “compatibility” with GPL is always a one-way street- I may be able to convert BSD or APL code into GPL code, but I can’t do the reverse. GPL with itself is no different.
Q: So, uh, isn’t incompatibility bad?
A: The incompatibility does restrict your ability to cut and paste code directly from one codebase to another. But past that, it probably won’t matter much.1 Again, quoting Stallman:
Fortunately, license incompatibility only matters when you want to link, merge or combine code from two different programs into a single program. There is no problem in having GPLv3-covered and GPLv2-covered programs side by side in an operating system. For instance, the TeX license and the Apache license are incompatible with GPLv2, but that doesn’t stop us from running TeX and Apache in the same system with Linux, Bash and GCC. This is because they are all separate programs. Likewise, if Bash and GCC move to GPLv3, while Linux remains under GPLv2, there is no conflict.
Q: Talk to me more about this APL compat. Are we going to have GNU/httpd now?
A: The one-way compatibility of GPL (mentioned above) isn’t something that is ‘hidden’ when FSF talks about compatibility- it is very deliberate, very public, and very explicit. So this new compatibility means that one-way GNU forks of Apache projects are now a legal and theoretical possibility. But pragmatically, it seems unlikely- the Apache folks have well organized communities that would likely outcode any fork, and when Mozilla went dual-license, Stallman specifically recommended against such a fork. It seems unlikely he’d act differently now- the goal of this compatibility has been to increase the ability of free software communities to work together, not to split them apart.2
Q: What about the Internet and Software as a Service?
A: The FSF’s relationship to software delivered over the internet is ambiguous. v3 explicitly maintains the loophole for software whose UI is delivered over the internet, so someone3 can still do things like take GNU code, replace the terminal interface with an html interface, distribute it to the world via http, and not provide your modifications upstream. At the same time, FSF does endorse the Affero Public License, which closes that loophole. If you’re worried about that problem, you can definitely use the Affero instead of the GPL.
Exactly why the FSF hasn’t closed the loophole in the GPL and is instead offering the Affero is unclear; if I were a betting man I’d say that the FSF would prefer to use moral pressure on Google and friends, rather than legal pressure until Microsoft is no longer a threat. The phrase is ‘pick your battles.’ You can see Moglen talk a little bit on this subject here. (Be forewarned: I normally think that Eben is one of the world’s best at taking difficult concepts and expressing them orally, but this isn’t, IMHO, Eben’s most lucid talk, perhaps because so much of it may be intended to be read between the lines.)
Q: Any thing you missed or badly screwed up in the first few days?
A: The biggest was that I neglected to mention a significant downside to dual-licensing. When you dual-license, you limit the code you can copy and paste into your own code base to the set of code which shares the same license you do. So, for example, Mozilla (which is triple licensed) can only copy from code bases which share the same three licenses- that is to say, virtually none. Not only does this make it more difficult to reuse code from elsewhere, it also makes it easier for forks to occur. For example, Flock is a GPL-only fork of Mozilla. This means that when Mozilla makes fixes, Flock can take them, but not vice-versa.
I also overlooked another option, besides outright copyright assignment, for handling the ‘or later’ problem- the license allows assignment of a proxy who can decide whether or not to upgrade to future versions of the license. This allows you (for example) to assign the right to upgrade to GPL v4 to the GNOME Foundation, without having to trust them completely enough to do a copyright assignment, while still allowing the Foundation to set some coherent strategy when the next license comes out. It seems like this is something that organizations who intend on being around for the next 16 years might want to consider as a lighter weight alternative to copyright assignment or just blindly trusting in ‘or later.’
Oh, and I’m not doing the all-caps thing; that is my theme. Sorry about that; I intend to fix it at some point. Q: parting shots for now?
A: This license is an evolution, not a revolution; a good one that lots of projects will adopt, but which won’t (quite literally) change the IT world like v2 did. The revolutions are still to come- when we figure out the licenses for things outside of copyright (like web APIs, standards, personal data, and trademark) that give us great developer benefits and improved user rights, like GPL v2 did, we’ll see explosive growth in those spaces.
If you’ve seen an O’Reilly article arguing otherwise, ignore it- or at least go back and read the comments, particularly those from Richard Fontana. The article seriously misunderstood a lot of things. [↩]
Note that I’ve been told that GNU has done this in some cases, like gnash, so YMMV. [↩]
(Before going further, you should (at the minimum) read the disclaimer on Monday’s post and (ideally) make sure you’ve read all of the past two posts. (first, second.))
Q: Companies hate this! The sky is falling if the GPL is adopted!
A: Find your calm place. There is no doubt that the new license will create new uncertainty, which companies hate, and that the license seeks to place rights more firmly in the hands of users, which many companies (though not all) hate. So companies have reason to be nervous.
But the license was created with input from an extensive range of companies who both produce and use free software-based products, so I think you’ll find that it really isn’t that bad for companies who are playing by the rules- that is, for 95% of companies, 95% of the time. Remember, this license is (for most purposes) much more evolutionary than revolutionary, so it gives the same rights, sometimes clothed in different languages, in most circumstances. Most companies will not be affected by the tivo-ization and DRM clauses, and will actually appreciate the additional protections of the new license. Especially once companies have had time to digest the license, and to realize that none of the early adopters have turned into a newt, most companies should be fine with the license most of the time.
Q: OK. A little calmer now. My company makes products based on open source components. What are my new risks?
A: Have you burned the boats? If you’ve truly burned the boats, you’re fine- the patent provisions and installation provisions of the license only help you get closer to your customers and differentiate you from competitors and free-riders.
On the other hand, if you or your customers are still relying on some form of proprietary lockin, the picture is much less clear. You have new responsibilities that you may not have previously had. In particular, if you contribute to GPL v3 projects, you have to open up your patent portfolio to those projects and their users, and if you distribute GPL v3 code, you have to give your users the ability to reinstall code that they modify with very few restrictions. These may not be dealbreakers, but if your business model depends on users who are somehow kept under lock and key, you will have to deeply examine the new license, and may have to reconsider basing your business on GPL’d code.
Q: Do I get any benefits to go with those risks?
A: Like everyone else, you should get greater certainty about patents, and greater legal certainty in general as a result of the improved language. The same clauses that protect your customers from you will also protect you from competitors who seek to use some sort of patent or device lockin to compete unfairly against you, so even they aren’t all bad.
You’ll also get more control over trademark as part of the compatibility with the APL- you can explicitly ban use of the trademark by derivatives, among other things. Most community projects are not overly concerned by trademark, but this is clearly important to companies who are trying to build a brand, and more explicitly spelled out now as an optional addition to the license.
You also get the ability to transmit code to contractors without being considered to have ‘conveyed’ the code, allowing you to use consultants and outsourcers to modify your private code forks without accidentally freeing your work. If you sell non-consumer products (IBM S390 servers, for example, or medical devices which might be under government regulation) you are now even allowed to prevent modification/reinstallation by those who you sold servers to.
If you’re using patents or hardware to lock in your customers, none of these things are going to be much solace. But for everyone else, they should be useful compensations which make up for the short-term uncertainty.
Q: Why is Sun seemingly so excited about this? Should I share their enthusiasm?
A: Maybe. Sun is in a fairly unique situation. They badly want to win developer mindshare away from Linux, so becoming More FSF-Free than Linux is a big PR win for them- more so than it might be for most companies who aren’t competing with one of the poster children of open source and with the ghosts of their own proprietary past. In addition, some of the license features which are problematic for many people may be a benefit to Sun. For example, most people will look at v3’s incompatibility with v2 and think ‘what a pain’. Sun, in contrast, might think of that as a benefit, since that would continue to prevent Sun code from being used in the Linux kernel- who have to be seen as a significant competitor for them. Similarly, the new clauses which make embedding and DRM difficult may be seen as a detriment by many developers, but they play very well into Sun’s business model for Java, which is based on licensing into the embedded market. Anything that encumbers Free Java helps drive embedded market revenue for them, so GPL v3 may be preferable to v2 from that perspective.
All that said, we should probably give Sun some of the benefit of the doubt at this point- they’ve freed a lot of code, and by all accounts are trying hard to become a more open company. If they really wanted incompatibility and embedded revenue, they could just stick to the CDDL or a proprietary license. GPL would be a huge step for them, and is a step that the Free Software community should welcome with open arms, even if their motives are not 100% pure.
Q: Should Novell be quaking in their boots?
A: Hard to say. With their recent joint announcement with the EFF1 they appear to have started the process of really burning the boats. A company fully committed to competing on the basis of quality and service, and willing to say no to customers who ask for bad things, should have very little to fear from GPL v3, and it seems like (belatedly) Novell may finally be headed in that direction.
Q: But Novell are on the hook for the MS deal, right?
A: Yes and no. While a deal like the Microsoft-Novell deal, which induces a third party to grant a non-assert agreement, older deals got grandfathered in- the FSF appears to believe that it is better to have Novell tentatively on our side than actively using their large warchest to fork everything that goes v3.2 But it seems unlikely that MS can continue to uphold their part of the deal without licensing their entire patent portfolio to some key technologies like gcc and libc. So MS has a strong incentive to get the deal voided, and even if not, it will expire in the not too far future. (Remember, they negotiated a license which only covers five years of twenty year patents.) If they do renegotiate, the new deal will almost certainly look like the Xandros and Linspire deal, where MS offers indemnification to individual users instead of to all users. This will be acceptable under the new GPL language.
Q: So can we break out the champagne? Is the MS patent threat over?
A: Definitely not. MS can, of course, cease giving out coupons, and try to induce Novell to adjust the deal. Moreover, because of the complexity of the patent language, there is almost certainly another loophole for them to exploit, though it is hard to see what it migh be at this time. They could, for example, offer indemnification directly to customers- which appears to be the route announced in the Xandros and Linspire deals.3 Even if they do continue the relationship with Novell, lots of very big chunks of code that aren’t GPL v3, like the kernel and Open Office, will not be protected. So we’re still dead in their sights, no matter what.
Q: What does MS think, anyway?
A: They are gearing up their FUD machine, of course. Expect the old reliables: GPL is anti-American, GPL will steal your rights, GPL will eat your babies. Expect some new favorites too- lots of talk about how MS ‘builds bridges’, and about how the GPL hates interoperability. Of course, no mention will be made of the tolls that MS wants to charge on those bridges, or of the tons of GPL licensed code which builds bridges both to open standards and (despite the difficulties) to MS ‘standards.’
Q: What about the little guys in the embedded/consulting space? Opened Hand, Fluendo, etc.?
A: Each will have their own sets of problems and evaluations of the license. The new LGPL should allow Fluendo to continue down the mixed proprietary/open path they have chosen. Perhaps a more difficult question is what this will mean for those who are thriving in the embedded phone/handheld device space, like Opened Hand, OpenMoko, etc. The new license would appear to require that they allow modification, even for things like phones- which may be very problematic for networks (despite the out for network service providers included in the license, which allows you to withdraw services from modified devices if the modifications cause problems.) It will be interesting to see what openmoko’s lawyers say- they appear committed to resolving the problems between a locked down network and an open device, but this may be too much even for them to overcome. 4
Q: What about Google and other SaaS companies?
A: Nothing here that impacts them; they can continue business as usual. There is a new Affero GPL, which closes the SaaS loophole, but the FSF has made it clear that for now they will use moral persuasion rather than licensing to encourage code to migrate out from behind the closed Google doors. You might call this ‘picking your battles.’
Q: what is the bottom line for companies and the GPL?
A: For most? Simple. If you just use GPL-licensed code (for example, as a server or desktop), you have no worries. If you contribute code to GPL projects, you’re OK, as long as you feel comfortable granting your patents to the version of the project you’re contributing to. If you distribute GPL code as part of a device, you’re also OK, as long as you allow users to modify their devices. These categories cover the vast majority of corporate participants in the existing GPL community.
Despite that, this won’t be a license for everyone; some companies may prefer to stick with v2 or perhaps even use other alternatives instead. Like the choice for developers, the choice will require a case-by-case analysis of the costs and benefits. I do look forward to the day when we have a new license, representing a new and appealing business model which makes these kinds of choices easy, but for right now we’re stuck doing the hard and sometimes unpleasant work of protecting more user rights, and that means compromise and muddiness, not clear wins. Sorry about that…
which I’m embarrassed I haven’t covered in more detail- it was a bold move by Novell, given their conservative history, and the announcement deserved more attention than it has gotten [↩]
This clause also prevents Sun and IBM from having to review every patent licensing deal they’ve ever conducted- which is probably a good thing, since given a choice between ‘pay lawyers to audit and renegotiate potential tens of thousands of contracts’ and ‘skip the GPL v3 party’, they would almost certainly chose to skip the party. [↩]
FSF appears to be OK with this, since that route does not break away a chunk of supporters. [↩]
Perhaps we’ll have to wait for voip over wimax to get truly open wireless devices. :/ [↩]