Views on the GPLv3 hoo-har

Short URL:


There has been a lot of hoo-hah recently regarding the pros and cons of certain aspects of the drafts of Version 3 of the GNU General Public License from the Free Software Foundation. The originator of the Linux kernel, Linus Torvalds himself, is playing a role here. Unfortunately, each side has taken to the ploy of misrepresenting the other’s points. Arguments are getting heated to such an extent that you need to wear an asbestos suit just to look at the issues. However, on examination, not only do I find that both sides have valid issues but I also believe an obvious solution exists that will make most, if not all, satisfied and the world a less flame-ridden obstacle course.

First, the problem. The GPL (versions 1 and 2) was designed to guarantee four freedoms of copyleft for the work and its derivatives. These are:

  • Freedom 0: The freedom to run the program, for any purpose
  • Freedom 1: The freedom to study how the program works, and adapt it to your needs, access to the source code is a precondition for this
  • Freedom 2: The freedom to redistribute copies so you can help your neighbor
  • Freedom 3: The freedom to improve the program, and release your improvements to the public, so that the whole community benefits

Access to the source code is a precondition for the above, especially freedoms 1 and 3.

These are further described here. The GPL as it stood guaranteed these reasonably well for a decade, or just over. But then came the “evil" Digital Rights Management (DRM for short) technology, and TiVo in particular.

I must say that I am not going into the morals of copy-protecting movies, TV and music here, or even closed proprietary software. My interests only concern the treatment and guarantees of free software, and what is best for all regarding that. I am most certainly not interested in advocating or believe in assisting piracy.

TiVo use free software licensed under the GPL for their DVRs, and they comply to the terms of the current GPL (v2) by providing source code from a page on their web site. However, users of the TiVo product are denied, in part, freedom number 3 above because although there is nothing stopping a user from changing the program they would not be able to run the new version on their machine because it contains DRM technology and the executable needs to be digitally signed with a private key by TiVo itself. Also, each TiVo machine uses a separate public/private key pair so in reality freedom number 2 above could be claimed to be denied.

For those unfamiliar with the mechanics of how public and private keys work, I will digress into an overview as to how they work. For those who are clever or who are already experts in the field please either skip this and the next two paragraphs or ignore the massive over-generalizations and simplifications I have included. Public key cryptography relies on an algorithm that uses two keys, which I will call “Key A" and “Key B" due to a lack of imagination. These are known as a “Key Pair". If a piece of information is encrypted using “Key A", then “Key B" is needed to decrypt it, and if “Key B" was originally used then “Key A" is required. The clever bit is that if a message was encrypted with “Key A", then someone who does not know what “Key B" is cannot read it, even if they know what “Key A" is. The same applies to “Key B", you need to know what “Key A" is to decrypt those messages, knowledge of “Key B" is irrelevant for that.

The way TiVo DRM works is that when the “Key Pair" is generated TiVo keeps “Key A" itself secret as the “private key", and burns “Key B" into the processor on the DVR. When it runs an executable it takes a “Hash Sum", like MD5 or SHA, of the executable. It then finds an encrypted value, known as a “digital signature", it has in a master file on the DVR for that executable and decrypts it using the public key burnt on the processor. If these two values (the hash sum and the decrypted digital signature) are not the same it does not run the program but gives what many would consider a rude message.

In order for the encrypted value to get onto the master file, the “Hash Sum" of the executable needs to be encrypted with the “Private Key", which only TiVo knows, so only they can perform that operation. Therefore, TiVo can choose what can and cannot be run on your machine.

That is the end of the explanation. Back to the entry...

The Free Software Foundation are not happy about this. The whole point of their licenses is that the user decides what can and cannot be done with software on their machine, not the vendor. Their solution is to create a new version of the GPL, version 3, that will prevent TiVo and those like them from prohibiting the freedoms the GPL was designed to ensure. While they are at it, they are also putting in other clauses in an attempt to prevent patents, as well as anything else they can think of, from doing the dirty.

