Technocrat

GPL3 article pulled

Bruce Perens
Sun Jun 17 21:44:47 -0700 2007
About+Technocrat.net
manage

I pulled the article on GPL3, Tivo, and DFSG. Unfortunately, there was too much mis-information. Sorry I wasn't around to see it earlier. Here's my rebuttal to the article.

Timothy,

I pulled this article from technocrat.net, because I don't want to spread mis-information about GPL3 or DFSG and I'm afraid this contains quite a lot. By way of introduction, I am the creator of the DFSG.

  • The current draft of the GNU GPL v3 includes several paragraphs intended to prevent "Tivoization", or the use of GPL software in non-user-modifiable devices. This seems to be at odds with the paragraph on compilations, and also with the "Fields of Endeavor" section (s.6) of the DFSG. (It is also very clearly against the spirit of the "no contamination" section (s.9), although that section is worded to only cover contamination of software.)

I think you are referring to the "User Product" portion, but you don't continue the argument.

  • Compilations

    A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

    COTS hardware has an odd tendency to not be designed around specific pieces of software, and devices assembled from such hardware would tend to have a similar lack of dependence. So I kinda suspect that the hardware is independent of the software. I would also say that the software must be independent of the hardware, or where woult Tivo have gotten it from in the first place, when nobody *had* the hardware yet?

    So, I would argue that if the Tivo were purely software, it should be covered as an "aggregate". And this does not seem to be disputed, as I haven't noticed calls for the Tivo hardware to be GPL'd if they want to continue distributing it.

The definition of an aggregation vs. derivative work is in copyright law. Essentially two separate programs on the same disk would be aggregation, while linking those programs together would be creating a derivative work of both. Hardware is generally not copyrightable in general, it's covered by patent. But it's not clear how this connects to the rest of your argument.

  • An example: say I have a closed-source IDE, and ship it with GCC as the compiler. Let's further say that this IDE only accepts a compiler binary which has been signed by the IDE distributors, and that the version GCC it ships with has been modified to accept a different command-line argument syntax that this IDE uses. Is this aggregation?

This is a process called "daemonization", by which any program A can be made a daemon callable using a server client protocol by another program B for the purpose of avoiding the license of program A. It is possible that in court it could be demonstrated that this is a single derivative work, and possible that the court would find the other way. GPL3 actually disambiguates this, look for "standard interface".

  • GCC clearly isn't dependent on the IDE, and if the IDE was dependent on GCC then why did GCC have to be modified? It could just as easily work with any other compiler that took the same special syntax, GCC was just used because it provided a convenient starting point.

This has been offered many times, and it's sort of a circular argument. Sure, you could make it work with any compiler that you had the right to modify. It's still easy enough to prove that in practice it's intended to work with a particular compiler that you HAVE modified.

  • What makes hardware special?

I think the problem is that you think the hardware has to be a derivative work for the GPL3's anti-lock-down provision to apply to it. But that is not the case. And it makes the argument up to here moot.

  • "Fields of Endeavor"

    There are some devices which legally cannot be fully user-modifiable, such as software radios.

Most people think that US FCC requires this, but actually, it isn't the case. I think FCC wants to see protection from out-of-parameter operation before it certifies a Part 15 device, but those same devices can be modified when operated under Part 97 (the Amateur service). I have a USRP, and of course all of the software for that is Open Source and it can transmit on ANY frequency.

I am planning a request for rule-making with FCC that would make this crystal-clear for manufacturers, so that they stop using that excuse for refusing to provide non-Open-Source drivers.

  • I would rather suspect that this would count as a "Field of Endeavor", and so make the proposed GPLv3 DFSG-incompatible.

There is absolutely no way that "producing unmodifiable devices" is going to be considered a legitimate field of endeavor under a guideline for producing software that has the very goal of requiring that software be modifiable.

  • There is also the possibility of devices which cannot work (or cannot legally work) without approval by some third party (such as, perhaps, video players and various movie industry groups like the MPAA or AACS LA). It seems just as reasonable to also consider making this kind of device as a "Field of Endeavor", which again would be forbidden by GPLv3 if the controlling party chose to forbid user-modifiable devices. Making the proposed GPLv3 again DFSG-incompatible.

