July 31, 2014
 
 
RSSRSS feed

A Group Conversation with Eben Moglen, Part I - page 2

How GPL 3 Relates to Non-Lawyers

  • May 17, 2007
  • By Brian Proffitt

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.

Sitemap | Contact Us