Eben Moglen
Chair, Software Freedom Law Center
The world's leading legal authority on open source software reveals the key things you need to know as a developer, vendor or customer looking at open source software licenses.
GCJ: Tell us a little bit about how open source software licensing works...
Moglen: Open source software licenses are designed to address the problem of making sharing possible - either making it possible under the broadest array of downstream uses, or making it possible in a way that protects other people's freedom to share.
There are essentially two classes of licenses in the world. One class has been typified by the historically named 'BSD' licenses. It's a class of licenses that say 'here's some software, do what you want with it, but there's a copyright that applies to this software, it's not in the public domain.' That license effectively says, 'here, share this ... or, put this stuff into a proprietary product and do whatever you please with it.' The people who use and approve of those licenses basically see them as maximizing freedom of use. Because you can use them in a free fashion, or a proprietary fashion - the code under those licenses has been collaboratively shared up until the moment you got it, and your choice is whether you want to continue sharing it or not.
The other type of license is the so called "copy-left" license, of which the dominant example is the "GPL" license. That license says "here's the software, do anything you want with it. But if you re-distribute it or make something out of it, don't give anyone downstream fewer rights than you had in what you started with."
GCJ: Are these open source licenses ever just superficial?
Moglen: They're not superficial. If they have weaknesses, the weaknesses tend to be of two kinds. One, they tend to be US-centric. Two, they tend to be so agnostic about business models that they don't actually ensure much with respect to the long-term rights of the developers. Users are probably pretty well-protected, because the license doesn't constrain them at all. But developers may find themselves in places they don't see fit. For example, many of the people who do free software projects would probably say they don't want to do unpaid work for Microsoft. If they release their code under a BSD or X11 license, nothing would prevent Microsoft from taking that code and embedding it in Windows - which, for example, has happened to code under the BSD license that that was originally part of BSD Unix.
GCJ: Does a licensing choice affect the open source technology itself?
Moglen: As it turned out, those two particular forms of licensing (BSD and GPL) have had significant effects on the way in which software is developed. A good example is the difference between operating kernels under the BSD-like licenses, and operating kernels under the GPL. If we take the set of operating system kernels under BSD-like licenses, we would find free BSD, Net BSD, open BSD, and MAC OS X. That is, to say, a lot of forking - including some proprietary forks. If we were to take an example of an operating system kernel under a GPL, we would find Linux - which is a surprisingly unforked kernel.
It sounds somewhat similar to emerging standards for new technologies. You see all these different standards trying to achieve similar things - where everyone converging on one standard accelerates the technology adoption faster.
Yes, the reason why standards have the tendency to differentiate over time is that the participants in the process are not individuals - they're profit maximizing institutions who obey a raison d'etat which implies competition. So if they are in a position in which they want to diversify themselves, they will, with a kind of iron logic. They don't sacrifice to one another, because they have an intrinsic commitment to profit maximization. A GPL software project does not benefit from forking.
GCJ: How do these lessons apply to Grid?
Moglen: When we apply this to Grid systems, we recognize that when you scale the number of processors very drastically, only zero cost marginal licensing can be used. You can't license on non-zero marginal cost software for use on clusters of thousands of processors. So whatever you have, you must have a license that scales for users, at zero cost of marginal acquisition.
Applications are typically licensed on a per node basis - what happens when you start talking about different resources sharing applications, where it becomes much less rigid and definable?
If the code you're talking about were only used in such environments, you could make a contractual rule governing its activity. The issue with a service oriented architecture is that the code is not distributed. That data comes over the wire and goes out back the wire, without the code that processed that data necessarily having moved.
So this arrives in the GPL setting in the following ways. X writes a web app under GPL and goes into a business model of providing that web app to people over standard, over-the-wire protocols, like HTTP. Now your competitor down the street takes your web app, and goes into business providing services, in competition with you. However, he modifies the code so the service is more sophisticated or better adapted to the market. He does not re-provide those changes to the world. When questioned, he says "I don't have to - I'm not distributing the software. Because my users don't get a copy of the code - they just provide me inputs and I give them outputs."
And that's a defensible proposition - because no distribution of software occurred. Copyright law, from that point of view, didn't touch it. Nobody got any source code.
GCJ: You recently kicked off the Software Freedom Law Center - tell us a little bit about what you're up to.
Moglen: Certainly the question of web services under GPL3 will be a very important part of our activity under GPL3 development for the Software Freedom Law Center. I expect us to address this very question as part of the re-drafting of GPL. We are very concerned with the question in the embedded context in the future.
How do users know what their rights are? In a world of pure software distribution, it used to be really simple. Programmers were the people who got the code, and if you put a file with the license terms in the top layer of the distribution, they could read them. But in a world where every room has multiple devices with software inside, how do you know what your rights are in any of that software?
We are also very concerned with trusted computing. What happens if hardware begins to reject modified software because it isn't signed by someone considered friendly enough by Walt Disney?
For grid, I believe the copy-left idea is of great importance. The acquisition cost for software in the grid can be driven near zero by any free software license. Any license which gives the right to copy and execute will be sufficient to get software loaded to the Grid. The real question is how can a Grid made of flexible, heterogeneous parts that continue to all work together over time. It is here that the homogeneity-inducing quality of copy-left licenses like GPL becomes particularly important.
GCJ: What's your opinion about the Apache 2.0 as a good license for the Globus Toolkit?
Moglen: The problem of course is that the Apache developers want their code to be embeddable into proprietary work - which is for example one of the reasons why IBM is so interested in Apache. Of course, IBM is also particularly interested in the Grid. If the Apache 2.0 license over time meant that there came to be more and more sub-flavors of Apache, would that begin to cause harmonization instabilities in the Grid? The IBM answer I think would be no - it's not a problem, because web servers have an address. So each and every Apache-infused device in the Grid, only has to be able to obey the protocols like HTTP, HTTPH, SSL. As long as it does that through open protocols and open standards, there's no problem.
GCJ: How long does it take implement a new license if you're unhappy with the one you chose?
Moglen: Developers do it all the time. The problem is that it's too easy to implement a new license. Large-scale users in the IT industry are beginning to pay a cost which developers did not foresee. Developers did not foresee that in a world of enterprise adoption of a stack, each license in the stack exponentially increases the cost to the enterprise user. If you're the Bank of America and you want to have a stack that runs from Linux at the bottom as the kernel of the OS, through LAMP and all the way to your code on top - then if there's one license that covers the whole stack, you have one set of risk assessments and one set of legal clearances. If there are two licenses, then you have four sets. And if there are 18 licenses, then you're in trouble. One of the things they will look to Software Freedom Law Center to do is to help new projects chose from existing licenses wherever possible. We will say to our clients that there might be ways in which optimally you would make a new license here - but you will create disadvantages for customers and users downstream. So why don't we see if we can find a way to live with this existing license, so as to make it easier for customers who have adopted your software, which after all is what you want.
GCJ: Do you think that the tech industry can self-govern itself on software licensing, or will it need to be legislated at some point?
Moglen: I think that in the present moment in the United States, given the way in which American politics work, legislation is not a promising approach. On the contrary, it takes enormous levels of legislative intervention to propertize any area of science (including computer science) for any length of time. And without the kind of financial pressure created by drug company money, it wouldn't work. The patent system is presently sustained because pharma is rich. As pharma becomes less rich, the patent system will die. The software world has already transformed in the last 20 years. It is not going to go in a more proprietary direction. I know no serious thinker in the world who thinks that Microsoft's power is going to grow - or that after Microsoft, there will arise a software power more vigorous and more exclusionary than Microsoft. Over time, things will get more open, not less open.
1
From July 20005