No, sorry. Same as above.

  • "No Contamination"

    The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be free software.

    I think it odd that this is limited to software, and can't seem to find any discussion of this. If the limitation is regarded as an oversight, as seems reasonable, then the Tivo section in the new GPL is entirely contrary to this section.

This is about aggregation. But it's moot because the GPL3 provisions you are complaining about are not effected by the aggregate or derivative work status of the Tivo.

  • The OSI Open Source Definition

    The OSI Open Source Definition is very very similar to the DFSG, and the current proposed GPLv3 has all of the same problems and likely problems with it that it does with the DFSG.

    This is a bad idea.

    Do we really want a license which is of many minds regarding compilations?

Uh, I don't yet see that it is. I think you're just mis-reading how copyright works and how the license works, and even how the DFSG works.

  • And do we really want large numbers of basic utilities to move to a license that excludes them from probably the most freedom-concerned distribution there is? That should cause some major forks and incredible hard times as it fragments the community.

You think that Debian is going to refuse to certify GPL3 under DFSG? This is news to me. Do you have anything to back it up? The message you link to below gives no hint of it, and no hint that Debian would have a reason to do so. What happened to the Debian folks on the GPL3 committee? I've not heard an objection from them.

GPL3 article pulled
Nathan Smith
Sun Jun 17 23:04:23 -0700 2007
 manage
Thanks Bruce.
GPL3 article pulled
Kai Howells
Sun Jun 17 23:33:12 -0700 2007
 manage
This is one of the reasons I keep coming back here - although the editors have carté blanche to post whatever they like, the articles are not carved in stone, and should something slip through that is controversial, then it can be pulled. Not only this, but when an article is pulled, there is a full explanation and frank discussion of exactly why it was pulled and logical reasoning presented.

Now, I didn't read the original article, and while it wasn't presented here in it's entirety, it may have been good to have the original version available, just so I could go back over it, after reading the above article, and make up my own mind.
GPL3 article pulled
Uncle Entity
Mon Jun 18 01:05:42 -0700 2007
 manage
He quoted the vast majority of it if not all of it in the post. Basic reasoning was that the GPLv3 takes away too many freedoms to be compatible with Debian's raison d'?tre because of clauses that make it viral in in nature, Tivo being forced to provide information for people to be able install their own software being used as the example. Linked articles have Linus and co debating this point with a FSF person and saying GPLv2 was good enough.

So basically they wish to take away the freedom to use GPL software from consumer products which complied with the GPLv2 in the name of freedom. Projects forking in order to stay under GPLv2 was also mentioned as a very likely possibility in the near future.

Seems a lot like the XFree86, xorg split a while back or OpenBSD maintaining their own version of Apache, put too much of a burden on the users and they will go off and do their own thing. How much freedom can you take away before people just say screw it and port their apps over to BSD or *gasp* windows embedded where they don't have to give anything back...well other than $$$ in the case of winders.
GPL3 article pulled
Bruce Perens
Mon Jun 18 01:14:09 -0700 2007
 manage
The XFree86 split seems to have been about one developer or ex-developer deciding to make license changes unilaterally. I don't know about OpenBSD and Apache, could they possibly have had a problem with the Apache license?

When considering this sort of question, it's easy to confuse the developers and the free-riders (that meant in the economic sense). Generally, the folks who write the code are the ones who want a license that will protect them from various sorts of free-riders who would take their code private without returning anything. A lot of discussions of this talk about the free-riders as if they were the developers, and that's how they get it wrong.

Bruce

GPL3 article pulled
Uncle Entity
Mon Jun 18 02:10:53 -0700 2007
 manage
A lot of discussions of this talk about the free-riders as if they were the developers, and that's how they get it wrong