To many people’s surprise objections rose from some free software programmers, most notably Linus Torvalds and some other kernel developers. There then followed some very emotive exchanges and great snarling and gnashing of teeth which has increased the temperature of many a forum. I, a self proclaimed hero of the Blogosphere, will now attempt to dive in and uncover the root of all this hullabaloo.

First to dispel a myth, the kernel developers to my knowledge have not objected to “Section 3" of the new GPL draft, nor any of the specific DRM or Patent sections, but to a paragraph in “Section 1", the definition of the source code that needs to be made available. Namely, this paragraph....

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source.

Inclusion of that would mean that any kernel licensed under GPLv3 cannot be used where DRM is required for a secure environment. Please remember that not all DRM is evil; medical computers are often cited as examples of where it is a positive. However, the argument is that use of DRM should not really fall inside a software license. Further, as long as the software is accessible and readable by the user, as well as modifiable to be able to be run on machines without DRM or where the private key is known, then what business is it of the software licensee? Answers on a flame please to the comments section below...

Also, I think it is worth including that the current draft of the GPLv3 will not protect against performance of these shenanigans on my free software projects, nor do I believe it ever can. I write some free software, and looking at the download figures there are some who it appears actually find it useful. I primarily distribute source code to a POSIX (I think) standard and leave it up to the end-user to compile.

Imagine, say, a fictitious organization called TrustMe Inc.—a DRM-oriented, good-for-nothing, profiteering and unethical company—comes along who would like to include a particular version of my program in their list of “allowable" executables. What they can do is give, nay, let’s say sell, a digital signature for that version of my program giving me none of the profits. They can even get a “friend" of theirs, or someone not connected to them, to pre-compile that version of my program and to distribute it (source and all) under the GPL.

The scenario we have here is that users of TrustMe Incorporated’s equipment can obtain my free program from the “wild", but in order for them to use it, they need to pay TrustMe Inc a fee for the digital signature. TrustMe Inc has not infringed on the GPL as they have not distributed any software, the “friend" has not as they are doing nothing to restrict use of the program, and he is not necessary anyway, yet the user has been denied freedoms of the copyleft, and TrustMe Inc. has profited by controlling work I, as the author, specifically want to be free.

For this restriction to work for TrustMe Inc. would need to restrict the kernel that is run to one approved by them (like TiVo does), and it may seem like releasing the Linux kernel under GPLv3 will take care of this. However, there are other POSIX kernels out there that are not released using GPL restrictions, such as the BSDs or even OpenSolaris. At a push TrustMe Inc. could even purchase one of the closed proprietary ones.

A keen observer will note that TrustMe Inc. can only control executables that run on it’s own equipment. A solution is for the end user to simply not purchase it. However, the model of this suggests that TrustMe Inc. could subsidize the initial purchase cost of the equipment using revenue they are obtaining for the use of it. The lower capital cost would attract the more non-caring purchases at a cost of the market share to the hardware vendors using a more free model. Look at the games consoles market.

Please note: “TrustMe Inc." is an imaginary company I have just dreamed up for the purposes of this entry, if there happens to be a real company by that name my example here bears absolutely no relation to it whatsoever.

The solution to the above? I cannot see one in the short term. I believe education and awareness is a key here. People don’t like you charging for things that should be free, and it is a matter of telling people that GPL software IS free. That would, I hope, deter people from restricting free software.

The solution to the flame war? That is easier. There is no problem including the aforementioned paragraph in Section 1 of the GPLv3, but be aware I have just shown this is easily circumventable. Also don’t expect kernel developers to be too keen on adopting it, what you are doing is devaluing the kernel by restricting the type of hardware that it can be run on for no benefit whatsoever. All we need do is make room for a license with and without that paragraph. Also, on a practical note, it would be near impossible to change the license radically for the Linux kernel, too many copyright holders are involved.

