Clearing up anti-GPL3 FUD
Mar 26, 2007 — by LinuxDevices Staff — from the LinuxDevices Archive — views
Foreword: This guest column describes in plain language how Version 3 modernizes the GPL, while remaining consistent in intent with earlier versions. Additionally, it debunks a few common GPLv3 myths, and suggests how the Linux kernel itself could someday wind up adopting the revised… license. Enjoy . . . !
by Bruce Perens
There's been a lot of talk about GPL version 3: whether it goes too far to be acceptable to business, whether the Linux kernel developers will ever switch to it, whether our community will fork or undergo unrest over it. Much of that talk is based on a poor understanding of the GPL3 terms, and with release of the new license imminent, it's time to clear that up.
Confused objectors to GPL3 state that it won't allow the Linux kernel to be used on a system that implements DRM, and that GPL3 will compel manufacturers to “give away their keys.” If Linus Torvalds and the kernel developers still believe this, they're wrong.
The intent of GPL3 (and most other Free Software licenses) is to give you the right to modify the covered software. GPL version 3 takes more trouble than other licenses to make sure that this right actually works with embedded systems. It essentially trades the makers of those systems the right to base their devices on our great GPL software, in exchange for the consumer's right to make that hardware run new and innovative programs that weren't envisioned by its manufacturer.
GPL3 does not prohibit DRM, and does not require that the DRM be insecure or unreliable. What it requires is that the DRM must not break the GPL software or lock it down, and must continue to work to play media if the GPL software is modified.
A system with GPL3 software and DRM would have to allow the GPL software, for example the operating system kernel, to be replaced. It would have to allow the system to boot after such a change, and it would have to continue to allow the system to play media or do whatever the DRM would otherwise do before the change. It would not have to provide access to the unencrypted media stream, and there would be no requirement to release cryptographic keys as long as the DRM was implemented to comply with GPL3's requirements.
If the Linux kernel was under GPL3, a manufacturer would be prohibited from using DRM to lock down that kernel so severely that we'd be unable to change it, as the Tivo locks it down today. But that doesn't mean that you can't have bullet-proof DRM to restrict media using Linux and GPL3, and it wouldn't prevent Tivo from using new kernels. It just says where that DRM must be located: anywhere that it can live without removing the user's right to change the GPL software.
If GPL3 is applied to the operating system kernel of a system, there are four places where you can put DRM in that system and remain within compliance with GPL3. Those places also happen to be the best, most secure and reliable places to put the DRM from a technical standpoint, regardless of the license:
- In hardware — This would usually be an application-specific integrated circuit or a programmable logic array that interprets encrypted streams on the way to an audio or display device.
- In a coprocessor — Most cellular telephones that offer PDA functions (and PDAs containing wireless devices) have two or more CPUs, generally an ARM9 running the user interface and applications, and an ARM7 that runs the wireless data-link layer or the GSM stack. You can put the DRM in the processor that isn't running the kernel, and then the GPL component just talks to a well-defined interprocessor link to the external CPU that runs the DRM. The GPL obligations don't cross that link.
- In a kernel under the kernel — Microsoft XP and Vista have used this architecture: the core of the DRM system lives in a microkernel called the “nib” that lives under the real kernel, and hosts the real kernel as the kernel would host a user-mode application.
- In a user-mode program — The GPL obligations on the license of the kernel don't transmit across the system-call interface from the kernel to an application hosted by that kernel
Many have interpreted that the GPL 2 has always made the same restriction on DRM that is stated more explicitly in GPL 3. I've always advised my strategic consulting customers to make their technical plans assuming this is so, rather than have it decided in an expensive lawsuit. The four places for DRM that I state above apply equally to GPL 2.
Another oft-heard objection to GPL3 is “GPL 2 is good enough!” But GPL has never stood alone; it has always depended on the local interpretation of copyright and other law to give it force, and those things change over time.
When the GPL was written, there was no web, music came from phonograph records, video from tape, and rather than DRM there was rudimentary software “copy protection.” The renaissance of microprocessors, software, the web, and digital media worked a tremendous change in the law with many changes to copyright, patents, the nature of consent, contracts, tear-open licenses, and copyright permissions. And there have been many trials over those years that added interpretation to laws that GPL 2 depends upon. As the law changes, GPL must change to keep up with it, or it will become increasingly un-enforcible.
In the Novell-Microsoft agreement [story], a loophole was constructed by Microsoft and Novell's attorneys, one so new to us that the first two public drafts of GPL3 contained no provision to repair it. This experience shows that GPL must continue to grow just to stand still. To freeze on one version would act to erode its protections over time.
And what about Novell-Microsoft? Will there be a provision to block that deal in GPL3? How will it work? Richard Stallman announced on Monday March 19 that GPL3 will contain a provision that blocks the Novell-Microsoft deal. It works this way: if any entity that distributes the software arranges to protect a particular group from patents regarding that software, it must protect everyone. This mends the loophole exploited in the Novell-Microsoft agreement without being discriminatory or unfair.
What does this mean to Novell? It won't keep them from using existing GPL 2 software in its present versions. But it may freeze them in amber as an example of the state of software in early 2007, as the rest of the Free Software community and Linux distributions move into the future. Torvalds is loath to change the license on Linux right away, but critical programs in the Novell system are directly owned by FSF: GLibC, the fundamental library that every program depends upon, the C compiler and other key components.
Projects not owned by FSF will also make the switch: the motivation of Open Source programmers to release new code to the public is in part dependent on the enforceability of the GPL's share-and-share-alike terms, and GPL3 will offer the best continued enforceability.
A majority of Open Source projects choose the GPL, and a share-and-share-alike paradigm, rather than the BSD/Apache flavor of license which is an unconditional gift. Many developers would just stop writing if they couldn't enforce the sharing part of the equation, they'd feel as if they were being taken advantage of by corporations and Linux distributions, like some sort of unpaid employee. The majority that feels that way will tend to switch their projects to GPL3.
The GPL is also a very good license for businesses like MySQL, because it facilitates a dual-licensing paradigm in which a customer can pay a software creator rather than share additions that the customer makes to the software. Expect those companies and projects to switch to GPL3, once they study the final version.
But how can the Linux kernel project, with its thousands of developers, change its license? We can't even reach them all, and some of those developers are dead and their estates don't know software licenses from driver's licenses. But changing the license is easier than most people think.
First, it's not a fundamental change: the intent of GPL 3 is that of GPL 2, the change is in the implementation. Given that, what would be required for such a change would be for Torvalds (or someone else) to publish his intent to start making releases with the new license, as a legal notice. A certain number of people would object, and they would have the right to require that their contributions be removed from the new release.
The kernel team has never been loath to replace code when necessary, and never slow to handle the job, no matter how large the item to be replaced. Just look at the replacement of Bitkeeper with “git”, a big job that took a ground-up rewrite and yet was working in five weeks. So, code belonging to GPL3-objectors would be swiftly dealt with.
After some time passed, the release would happen under the new license, and life would go on. There is precedent for this, as Torvalds has already made two significant changes to the prelude to GPL2 on the kernel, publishing his intent and then making a release.
But will the kernel team ever switch to GPL3? Linus Torvalds and some other kernel team members don't like it today. But as I've presented above, their reasons to dislike might not really be valid. One thing to Torvalds' credit: when he's wrong, he can be convinced of that eventually. But sometimes it takes years. Going by history, I think that we could wait one or two years to see the kernel team see fit to switch to GPL3. Even if they don't, so many other important projects will switch to GPL3 that it is sure to be an important factor in our future lives.
[This guest column is derived from an essay originally posted on Perens's Technocrat website.]
About the author: Bruce Perens is a leader in the Free Software and Open Source community. He is creator of the Open Source Definition, the manefesto of the Open Source movement in Software. He's founder or co-founder of the Open Source Initiative, the Linux Standard Base, Software in the Public Interest, and No-Code International. Perens released his first Free Software program, Electric Fence, in 1987. He is creator of Busybox, which has spawned its own development community and is part of most commercial devices using embedded Linux.
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.