As soon as they release their changes under the terms of the GPLv2 they become developers with a vested interest in the project. Using unmodified GPL software was always open to any and all uses under the libre part, v3 makes it neither libre nor free as in beer based entirely on the way in which it is distributed. Very similiar to XFree86, you can only distribute this software if you call it GNU/Linux/XFree86 Debian.

Freedom to study and use software has become a weapon in a political battle to try to gain freedom to study and use hardware. True nobody is calling for Tivo to open source their hardware but they are forcing them to release information or they lose their license to include FLOSS in their products.

From a strictly freedom standpoint this is a step in the wrong direction. The spirit of the GNU becomes a false dictum because it takes away freedom instead of giving freedom. What's that copyleft stuff all about again? Free as in speech and free as in beer unless you're a freeloader then you get nothing...
GPL3 article pulled
Morosoph
Mon Jun 18 04:14:44 -0700 2007
 manage
From a strictly freedom standpoint this is a step in the wrong direction. The spirit of the GNU becomes a false dictum because it takes away freedom instead of giving freedom. What's that copyleft stuff all about again? Free as in speech and free as in beer unless you're a freeloader then you get nothing...
Well, first, it's not just any freeloader, but those who attempt to redistribute GPLed code that has been closed off. Use is okay.

Second, you're missing a dimension of freedom, which is a community-facing aspect of it. We are social animals (although not eusocial, as bees are), and preserving freedom to share downstream has a cost in that you aren't allowed to prevent it.

Thirdly, the inconsistency is yours, not the FSF's; if you look to the FSF's reasons for certain decisions, it's pretty clear that the rule is not "total freedom", but rather, "the greatest freedom for the greatest number" (quite a good rule for good government, IMO). The latter guideline recognises tradeoffs between individuals.

Fourthly, the default state of copyright law is not freedom, so a failure to impose licensing conditions is not a return to freedom, but a return to the status quo. A licensing restriction that prevents a return to the status quo is less onerous than the status quo.

If you intend to maximise the next developer's freedom (only), then certainly, put your code into the public domain. That is your freedom. But if I am a developer, why should I care about particular other developers? Obviously I care about my own freedom, and that of those who are close to me, but beyond that, I want society to be free, and I don't particularly want to fascilitate those who intend to make it less free, whether it be for a selfish, of else an ideological reason.

Effectively, I want a change of law, but a volutary change. How do a fascilitate this? Well, the GPL looks pretty good, and other developers can opt out by not building on my code.

GPL3 article pulled
Bruce Perens
Mon Jun 18 08:12:27 -0700 2007
 manage
From a strictly freedom standpoint this is a step in the wrong direction. The spirit of the GNU becomes a false dictum because it takes away freedom instead of giving freedom. What's that copyleft stuff all about again? Free as in speech and free as in beer unless you're a freeloader then you get nothing.

The entire point of GPL is to restrict anyone from taking away anyone else's freedom. It makes sense that if hardware locks down GPL software through technical measures that prevent the installation of any modification - while keeping that freedom for the manufacturer, you don't have the freedom of the GPL software any longer. GPL3 attempts to reverse that.
GPL3 article pulled
bill_mcgonigle
Tue Jun 19 18:18:09 -0700 2007
 manage
Right. I explain it simply to FLOSS license virgins: The GPL maximizes the freedoms of the community, whereas BSD-ish licenses maximize the freedoms of the individual.

I prefer the GPL methodology and 'only' score a 40% on the Libertarian Purity Test. Probably not coincidental.
GPL3 article pulled
Morosoph
Mon Jun 18 03:46:56 -0700 2007
 manage
A lot of discussions of this talk about the free-riders as if they were the developers, and that's how they get it wrong.
Indeed, many free-riders are the employers of those who'd rather contribute code to the community, and don't have enough leverage to do this without the requirement to do so.
GPL3 article pulled
Bruce Perens
Mon Jun 18 10:32:57 -0700 2007
 manage