It comes down to right vs. right. It’s right for the Free Software Foundation to try and guarantee the copyleft freedoms of GPLed software, and it’s also right for the kernel developers to wish for no restrictions on the hardware that kernel should run. Practicalities dictate the best way forward. The kernel should remain GPLv2, or a version of GPLv3 without the offending paragraph, and applications can adopt the GPLv3 with the paragraph to make the “TrustMe" scenario described above more difficult to adopt.

Whew—it’s hot. Where’s the ice?....



Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

You write, "Inclusion of that would mean that any kernel licensed under GPLv3 cannot be used where DRM is required for a secure environment. "

--- If I get the source code for the Linux kernel, can I not do whatever I like? Is it not only at the distribution point that the license kicks in?

Terry Hancock's picture

If I get the source code for the Linux kernel, can I not do whatever I like? Is it not only at the distribution point that the license kicks in?

You can do anything that is otherwise legal. The problem is that signing your code with a private digital key that belongs to the platform DRM company is an illegal circumvention of their DRM system, and thus illegal under the DMCA. That's the “gotcha". Only by paying for that key from that company can you sign your code so that it will run on the platform.

Terry Hancock's picture

I think your runaround case is pretty artificial. No company would be happy with this kind of key-selling arrangement, because it would require the end-user to consciously install the software. Which is precisely the opposite of what such "blackbox" vendors want to do.

What you're describing is a similar situation to what Debian has done in the past with "non-free" downloadable programs: they would write an "installer" package, that would, as it installs, download and install the non-free package. This allowed them to technically avoid "distributing" the file (which would be illegal), while making it seem as if the package were included in the Debian distribution.

It worked, but it was fragile and hard to maintain. Your hypothetical company would have the same sort of problems. It would be easier for them just to open up the platform.

Even if all the GPLv3 does is force that kind of runaround, it will have done a pretty good job of discouraging DRM platforms, since it will make them that much less convenient.

I think the real concern is that the new GPLv3 wording does require these kinds of business model changes in order to work, and after 15 years of finding business models that work for free software, pragmatically-minded people are inclined to fear rocking the boat. And I don't blame them. Business models for free software have worked, but they've always been a bit marginal. There's reason to fear that a little bit of slippage could run you right out of business.

The Linux kernel developers are sensitive to this, because they're very much aware of the significant commercial contributions to Linux in recent years, and so it follows that they don't want to see those beneficial relationships harmed.

On the other hand, DRM does have the potential to do massive harm to the industry if it is ever adopted wholesale (as certain deep-pocketed interests certainly want it to be).

One intriguing idea I've had is that the GPLv3 Section 7 now provides a very simple way to bolt on certain common requirements and to remove just about any of them. The new version of the LGPL demonstrates this. It would be trivial to envision a "GPLv3-minus-DRM Keys" (maybe a "Kernel Public License/KPL") that would remove the "Corresponding Source Key" requirement for those who don't like it. That might defuse the situation a bit, by providing a less-controversial alternative, without throwing out other changes in the GPLv3.

However, based on their recent statements, I don't think the Linux kernel folks are going to adopt even that. There seems to be a pretty strong desire to stick with GPLv2. Fortunately, this has few consequences for those who like GPLv3. The kernel is only one element, and as there remains a "platform exemption" in both GPL versions, the platform copyleft doesn't affect the apps that run on it.

Of course, despite FSF hubris about the importance of the "GNU system", the folks who want to "TiVo-ize" their Linux blackboxes, can and no doubt will just use Busybox or a BSD-derived set of utilities on top of the Linux or even BSD kernels. Those might even be technically better alternatives for their platforms.

There is of course, a subtext in this whole discussion that the hardware is unalterable and that the consumer has little ability to make his own or acquire open hardware. This is an assertion that the embedded hardware is not very free, largely due to monopolistic and industry trust tactics.

