A Group Conversation with Eben Moglen, Part II - page 4
Software as Service and GPL 3
Question: One thing we didn't touch on the other day or this morning is corresponding sources and the boundaries of that in GPL3.
Moglen: I'm a little bit surprised at the depth of intricacy of concern about all this, but let me try and say something about it. The problem which we had from the very beginning of the GPL, before I was working with Stallman, before GPL Version 2 was out in fact.
Because GPL was meant as a license which would allow the development of free programs on un-free operating systems. It had to be; there were no free operating systems available. That was the whole point of Stallman's idea in the first place. So, there was always an assumption underlying the distribution of any GPL program that you might not be able to provide the full source code of everything needed in order to hack on that program. In particular, in every UNIX like operating system towards which GPL code was originally aimed there were various libraries required for linking an application of any kind into the system by providing access to kernel APIs from user-land and doing other necessary things in connection with living on the system. It was therefore a necessity from the beginning for GPL to say when you provide people all the source code that they need to make this product, to make this program over--to hack on it and modify it and share the modifications--there's some source code you're not responsible for giving because it's in system libraries, because anybody who can make them on the program can be assumed to have that code available because making the link is a thing which the system owner or generator or architect or producer wants you to be able to do.
And in saying that you don't have to provide the source code for it, when you give the program to somebody we're not allowing anybody to engage in any significant evasion of copy-left, because we're only talking about linkage with libraries that contain system APIs. And so nobody is going to be in a position to make a proprietary enhancement to the program by modifying the system APIs underneath and putting these enhancements down there inside the system that would be too big a job. So, GPL from the beginning, assumed that there was some class of code, namely system libraries that were accepted from the source code you had to give people when you gave them everything they would need to build and make modifications and execute.
Over time, it became clear that the language of GPL2 though rather intricate on the subject, was both a little over inclusive and a little under-inclusive. It was clearly giving permission for some things that might be evasions and it was not clearly enough giving permission for some things which it was important to permit. In particular, some who read the license--to wonder whether it was acceptable to compile a GPL program and run it on a system with a free but not GPL-compatible C library and distribute the source code of the application without distributing the source code of the free but non-GPL compatible C library under GPL. This became an issue because the C library for Solaris was under CDDL, a free but non-GPL compatible license. And as parties began to fool around with the activity Ian Murdock is now finishing--that is, the idea of building a Debian user land on top of Solaris--people began asking well but is there going to be a problem building the Debian user land with the C librarty under CDDL free but not GPL compatible? And some parties on the Debian legal/mechanical interpretation list said yeah; there's a problem. That's not what GPL2 permits. So it became necessary to clarify a little bit both as to under and over-inclusion what the system libraries exception means.
But there's also a profound change in technology in the world. Operating systems decline in importance and operating environments above the layer of the OS and below the layer of the relevant application Layer 7 activity become more important. And so parties say are you sure that this system library's major components of the kernel, window, and system, and etcetera is the appropriate place to define the boundaries of what source code need not be provided because it can be assumed to be there? And because the user's ability to modify copy and share is not significantly affected by failure to have the source code conveyed under GPL by the party conveying the GPL application.
So effort was put into an attempt to consider rewriting the definition of corresponding source code. Rather complexly, there was also a period in which anti-lockdown, anti-DRM elements had come to rest in the definition of corresponding source code as well and that began, in my judgment, to bloat the complexity of the corresponding source code element of GPL3 a little too much. The change in discussion draft three to move the anti-lockdown, anti-DRM components to section six allowed some more simplification of the corresponding source code section, which has generated some more highly sophisticated questioning about where the boundaries ought to be in a world where the stack is no longer the operating system plus an application layer on top and there's still conversation going on. So here is one of the cases where Mark's rudely asked me a question about something I can't quite declare as finished. We will be thinking more about this highly ultra-specialized Inside Baseball aspect of GPL in the next two weeks and those who want to take a look at GPLv3.FSF.org at the corresponding source code section of section one will find there everybody's comments since the beginning of the draft with intensity highlighting. Look for the heavy red mark that tells you lots and lots of people are working away in there and come and give us a comment and tell us what we need to know from your point of view.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.
- 1Linux Top 3: Ubuntu 14.04, Debian Gives Squeeze More Life and Red Hat Goes Atomic
- 2Linux Top 3: CoreOS, Oracle Enterprise Linux 7 and Ubuntu 14.10
- 3Linux Top 3: Debian Dumps SPARC, Ubuntu Takes Over Linux 3.13 and the Core Infrastructure Initiative
- 4Linux Top 3: Fedora, Ubuntu and Gluster Lose Community Leaders
- 5Red Hat Enterprise Linux 7 Finally Hits the Big Time