Great point.
GPL3 article pulled
Michael Smith
Mon Jun 18 04:37:22 -0700 2007
 manage
I don't know about OpenBSD and Apache, could they possibly have had a problem with the Apache license?

It was because Apache wouldn't integrate the OpenBSD security patches.

BTW it will be interesting to see the attitude of Theo if Tivo move to a BSD derivative for their product.
GPL3 article pulled
Timothy Brownawell
Sun Jun 17 23:42:37 -0700 2007
 manage

[email of the above, ending with saying the whole argument was based on a misunderstanding of "aggregation"]

Mm, probably most of it, but also there was some forgetting that some things should have already had observable results.

I think you are referring to the "User Product" portion, but you don't continue the argument.

I was, and yes, I have a bad tendency of doing that. I'm sure I could get over it if I could convince myself to try writing more...

Hardware, and compilation or derivative or neither

So I have thing A (GPL software), and thing B (hardware, or other software), and write thing C (after I have both A and B) to make them work together.

The license on A says that it can be distributed with random other things (A can be distributed with B, for all B), without caring what they are. But it also says that it can't be distributed to be used with B, if B is locked-down hardware. This does not appear to make sense.

I think the problem is that you think the hardware has to be a derivative work for the GPL3's anti-lock-down provision to apply to it. But that is not the case. And it makes the argument up to here moot.

Not exactly. I'm thinking that if it's not derivative, then what is the grounds for restricting it (in light of the compilations section)? Does thing C make A and B no longer independent?

Contamination and aggregation

Ok... but what's the line between what is and isn't aggregation, or rather between when contamination is and isn't allowed?

Fields of Endeavor

There is absolutely no way that "producing unmodifiable devices" is going to be considered a legitimate field of endeavor under a guideline for producing software that has the very goal of requiring that software be modifiable.

So a field of endeavor can be "legitimate" or not, which apparently means "something I (don't) fundamentally disagree with". I see. Sorry, but this sounds rather bogus.

(maybe somewhat) bad idea?

This is the "should have had observable results" part. Obviously (yeah, obvious after being reminded...) it can't be right. Which does rather lessen the feeling of impending doom, although I'm somewhat concered that it doesn't appear to make sense.
GPL3 article pulled
Bruce Perens
Mon Jun 18 00:32:00 -0700 2007
 manage
The license on A says that it can be distributed with random other things (A can be distributed with B, for all B), without caring what they are. But it also says that it can't be distributed to be used with B, if B is locked-down hardware. This does not appear to make sense.

The license places terms upon number of actions that are defined under copyright law, one of which is the creation of derivative works, another of which is copying. The portion on compilations acts to define certain actions that do not create derivative works for the purpose of the license. The portion on hardware lock-downs states certain methods that you may not use if you are to exercise the right to copy the GPL3 software at all. So, your basic mistake here is to over-read the portion on compilations: it says that the license terms don't apply to other parts of an aggregate, and the part you are missing is that the license terms do still apply to the right to copy the GPL3 piece of that aggregate.

Ok... but what's the line between what is and isn't aggregation, or rather between when contamination is and isn't allowed?

Copyright law was defined before software and still does not contain good definitions of how it applies to software. Thus, we must depend on case law. There are some areas in which there haven't been any cases yet. For example, does dynamic linking create a derivative work? Lawyers I have polled are 50-50 on this question. The closest case is "Nintendo v. Goloob", and it doesn't come close enough to be definitive about dynamic linking. It was about the "Game Genie", a device that plugged between the game cartrige and the console for the purpose of cheating at solitare, and which Nintendo consdered to be derivative even though it was demarcated by those physical plugs and only modified a few memory locations in the console. Nintendo lost. That case did not proceed to a high enough court of appeals to be be definitive outside of the district in which it was heard, and didn't use dynamic linking anyway. So, there are real gray areas, and in my practice for Sourcelabs of connecting our customer's lawyers and engineers together on these issues, I tell them how to avoid those gray areas by building their software differently.