However, it so happens that hardware is continuing to get more commoditized and cheaper to create in short runs, so that there is likely to be a new boom in open and free hardware in a few years. The fear of a "DRM Dystopia" just feeds this new trend, as developers and savvy users start to seek out alternatives. As more and more examples of the absurd ills of closed and locked-down systems pile up, it becomes easier and easier to sell people on the advantages of free systems.

I'm personally betting that DRM will die that way: with the platform manufacturers who pushed it realizing that they can't compete, and giving up on the game.

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

The GPLv3 allows authors to add additional permissions (v2 also did that, it only forbids further restrictions). So people who like DRM could distribute their software under GPLv3 + permission to ignore the key part of the source code definition. Wouldn't that satisfy Linus & co ?

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

I think the whole Tivoism thing results from an ambiguity in the GPLv2.

However, I think if everyone agreed to interpret the GPLv2 relative to it's intended purposes, then a judge would have to rule Tivo in violation.

How is this any different than Micrintosh Inc. distributing a completely encrypted source distribution, where you couldn't even see the source? People laugh and say, "What, that's an obvious GPLv2 violation... You can't even read the source in order to change it... It might as well be a stream of zeros..." To that, the vendor then says, "No, it's not like that. Just pick up our FREE MacdowsPC and you can read, modify, and execute anything from the kernel to the browser. Just log into our website from your MacdowsPC and go to the Macdows Online Program Editor. When you are done making you're changes, simply click "Add to Cart!" (ten cents a line for most programming languages. Contact us to become an affiliated software vendor) and when you check out you will be directed to a link to download the encrypted executable. Heck, you can even write your own programs from scratch, in any license, and anyone with a MacdowsPC can run your programs too!"

In both instances, both vendors (Micrintosh and Tivo) are distributing the code for free, they're both technically allowing the code to be viewed and even changed, but they're RESTRICTING the utility of that code (ie. it's execution in it's targeted environment) to only their wallets. No other derivation of their particular distribution can be of any further utility except when deemed profitable by the vendors. Not even when it's just for fun.

The kernel crew likes to point out that we shouldn't _Assume Purposes_ on what the end user will have for the code -- indeed, the GPL intends that. But that is what Tivo has violated. Subsequent end users of the code can no longer re-purpose the code, FOR ANY PURPOSE ALLOWED BY THE GPL, without paying out the nose to %S (for added effect, %S = Hardware Monopoly, Biopoly, or Triopoly).

The code is then hijacked. The free software and open source process that created the FOSS ecosystem, and it's underlying licenses, are short circuited -- diverted from the goals for which the software, and it's rules of distribution, were created.

Are we going to let our software, our intellectual real estate, be appropriated by the hardware giants?


alien d0t empathy a+ gmail d0t com

taime's picture
Submitted by taime on

I can't see situations where DRM could be useful. Like for GMO, Medical interest is invoked for justifying questionable practices.

Ryan Cartwright's picture

I too fail to see where there would be a good use for DRM especially in the medical community.

Encryption of data to protect it from unauthorised parties is one thing (and sensible) but that is not the same as DRM, certainly not in the examples you (Edward) discuss. You speak of DRM in terms of application restriction not data. Why would a medical application require such a restriction (assuming it was not under a proprietary licence)?

Come to that can someone explain why ANY application would require DRM which interferes with the customer's use of their own data?

Most DRM in use today restricts what the user can do with data for which they do not hold the copyright. This seems like a good idea except that most of the uses today circumvent the fair usage part of existing copyright law and are used to simply exploit the end user. It also falls down when it comes to an end user using the data they have created for use on the hardware/software containing the DRM.

DRM in a medical enviroment would benefit nobody except the software vendors - but then perhaps that's the point.


Terry Hancock's picture

Probably the best example of "non-evil" DRM is a certification system.

Medical or safety devices make good examples, because they clearly show the importance of values which might trump your insistence on being able to modify the code.

It's easy to imagine a medical device, which, if programmed correctly, will save lives, but if programmed incorrectly, will kill or injure people.

