Slashdot and GrokLaw, the major homes for the community's individual members, bulge with posts. But reaction from the corporate wing of the movement--starting with its semi-official spokesman, the Linux Foundation--is silence.
Why the companies hit the mute button just when one would expect a coordinated chorus of huzzahs is a matter for speculation, but here is a hypothesis: Maybe because after two years of drafting, redrafting and re-re-redrafting, the product finally went to the corporate general counsels, and these folks promptly went ballistic over the ambiguities, uncertainties and risks.
To illustrate their likely concerns, focus on one major problem: Will content companies, such as movie, music and book producers, and those who want to provide them with information technology services, be able to attach Digital Rights Management (DRM) technologies, a.k.a. Technological Protection Measures (TPM), to programs that are licensed under GPLv3? Since every Linux distribution contains many programs controlled by the Free Software Foundation, this presents no small issue.
If GPLv3 and DRM are incompatible, then no one will be able to add DRM to a Linux system, whateverabout putting the kernel under v3.
The FSF is strongly hostile to DRM. The first draft of the v3 revision expressed this philosophy directly: "This license intrinsically disfavors technical attempts to restrict users' freedom to copy, modify and share copyrighted works. Each of its provisions shall be interpreted in light of this specific declaration of the licensor's intent," and, while the words may have been toned down, the anti-DRM tune remains loud and clear.
The FSF's position on DRM is not new. What is new is a fundamental change in the reach of the license terms that makes that hostility more of a threat.
In the earlier version 2 of the GPL, the focus was on redistribution of covered code. As long as a user of a 'GPLed' program did not transmit the code on to others, it was free to do what it wanted. It could attach propriety applications, tweak the code internally, add DRM, whatever. None of these actions triggered any obligations under the license. Such bright lines make corporate lawyers happy.
The current version 3 changes the situation by adding anti-DRM provisions that could reach into a user's internal operations even if the user does not redistribute code.
This crucial shift is accomplished in three ways. First, via wording that says anyone using code covered by the GPLv3 automatically gives up any rights to use the anti-code-cracking provisions of the Digital Millennium Copyright Act against someone who changes the code for the purpose of getting around any attached DRM programs.
Would it work? Would a waiver given by a code distributor bind those later in the chain of distribution? Probably. Would the waiver matter? Maybe.
A second anti-DRM measure contained in the same discussion says that selling or renting a consumer electronic device with 'GPLed' code in it (unless it is in ROM) constitutes a distribution that requires the code be both revealed and modifiable. Translation: If that code contained any DRM measures, these could be found and removed.
Again, would this matter? Well, what about cell phones, which are subsidized by wireless companies and rigged to be specific to the subsidizer's network. Under this provision, a program to remove this limitation could be sold freely, which would certainly upset the wireless companies, and possibly end the subsidies.
Yet a third anti-DRM arsenal is buried in the "definitions" section of the draft discussion. This is a requirement that code dynamically linked to GPLed code is also subject to the disclosure requirements of the GPL. Thus, even if DRM were included in a separate program, it could be covered, depending on how far, exactly, this murky requirement extends.
You can argue about the import of these provisions. Open-source advocate Bruce Perens was recently quoted criticizing claims that GPL 3 invites legal risks. Earlier, he wrote that GPLv3 allows DRM and that anyone who says otherwise is full of FUD. But there is disagreement whether that's true. In none of the FSF materials is there any discussion of the specifics--of watermarking, High Bandwidth Digital Content Protection, deep packet inspection, acoustic fingerprinting--and how they would be affected. It is all abstraction, provided against a background of bitter hostility.
In fact, the addition of these murky provisions creates huge uncertainties about the impact of the license on content creators' ability to incorporate DRM. Can you imagine an IT company that risks having to inform the maker of a $100 million movie that it just gave away the creator's right to protect the work--solely out of dedication to the open-source community or because of the legal advice offered in a blog post?
The late lights will keep burning at the Linux Foundation as they try to figure out what to do about this not-so-little problem.