So a field of endeavor can be "legitimate" or not, which apparently means "something I (don't) fundamentally disagree with". I see. Sorry, but this sounds rather bogus.

To be logical, the guideline must disallow practices that contravene the guideline. The DFSG, which has the goal of requiring that software be modifiable, can not recognize a field of endeavor of "producing unmodifiable software" as one that must be allowed for a license to qualify under the DFSG. To make that statement more general: the DFSG can not recognize "producing items in contravention of the DFSG" as a field of endeavor. Obviously, you're not the first to raise this objection, one could pose that any of the requirements of the DFSG are prohibited by its own fields of endeavor language, you might even pose that the fields of endeavor provision prohibits itself because the endeavor of prohibiting discrimination by field of endeavor is itself prohibited :-)

I am a little concerned simply because "creating User Products" could be a field of endeavor, and there is an exception to the lock-down terms for things that are not User Products. But it's not a "use" restriction, so it probably slips by DFSG #6. That was written to disallow the "Educational Use Only" license term that was on much "free of charge but uselessware" back then.

GPL3 article pulled
Timothy Brownawell
Mon Jun 18 16:56:04 -0700 2007
 manage
The license places terms upon number of actions that are defined under copyright law, one of which is the creation of derivative works, another of which is copying. The portion on compilations acts to define certain actions that do not create derivative works for the purpose of the license. The portion on hardware lock-downs states certain methods that you may not use if you are to exercise the right to copy the GPL3 software at all. So, your basic mistake here is to over-read the portion on compilations: it says that the license terms don't apply to other parts of an aggregate, and the part you are missing is that the license terms do still apply to the right to copy the GPL3 piece of that aggregate.

Huh, so it really is purely a "you may not distribute this for purpose X, because we don't like purpose X" kind of restriction (random side-note: I like the current GPL but really dislike the idea of discriminatory licensing, which combination is probably why I kept trying to see other things that this could have been. Even when it fairly clearly wasn't.). Which lets it be internally consistent, but comes squarely back to the "fields of endeavor" issue (because "distribute for purpose X" is really a subset of "use for purpose X", as some uses imply distribution).

To be logical, the guideline must disallow practices that contravene the guideline. The DFSG, which has the goal of requiring that software be modifiable, [...]

But it can't be requiring that it *stay* modifiable, else why is the BSD license accepted?

[...] can not recognize a field of endeavor of "producing unmodifiable software" as one that must be allowed for a license to qualify under the DFSG.

Um, how is the sofware suddenly not modifiable based on whether a particular piece of hardware will choose to run those modified versions? And how is this result any different than what the BSD license allows, with BSD being DFSG-free?

...wait, what?

...While re-reading it again, it just occurred to me that the "User Product" section is under "Conveying Non-Source Forms". Which makes me wonder if it'll even accomplish anything, because of this from "man gcc": "You can use the -frandom-seed option to produce reproducibly identical object files." So you sign your object files, distribute source, and then on first boot the device compiles that with -frandom-seed or equivalent to recover the signed object code. Which makes this whole thing seem rather silly.

What is hardware? What is software?

mcrbids
Mon Jun 18 19:16:06 -0700 2007
 manage
I don't believe that there is a real accurate difference between the two. Is a motherboard hardware? What about the BIOS chips? What about EEPROM? What about an FPGA? There are lots of examples of products that blur the line between the two in an increasing manner, and it will only get worse - far worse.

Ultimately, physicists now refer to "information loss" when commenting on very physical processes, such as they decay of a black hole. When push comes to shove, the entire universe is a fleetingly insubstantial information system. So as our technology advances, the line between "hardware" and "software" will continue to blur because there is, in truth, no such line.
 

Do you have questions about the site? Write to bruce at perens.com . List of all articles we've ever published. Source Code Developer's Documentation RSS XML Sitemap XML News Sitemap Valid XHTML 1.0 Strict Valid CSS! [Valid RSS]