But because this is an internal matter of programming, you can't expect the end user to be able to tell this on inspection.

What he can do is see if the device has a certification mark provided by a certification authority who has taken the time to do a due-diligence study of whether the programming of the device is safe. That mark is a kind of TPM, and it reflects our trust in a trained professional authority over our trust in the end user.

But if we insist that any end-user has the ability to reprogram the device without making it obvious that they have done so (i.e. by removing the certification mark) then we've defeated a significant safety precaution and a means of ensuring regulatory compliance that is intended to protect the public. So anti-TPM here is a bad thing.

Moreover, it's not clear whether simply "indicating" that the device is not compliant is sufficient. It may be necessary to render it incapable of operating so that it really can't be misused.

To see why this might be so, consider the fences they put around power substations. Anybody with half a clue would read the "High Voltage" sign and not even try to go near that equipment. Nevertheless, power companies are required to make an effort to physically block anyone who might get hurt from entering the premises (maybe they can't read, have extremely poor judgement, etc, but we are not excused from protecting them to from harm). In fact, if those measures are intentionally defeated by an idiot who tries very hard to electrocute himself, the power company will still get sued for liability in the case.

Likewise, merely flashing up a BIOS message "kernel not certified" may not be sufficient to excuse a medical equipment provider if a hacked device injures someone because of non-certified code being run on it.

Now you might argue that this is dumb, and the liability laws are what's at fault. And maybe you're right. But why does that kind of discussion even come into a discussion of software licenses? Because we're over-constraining the problem by restricting users' freedom. These constraints force them not to be able to meet their legal obligations, which is not a position I can easily term "free".

This would make us just as bad as Microsoft which sells medical offices on computers with "phone home" software that violates patient privacy laws. It tries to put the user in violation of the law in order to serve the needs of the producer.

I'm sure this is not the last word on the subject, but this is the kind of example that is usually cited to defend the idea of TPM measures being a "neutral technology" rather than "inherently evil".

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

DRM makes no more sense in medical technology than elsewhere.

There are any number of circumstances in which the owner of the equipment may wish to modify the software -- generally to fix problems, or refine functionality. Often this will be contracted to the original vendor -- but it might be the responsibility of of medical technician or specialist.

Creating a situation in which ONLY the vender can modify or repair the equipment is a recipe for high costs, vendor lock-in, forced "upgrades"/replacement of last-years model, and artificial obselesence (either at the vendors whim or because it's gone out of business) and arguments over whether there are problems needing to be adressed, and how serious those problems actually are. (Sound familiar? this happens -- and has happened -- in the med-tech field too.)

In practice (and i believe, also in law) any UNAUTHORIZED meddling with critical medical equipment is forbidden, and punished if it occurs. As far as that argument goes, any unqualified idiot can fiddle with a heart-defilibrator, the meds in a paper cup, or even someone's IV drip for that matter. The simple fact that the equipment contains some sort of processor capable of being DRM'd have nothing to do with the matter, and even less with whether the vendor should be allowed to retain ongoing, ultimate control of the equipment that it sells.

Bernard Swiss

Anonymous visitor's picture
Submitted by Anonymous visitor (not verified) on

Your example shows that it is technically possible to get around the "DRM" GPLv3 requirement. I agree to this - but will note that it describes a device being sold without software. If you buy this device, it is still good for nothing - you must then go and get the software, and install it. This complexity will decrease its attractiveness, in practice to a degree where few people will actually buy it.

I think that in this way GPLv3 achieves its anti-DRM puprose, even if it is theoretically circumventable.

Author information

Edward Macnaghten's picture


Edward Macnaghten has been a professional programmer, analyst and consultant for in excess of 20 years. His experiences include manufacturing commercially based software for a number of industries in a variety of different technical environments in Europe, Asia and the USA. He is currently running an IT consultancy specialising in free software solutions based in Cambridge UK. He also maintains his own web site.