At last week's Red Hat Summit, Eben Moglen, director of the Software Freedom Law Center, spoke about the state of the GPL 3.
Eben Moglen is one of those people in the community that delivers his message in a clear, concise way that never fails to capture the attention of his audiences. The Founding Director of the Software Freedom Law Center gave two talks at last week's Red Hat Summit, the second being more of a Q&A session than a formal presentation.
Although this talk was before the recent round of allegations from Microsoft, Moglen's topics were still very much germaine to the Linux community. In Part I, Moglen discusses how the GPL3 relates to different segments of the community, and ponders the structure of the Linux kernel project and how a hypothetical license change might apply.
Eben Moglen: Let me expand a little bit on a couple of comments made earlier in the course of the Conference and just post up a little bit of news. As of this week, I think I see smooth sailing directly to a last call draft at the end of this month and the option of the license in a formal sense at the end of next, so I think the schedule is at this point fairly firm. I see very few matters that still need significant work before we can go to a last call draft. I think we've gotten about a dozen places where there's minor work needing to be done and I think we have two or three places where something a little more substantial needs to be completed. But I think the relevant further modifications are on that scale. So the draft published--this discussion draft three at the end of March, is very close to the last call draft, which means I'm not in the position of having to describe that which is not public in any meaningful way. In response to questions I should be able to give answers which contain information about what is the final license in almost every respect.
I want to call attention to... the question of the difference between those elements of license change which are important to lawyers and those elements of license change which are important to other people. And I want to concentrate here on other people in two senses. With respect to engineers the transition to GPL3 ought to mean in practice two things. For those engineers working outside large patent holding enterprises there should be more opportunity to feel sure that you can work on GPL code net of patent annoyances by those people who have also touched the code It should be possible in other words to believe yourselves part of the community of people who do not themselves ever engage in any kind of patent shenanigans within the community. With respect to outsiders, you will have at least some understanding of the mechanism whereby the community means to defend itself against outside patent digression on the surface of the license. So it ought to be at least possible to understand for engineers worried about this global patent whatever it is and how does it affect me? GPL3 ought to come as meaningful, helpful news you can use with respect to your role against the patent thread if you are modifying, reshaping, copying, using, deploying, assisting others to modify copy shape or deploy GPL code. That's the first thing I think that the license means to engineers.
The second thing I think the license means to engineers that it hasn't meant before is if you are building consumer devices, stuff intended for people to use in their ordinary daily lives, in their houses and their cars and their pockets and their schools--even if it's stuff which also is going to be used by businesses, if somebody wants to lock that stack down, so that the GPL code in there can modified by you after it has hit the field but cannot be modified by the consumer then you have a new class of problem to alert the business about. GPL3 wants one rule to be followed; if your product can be modified after it is in the hands of a consumer doing ordinary light stuff with it, and if you have the ability to modify code in there which is under GPL, or if you have given some other third party the right to modify code in there that's under GPL then the consumer ought to have the same degree of right that you have reserved or that you have passed to a third party.
If you're making consumer stuff that nobody can change after it is in the hands of the consumer--great. And if you're making stuff that everybody has equal access to change and hack around with--great, too. But if the way you're conveying consumer devices is to lock down the GPL code in there so that some people have a right to modify it and some doesn't include in the guy to whom it was sold that's a problem and you need to tell people about it. Those are from my points of view the two major areas in which GPL3 conveys news you can use to engineers making things.
The other bunch of people I want to talk about the license's effect on are people who license patent claims and other intellectual property, not necessarily lawyers typically involved in software licensing. In that world, GPL3 also brings some change and the change is when people modify code, when they contribute to GPL programs they're making a statement about patent safety to everybody. The statement they're making is when this code leaves my hands, whatever patent claims my employer or I have that read on the code as it is leaving my hands, we are freeing up for use in this program or works based on this program by anybody who gets the program or the modified version. So when we contribute to a GPL program we are doing something which has an effect in forbearing application of our patent claims to that code in other people's hands or to descendants of this code in other people's hands. That's a significant commitment to patent rights. It's not a more than is necessary in order to be sure that there will be no betrayals inside the community. It's what it takes to be sure that there will be no betrayals inside the community. Moreover, if you distribute GPL3 code that you did not modify then the person who gets code from you in that distribution is getting a promise that you will not enforce patents against them. If you discover that you have patent claims that lead on some code that you have been distributing under GPL3 and you want to reserve the right to enforce those patent claims you have to stop distributing. You can't be giving people stuff that practices your claims under GPL3 while at the same time reserving the idea that you might sue to enforce that patent against that work or a descendant of the work. But if you discover that you are inadvertently distributing something that practices your patent claims you can just stop and when you cease distribution you cease to be subject to that limitation.
So there are two classes of activity under GPL3 that affect the interests of those who license patent claims within the enterprise. They want to know if distribution is going on what patent claims in the house might lead other distributed software or that it's not worth searching. And they have a call-back if they have a problem; they can cease distribution. With respect to the code, which is contributed to GPL3 where it's on the other hand they need to make a permanent commitment when the contribution goes out the door. They need to have thought about whether it is appropriate for this contribution to be made and they need to decide whether they are prepared to allow those patent claims to be used by those who may or have made modified versions of the work as well employ the work itself.
One of the consequences of this is we believe that certain highly patented enterprises will decide to be a little more careful how they contribute to GPL-works. We think this is appropriate. Even if it means that some enterprises with a lot of patents will think more carefully about the business case before submitting simple patches to code we think it is appropriate for people who are making major architected contributions should consider their patent portfolios. We want to avoid inadvertent employments of people's patent claims which might result in friction within the community down the road. It is good to make people think about what they're doing before they put it in.
But there will be consequences for GPL3 and then the licensing executives and so one of the things we need to be prepared for is to answer the questions of licensing executives for why the software license works the way it does may not be so clear or the value of the GPL3 may not be so clear and we need to be prepared to explain what is and what is not the rule about this from the perspective of the licensing executive. I will at the Software Freedom Law Center admit documents explaining these questions for these communities. They're not exactly the lawyers and they're not exactly the engineers. But they are relevant constituencies who need to understand.
So I've tried in those few minutes to suggest ways that we might think about what GPL3 means if we are not the general counsel's office. The general counsel's office has largely been involved in this discussion, if it cared, and explaining that activity and what it means to lawyers, which represents the activity and carefully going through legal language and crossing it out isn't a fit subject for nine in the morning in such a place anyway. I think the best thing to do as I said at the beginning is to stop there and take questions. So, what do you want?
Question: Let's just say Linus Torvalds was interested in flipping the kernel to GPL3, how would he do that in light of the lack of any future version that falls in GPL2--just mechanically how would it work?
Moglen: Let me say some things in a purely theoretical light, okay? Because I don't have the relevant facts about Linus and his colleagues' project and I don't want to be taken to be making suggestions about a particular state of facts about which I'm not well-informed. But I have clients who share with the Linux kernel project certain characteristics. One, they have a pretty long history of every tub on its own bottom and each contributor holds the copyright history with one another; two, they don't have a very strong internal governance structure with hierarchical order taking rules about what--who is licensing to whom on what terms, when, how, and they don't document extensively. Okay; let's say that we're talking about a project like that, all right? I've seen many and you've seen some and the Linux kernel is from that point of view one.
Now there are a number of possibilities under US copyright law and let's for the moment assume US copyright law--let's not make the thing unduly complicated. There are a number of possibilities under the US copyright law about how such work might have come into being and the good news which is always the good news that you get from every lawyer all the time about everything is: it really depends, okay?
One thing that a work like that could be--is a collective work of multiple authors, each combining essentially independent parts into an aggregate--not a GPL aggregate but a combined work, a collective work of multiple hands, such as an anthology in the literary world, where the point is to collect a lot of pieces independently arrived at but with a larger meaning or expression that results from placing them together. A collective work is generally speaking license according to an informal agreement of the authors, which agreement may be in writing or may be nearly verbal or may only be indicated by their behavior.
Let's take an example; once upon a time I wrote an obscure chapter in an obscure book about the history of the privilege against self-incrimination in the Anglo-American law from the 13th to the 20th Centuries. I wrote a piece about what happened in British North America at the end of the 18th Century when folks who made the United States decided that they should not be whipped or tortured into confessing things. That they decided that, while also owning people whom they tortured into confessing things producing a certain number of ironies in the history of the privilege against self-incrimination in American law, ironies which are unfortunately now out of the closet and walking around the land in and around this graceful light.
But I wrote a piece about the dead past and I wrote it alongside a lot of other pieces about the dead past in other corners of the Anglo American world written by other people. We put them in one binder. We published it with the Chicago University Press and we informally designated one of our number who happened to live at the University of Chicago to conduct negotiations with the Press about royalties which he did with astounding sloppiness in my judgment and gave away all our pretty much nonexistent royalties forever in return for a few extra authors' copies of the book which I did not get.
But I was bound by his licensing decisions; it was a collective work and he was designated to make a license decision. On those terms you can understand that the thing could be done in a morning. right? Pretty easy?
Now let's take another possibility; such a program could be they jointly authored work under copyright law in which multiple authors have subsumed indistinguishable portions while retaining copyright interests in the work but which is a one undivided whole jointly authored by multiple people. In that event any one of the authors may license the entire work on any terms he pleases, subject only to a duty to account to all the other authors for an equitable share of any royalties reserved or collected. That if you will pardon me for describing it in a single word would be doomed.
So that the kernel or any other free software work falls into the class of being a jointly authored work is a very bad idea unless you propose to license the work in an ITX11 or a very relaxed BSD, because fundamentally you don't have any control over downstream licensing. So I assume, as other parties have assumed all the way along, that the Linux kernel is not a jointly authored work.
There's a third possibility; the kernel could be a collection of works in which all the authors have together licensed to one another under GPL. In other words, each of them filed an independent copyrighted work and each of them allowed it to be combined with other works under GPL, so the whole kernel is held together every brick with mortar in-between consisting of GPL version 2.0 only. Well that's not doom; but it's an inflexible structure. It's pretty much tied to the GPL v2 copyleft and connected all of the pieces when there were put together by everybody who contributed to them.
Which of the three it is--is a question of fact depending upon an understanding of what has been done and what it was that was it ever given stage existing; it's a matter to be shown. This is why it's really important for everybody who cares about free software to stop assuming that licensing is where the hard-wiring is done. In the world where I live, in the business of giving away advice to free software projects in order to make them better for other people to bend and use the license is not the big issue.
The big issue is what's the structure that puts the project together, legally, organizationally, and socially? What goals do you guys as developers have with respect to how you want your project to be organized to run, how much email you want to send and receive, how many hours you want to spend on the telephone, whether you want to have a Chief Administrator or not, and against the background of how you guys want to make software, how do we assure that the right legal consequences follow at the other end?
The time scale of Richard Stallman's thought--may I say an obvious thing--is long;. Mr. Stallman has been around thinking long forever. Mr. Torvalds when he began hacking the Linux kernel together was not thinking long. I'm not criticizing Linus; he's been very clear about that. This was an unintended revolution on his part, which is not a thing you can say about Stallman. The question of how to put a project together was very much on Stallman's mind from the beginning of GNU. He may have been right or he may have been wrong but he had real ideas about how to put a project together. The beauty of what Linus did, as Linus described it in his book and as we watched it happen,was it just happened.
But my practice is about not having things just happen that turn out to be worth billions or tens of billions of dollars at the other end, because if thing were worth tens of billions of dollars at the other end and they just sort of happened in the beginning there's always a chance that they will have happened in a way which is going to cause trouble. Or, because I don't think there's anything in the Linux kernel's way of happening that's going to cause trouble, is less efficient than it should be at repelling trouble. And I think it would be fair to say whatever else is said about the history of the Linux kernel that the history of the Linux kernel was not one which efficiently repelled trouble, which is why the trouble it eventuated wasn't efficiently repelled though it was effectively repelled and it cost a lot of time and money to do it. And preventing that from happening means working with projects while they're young to give them good legal assurance about their situation.
Now you want my guess about the Linux kernel from outside, where I sit? My guess it's a collective work produced by assembling the subsystems and all the contributions to them through a hierarchical process carefully managed by a team of people as evidenced by a decade of the LKML and that there is a whole lot of reserved authority, the sub-system, maintainers, add it to the core developments to make decisions for the benefit of the kernel; that's my guess. But I don't represent the developers of the kernel and I don't speak for them. I'm sorry that the answer was so long. I hope it was helpful.
This article was first published on LinuxPlanet.