Busy busy busybox [LWN.net]

BusyBox is a set of command-line utilities developed with the goal of keeping its size as small as possible. To that end, all unnecessary options and code are ruthlessly cut out, and the entire command set is implemented by a single, multipurpose executable. BusyBox is found in a number of embedded environments; chances are it is running on your wireless router, for example. The command set has reached a level of capability that the new BusyBox maintainer believes that it is almost ready for use on desktop systems.

Yes, BusyBox has a new maintainer, as the result of another disagreement over the draft revision of the GNU General Public License (GPLv3). This episode is worth looking at, as it may be an omen of disagreements that could come up in other projects as the GPLv3 process moves forward.

Some projects reach 1.0 more quickly than others. BusyBox is one of the others. It was started by Bruce Perens in 1995, and became part of the Debian boot process. Bruce moved on to other interests shortly afterward, leaving BusyBox in an idle state, where it remained for a few years. Under the maintainership of Erik Andersen, BusyBox came back to life, and the much-delayed 1.0 release happened almost exactly two years ago - in October, 2004. Version numbers can be deceiving, however, as BusyBox had been in production use for many years prior to 1.0.

In recent years, the BusyBox maintainer has been Rob Landley, an energetic individual (at least, when sufficient caffeine is at hand) who has done a lot to push the project forward. So the task of thinking about how BusyBox and GPLv3 relate fell to him. Since BusyBox can be found in so many embedded systems, it finds itself at the core of the GPLv3 anti-DRM debate. A GPLv3-licensed BusyBox would create obvious difficulties for any vendor wishing to incorporate it into a locked-down product.

BusyBox is not a GNU project, so the Free Software Foundation does not hold its copyrights; instead, those copyrights are retained by the original authors. As Rob looked over the code, he found many contributions with the usual "or any later version" language which would allow a change to GPLv3. Others, however, had the explicit "version 2 only" language. Some, contributed by one Linus Torvalds, state that they "may be redistributed as per the Linux copyright." Some other contributions carry a BSD license - originally with the GPL-incompatible advertising clause. It was quite the mixture of licenses.

Rob was especially concerned about the version-2-only licensing, since that would obviously get in the way of any switch to GPLv3. And, in any case, he was ambivalent at best about GPLv3; it seems that the BusyBox project had developed a plan to dual-license its code under both GPL versions, allowing it to continue to be used under either license. So his question with regard to the v2-only code was:

Anybody feel like auditing all those to make sure it was unintentional and check to make sure that nobody that's contributed to any of those files since is unwilling to also have their code under v3, or should we just admit that the BusyBox license is GPLv2 only? (In which case we can take the hotplug patch...)

That led to the beginning of a long and unpleasant discussion about whether BusyBox should move to GPLv3 or not - and it quickly became clear that Rob had no interest in such a move. His reasoning is worth a read, as it includes a couple of new concerns - including the fact that a dual-licensed GPLv2/GPLv3 code base would be unable to accept contributions licensed under a single version (either version) of the license.

Enter Bruce Perens, last seen in in BusyBox circles about ten years ago. Bruce clearly feels that he still has some rights over the code:

When I created Busybox, the policy was that it could be distributed under the GPL. There was no restriction to prevent future versions of the GPL. Over time, my work has been submerged in that of other authors. But IMO it would be respectful of the original author to continue to use those license terms.

What followed was a long discussion on whether DRM differs from simply putting the code into ROM, whether the FSF is more worthy of trust than IBM, whether a move to a GPLv2-only license was possible, how much of Bruce's original contribution remains, and so on. Interested parties are encouraged to go into the BusyBox list archives and spend considerable time plowing through the postings; they do not always show the free software community at its best. The real outcomes, however, are this:

BusyBox will be GPLv2 only starting with the next release. It is generally accepted that stripping out the "or any later version" is legally defensible, and that the merging of other GPLv2-only code will force that issue in any case.
Bruce Perens wants his contributions to keep the "any later version" language, and has requested ("and required") that the copyright notices reflect this wish. Accommodating a contributor's wishes in this regard is normally done, but Rob Landley has refused to go along; his reason, in the end, boils down to "I'm mad at Bruce and don't want to."

To show that he meant it, Rob launched a project to find and excise any remaining contributions to BusyBox from Bruce. In response, Bruce has announced that he will be creating a fork of BusyBox which will be more responsive to his wishes. All of that may be moot, now that Rob has resigned from the project and handed the maintainership over to Denis Vlasenko - who plans to pursue moving Busybox onto the desktop.

All of this could be dismissed as yet another silly community soap opera - and there is truth to that view. But this is a soap opera which is likely to be rerun a number of times over the coming months. Any project which (1) uses the GPL, and (2) allows contributors to retain their copyrights is likely to have a discussion like this one. Avoiding such discussions is, perhaps, why the FSF is so insistent on obtaining copyrights for the projects it manages.

Version 2 of the GPL has brought together vast numbers of developers into a single agreement on the terms under which their code could be distributed. It may never have been possible to update the GPL without fracturing that agreement; it seems increasingly clear that the GPLv3 draft has, so far, failed in that regard. There are enough developers who see it as not being "similar in spirit" to GPLv2 to ensure that the new license, in its current form, will not be a simple drop-in replacement for its predecessor. Regardless of how one feels about the new terms in the GPLv3 draft, it is hard to see the potential for this sort of discord in the community as a good thing.

(Thanks to the several LWN readers who brought this to our attention).

to post comments

Busy busy busybox

Posted Oct 1, 2006 21:26 UTC (Sun) by kleptog (subscriber, #1183) [Link] (171 responses)

I don't think it's just any project that uses the GPL that's at risk. It's more like any project that doesn't pay attention to consistent licencing of the code (which is, unfortunatly, most projects).

Such a mishmash of licences was going to come back and bite them at some point. In this case it was the GPLv3 draft that set it off, but it was probably coming anyway.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 7:33 UTC (Mon) by mingo (subscriber, #31122) [Link] (170 responses)

I'm sad that the FSF is creating a problem in free software projects where none existed before: the GPLv3 process is polarizing the community along moral lines that were artificially injected into the GPLv3 draft.

The FSF, in their false zeal to kill the "evil Tivo" are trying to use their unprecedented legal power to add new moral considerations to the license - which were not in the license before. With that they are opening Pandora's box.

This unprecedented legal power of the FSF derives from their legal ability to unilaterally change the license after 15 years, by using the wildcard "or any later" language, without any legal obligation for consent from the community!

I fear the new license splits the community, instead of unifying it. I also fear it sets a bad precedent for the future: what will there be in GPLv4? In GPLv5? Who will inherit this huge legal power from Richard Stallman, once he is not the president of the Free Software Foundation anymore? Who will interpret the "similar in spirit" clause, and in what way?

The legal power of the FSF rests in a 340 lines long license, which license now affects over 350 million lines of code not written by the FSF!

Please stop this licensing madness before it's not too late! We have already wasted too much time and effort on this, and the new license has not even been released. At the sight of this self-destruction of a once powerful community Microsoft must be laughing all the way to the bank.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 8:06 UTC (Mon) by mingo (subscriber, #31122) [Link] (156 responses)

I also think that many people (like myself) have put efforts into GPL-ed projects without fully realizing this legal power and the legal effects of the "or any later version" and the "similar in spirit" clauses. We are all just coders after all, with little care for the legal smallprint.

The FSF is now trying to pretend that the changes in the GPLv3 were "always intended to be there" and that this somehow resulted in every contributor having accepted that intent being codified into the license. The FSF apparently does not realize its deep moral obligations that comes with its legal power over this huge codebase. (of which codebase the FSF wrote only a very small portion)

What worries me most about the GPLv3 process arent even the technical flaws of the GPLv3 draft (because flaws can be fixed), but the apparent and fundamental lack of acceptance of the moral obligations that the FSF owes to the more than one hundred thousand contributors of this hugebase. The FSF, having started this project still believes they have a moral right to unilaterally control its future, and are trying to enforce their moral vision, apparently just because they legally can.

Without realizing this enormous moral obligation, and without codifying that obligation into the license and into the license update process i feel there is no possibility for the GPLv3 process to be open in the sense of free software: we should not only have the ability to see the process, but also the ability to modify it. (And if that cannot be done legally: dont do it then. Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.)

This unilateral "Richard Stallman is the judge and jury" process is a parody of free software and is humiliating to me personally.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 2, 2006 8:55 UTC (Mon) by khim (subscriber, #9252) [Link] (77 responses)

The FSF is now trying to pretend that the changes in the GPLv3 were "always intended to be there"

Sorry, but this document was written before GPLv1, GPLv2 or GPLv3. To make it possible for "a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him" in the world where DRM is common GPLv2 is not enough. Thus GPLv3 was born. Where is "pretense" ?

The FSF apparently does not realize its deep moral obligations that comes with its legal power over this huge codebase

On the contrary - FSF understands it so very well. That's why GPLv2 has recommendation to allow for GPLv3. MPL and CC license just blingly give the right to switch to new version - no questions asked. Is it better ?

We should not only have the ability to see the process, but also the ability to modify it.

Huh ? Can you do it with Linux ? If Linus does not like your approach - he'll write thing himself and your contributions will be thrown away. Linux will include the things Linus likes and only things Linus likes. You can always argue on the LKML. GPLv3 will include the things RMS likes and only things RMS likes. You can argue you case on the site or you can participate in different form. You want the right to veto changes in GPLv3, right ? Do you have the right to veto changes in Linux ?

Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.)

Does not work this way: any project of more-then-trivial size includes contributions from people why left, don't care about the project anymore, etc. The people who do care can always remove "or later" clause FSF already did the most of the work: "or later" clause is not part of license, but only part of the grant text. GPLv2 was created this way unlike MPL or CC.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 2, 2006 9:57 UTC (Mon) by mingo (subscriber, #31122) [Link] (58 responses)

To make it possible for "a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him" in the world where DRM is common GPLv2 is not enough. Thus GPLv3 was born. Where is "pretense" ?

Firstly, the "pretense" is in the sentence above that you only quoted partially in your reply. (You snipped away the crutial "having accepted that intent being codified into the license".)

Secondly, i contributed to GPL-ed projects, and i never accepted the GNU Manifesto's full range of 20 years old considerations being integrated into the GPL. I trusted the FSF to update the license to be "similar in spirit" so that it does minimal adoptations to new times, but now i see that trust being abused for political means, such as for the crusade against Tivo. So at least as far I am concerned, there is real pretense in the FSF's position.

Linus did not trust the FSF's "similar in spirit" promise and codified all contributions to Linux being under the GPLv2, and i see his distrust being largely justified today.

I never accepted every raving email or other writings of RMS being incorporated into the license by reference. I now see that the "or later" and "similar in spirit" clauses might legally enable RMS to achieve that, but i am outraged by his attempt to use that loophole.

Thirdly, even considering the words of the GNU Manifesto, it misses the point by a wide margin:

"a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him"

So tell me, if I etch a GPL-ed CPU design into silicon, for example via this GPL-ed CPU design, what programmer on this planet could possibly modify that chip, if that chip is put into a system? Are you trying to argue that "modifiability" is an unqualified property of all systems that run GPL-ed code? Are you trying to argue that any CPU maker who uses GPL-ed designs is obligated to open up their fab process and let random users from the world produce their modified cores?

Fact is: no system exists today that is fully modifiable. Fact is: the FSF and you are trying to single out certain types of tools and techniques that can restrict hardware, after the fact (DRM has been around for 10 years or more), just because they and you dont like the restrictions on Tivo. Fact is: i never authorized the FSF with codifying technically inconsistent and vague statements of the GNU Manifesto and various other writings of RMS into the GPL license. They might be able to pull it off legally, but it is arbitrary and deeply political in my opinion, and against the trust i have put into the FSF when i made my contributions.

Licence text and fabs

Posted Oct 2, 2006 14:59 UTC (Mon) by coriordan (guest, #7544) [Link] (57 responses)

It's difficult to respond to your statement that draft 2 of GPLv3 is not similar in spirit to GPLv3 when you don't reference the text to say how.

The closing fact about no fully-modifiable system existing is a "Can't be perfect therefore all effort is in vain" argument. It's not true. 100% effectiveness isn't required, and isn't possible through licences alone. GPLv3 is making small changes which can close some real world loopholes - ones that exist and are used, not theoretical ones or ones that are impractical.

But the most important thing is that there is nothing in the text about signing up to the GNU Manifesto, or opening the factory doors of every fab that burns GPL'd software onto a chip. Lets discuss what's in the text - that's the route to solving the problem (if there is a solution).

Licence text and fabs

Posted Oct 2, 2006 20:23 UTC (Mon) by mingo (subscriber, #31122) [Link] (56 responses)

It's difficult to respond to your statement that draft 2 of GPLv3 is not similar in spirit to GPLv3 when you don't reference the text to say how.

I sent that feedback to the FSF some time ago. The final reply, after some discussion where i explained my points, was silence. So lets put the discussion out into the open, maybe that improves the quality of communications.

For example, lets take the definition of Source Code from Section 1, gpl-draft-2006-07-27 (gplv3 second draft):

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.

I understand that this is that drives the anti-Tivo push, but what do encryption keys have to do with source code?

If a hardware maker decides to put a "virtual ROM" on his box and sell the hardware in such a restricted form so that it will only run kernels that match a certain hash (besides putting the hardware into a 10"x10" sealed, translucent plastic cube and painting it purple), what does the hash check in the hardware have to do with any source code?

And if there is any connection, why dont we include "box that can be opened via a standard screwdriver, so that it can be modified without damaging it" into the definition of the source code?

Why dont we include "and all specifications of the hardware have to be provided too, so that the modification of software can be performed without damaging the hardware"?

Why dont we include "dont paint the box purple because that color scares away free software developers trying to modify the box!"?

Why does the GPLv3 redefine source-code in such a way, why does it single out keys from the myriads of existing ways of restricting hardware capabilities, and where will that process stop? But most importantly, why does the GPLv3 get into the business of trying to dictate hardware design? The GPLv2 didnt do that. I hate the MPAA/RIAA's behavior as any other guy on lkml but still i dont get down to their deplorable tactics.

Licence text and fabs

Posted Oct 2, 2006 22:21 UTC (Mon) by stevenj (guest, #421) [Link] (36 responses)

If a hardware maker decides to put a "virtual ROM" on his box and sell the hardware in such a restricted form so that it will only run kernels that match a certain hash (besides putting the hardware into a 10"x10" sealed, translucent plastic cube and painting it purple), what does the hash check in the hardware have to do with any source code?

That's a bad example, because that's not forbidden by the GPLv3. Making the hardware look at, say, the MD5 hash of the kernel before running it does not require any secret encryption keys.

The basic principle is simple: if the hardware manufacturer can modify the software in the user's box (as opposed to building a new box), then the user should be able to also. This principle explains why the FSF didn't consider any of your other examples like forbidding boxes without screwdrivers (or boxes painted purple??), since in that case the hardware manufacturer can't do anything the user can't.

Licence text and fabs

Posted Oct 2, 2006 23:38 UTC (Mon) by mingo (subscriber, #31122) [Link] (35 responses)

That's a bad example, because that's not forbidden by the GPLv3. Making the hardware look at, say, the MD5 hash of the kernel before running it does not require any secret encryption keys.

Firstly, i did not talk about an MD5 hash of the kernel.

Secondly, read the GPLv3 draft again, it is not limited to "secret encryption keys" alone. See Section 1:

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.

(emphasis added)

Note the "encryption or authorization" language. It is not limited to encryption keys alone.

Anyway, what does the "key" have to do in the definition of source code? By putting this into the Source Code definition, we are implicitly judging the act of "not sharing a key" immoral - because it's now judged to be an act of "not sharing the source code". (The GPLv3 does carve out a few exceptions in later sections, but the damage has already been done in this section.)

As it has been acknowledged by another poster here who seems to be intimately familiar with the GPLv3 process, the goal of this definition is to dictate what the hardware does, to remove the inconvenience of certain types of hardware limitations. My observation is that the GPLv2 did not do this, never tried to do this, and that trying to control what hardware does is immoral. (and pointless btw., as i explained it in other replies in this thread.)

What "inconvenience" will we try to remove via the license come GPLv4? Perhaps the inconvenience of not getting money in exchange of the nice free software we are writing?

Licence text and fabs

Posted Oct 3, 2006 0:58 UTC (Tue) by stevenj (guest, #421) [Link] (34 responses)

You're being deliberately obtuse to score cheap rhetorical points. You didn't specify an MD5 hash, but you specified a "hash" (no serious cryptographic hash requires a secret key) and, in any case, your example was a "virtual ROM". I explained how to create a virtual ROM without requiring secrets of any kind and in compliance with the draft GPLv3—no encryption or authorization "key" exists or is required, in the same way as for a physical ROM.

The only problem comes if the manufacturer wants the ability to modify the software while denying this ability to users.

My description of the rationale for restricting this and not ROMs being one of parity (between distributor and recipient) comes straight from Eben Moglen and RMS, not from hearsay, so Ciaran is mistaken in implying that distinction is merely "convenience":

If Manufacturer A wants the software he sells in the hardware to stay one version forever, he has a simple way to do it: he can put the software in ROM. He has no power to modify it, and the user to whom he gives it has no power to modify it. That doesn't violate GPL version two and it doesn't violate GPL version three, in current draft. We will not publish a draft that would be violated by that conduct. What we object to is the attempt to say "I will keep the right to modify the software, but I won't allow you to have the same right of modification that retain" because that's simply a technical way of evading the requirement of the licence to pass along all the rights you got.

The fact that you continually depart from the text of the draft license and ignore extensive evidence of the true rationale to conjure scare scenarios that don't exist does not inspire confidence in your analysis.

And, by the way, your argument that it is "immoral" could equally well be applied (and has been applied, usually by BSD advocates) to GPLv3—this is the usual argument against "viral" clauses. The usual retort is that it is simply quid pro quo: if you want to distribute my code as a part of your software (or hardware), you need to satisfy my conditions. And the conditions of the GPL have always been aimed at the same thing: giving every user (whether the manufacturer or the end-user) the same ability to modify, run, and redistribute the code. You may disagree with this goal, but you have yet to provide any convincing argument that the GPLv3 departs from this spirit.

Licence text and fabs

Posted Oct 3, 2006 14:13 UTC (Tue) by mingo (subscriber, #31122) [Link] (3 responses)

The only problem comes if the manufacturer wants the ability to modify the software while denying this ability to users.

So how does this differ from the situation of old-fashioned ROMs that contain GPL-ed code? Do you get an EEPROM burner with every toaster that includes a ROM? Do you get free training to be able to use that burner? If the write pins of the ROM were burned out, but it's still easily replaceable by the manufacturer, do you get free ROM chips to replace them with? If the ROM is in a disposable cartridge that has some weird physical form factor, do you get free access to the cartridge manufacturing process, to be able to "modify" the ROM and produce new cartridges?

You dont, and it would be unreasonable to require that in a free software license. And the same is true for a "virtual ROM", which is easily upgradeable for the manufacturer but hard to upgrade for others.

What this new language in the GPLv3 does is what the GPL never did and never purported to do: it limits the ability of end users to use GPL-ed code. Yes, hardware makers are end users too, and the new GPLv3 language limits their end-use. This sets a far more dangerous precedent than any supposed dangers of the harder-to-tweak nature of the Tivo brings with itself. It shows to new contributors that our prior words cannot be trusted. The GPLv2 clearly says: end use is not limited in any way, shape or form. Now the GPLv3 tries to limit the ways in how hardware makers can use our binaries. That is an unacceptable change of the bargain to me. I dont care how inconvenient the Tivo is to us, we have no moral grounds to limit end-users. This was clear in the GPLv2.

In what way will you change the bargain next time around? Ask for samples of free hardware perhaps to make modification easier? Ask for specs and training and access to personell to make modification more convenient? Or, to make it really convenient for all of us, do you plan on asking for money in exchange of them being able to use all this wonderful free software? It would of course be "similar in spirit" to previous versions of the GPL, because without money to live how can anyone do the modifications to begin with? The 4 freedoms would be toothless if developers werent reimbursed for their efforts, right?

And no GPLv3-proponent so far was willing to answer this simple point: where is the moral line? Now that the GPLv3 starts limiting end-use, where will that limitation stop?

And as i said it before: there will always be freeloaders that only use our works and dont give back. /We cannot force them to give back/. Still the community and our users are giving back /a lot more/ than what the text of the license requires - because what drives this whole thing is not your paranoia to punish freeloaders, but the basic mechanism of getting modified source code back. Your vendetta against DRM will only turn away new contributors (and old contributors) alike. It already caused real damage within the community. (read the article you are commenting on.)

Licence text and fabs

Posted Oct 3, 2006 18:57 UTC (Tue) by walken (subscriber, #7089) [Link]

> Yes, hardware makers are end users too

No they are not - not under any common definition of "end user".

Someone who's a distributor is not an end user - the product does not *end* up there, it gets *distributed* instead.

I'm sorry but you're twisting words again.

Licence text and fabs

Posted Oct 4, 2006 2:40 UTC (Wed) by sanjoy (subscriber, #5026) [Link]

the GPLv3 tries to limit the ways in how hardware makers can use our binaries. That is an unacceptable change of the bargain to me.

It might unacceptable if it were such a limit. However, there is not, despite many claims to the contrary. Use, in common parlance and in copyright law, means running the program. Under the GPLv3, hardware makers may freely run the program for any purpose. For example, they may and probably do run it to test whether it recognizes all the hardware or does not crash when given random input. They may even find solutions to any crashes, modify the program, and run the modified version (so long as they don't violate the patent-retaliation clause). There is no restriction on use.

Recipients of such hardware are also free to use (run) the program, as they do every time they turn on the device. No restriction on use there either. The only restriction is on distribution, which copyleft licenses by definition restrict. If the manufacturer distributes the program, perhaps embedded in a device, the manufacturer must give you the source code so that you can modify it; and under the GPLv3 the source code also includes the manufacturer's magic key so that you can install your modification. This requirement is a restriction on distribution: "You may distribute provided that you do XYZ." It is not a use restriction.

In what way will you change the bargain next time around?

This question is based on the incorrect premise that the bargain changed. With the GPLv3 as with the GPLv2: You may use the software for whatever purpose you want, modify it even, but if you distribute it (perhaps modified), you must give others the same rights.

--Sanjoy Mahajan

Licence text and fabs

Posted Oct 6, 2006 21:51 UTC (Fri) by petetron (guest, #8495) [Link]

You are being obtuse. In the case of something like Tivo, the company can push new software updates to the device over the internet without the consent of the user. As another example, if a device is tied to a particular service, the company could compel the user to upgrade the firmware by making the service incompatible with older versions. In either case where GPL software is involved, the user should have the choice as to whether to accept the new version of the software, and if not, to still be able to use the hardware they BOUGHT and PAID FOR in the way they see fit (by patching the GPL'd code). That requires being able to change the source code.

If you distribute GPL software in ROM, you still need to distribute the source code. That's just as much the case with the GPLv2 now as it would be with GPLv3. However, unless the company sends men in black to your house to replace the ROM chip in the dead of night, with ROM there simply doesn't exist the same ability to force unwelcome upgrades on your device. That's a key difference and why your argument about EEPROM is absurd.

What this new language in the GPLv3 does is what the GPL never did and never purported to do: it limits the ability of end users to use GPL-ed code.

What are you talking about? In the most literal sense, requiring people redistribute source code is a limitation on their rights to keep their modifications to the code hidden. But it is through this mechanism that the essential goal of the GPL is asserted, which is that software which is placed under the GPL remains free to be used, modified and redistributed by anyone.

And as i said it before: there will always be freeloaders that only use our works and dont give back. /We cannot force them to give back/.

But we can force them to give it back, that is where copyright and contract law comes into play enforcing the text of the GPL. It is evident that you completely misunderstand the legal and social contracts that the GPL is built on. Perhaps you read the BSD license and are just confused?

Licence text and fabs

Posted Oct 3, 2006 14:33 UTC (Tue) by mingo (subscriber, #31122) [Link] (28 responses)

And, by the way, your argument that it is "immoral" could equally well be applied (and has been applied, usually by BSD advocates) to GPLv3this is the usual argument against "viral" clauses. The usual retort is that it is simply quid pro quo: if you want to distribute my code as a part of your software (or hardware), you need to satisfy my conditions.

You are materially misrepresenting the "Quid Pro Quo" that existed in the GPLv2, and you have inserted a condition (see the word in bold above) that was never there.

Using our license to affect works independent of our work (such as hardware) was never part of the Quid Pro Quo deal. If my software is distributed with works that are independent of my software, i have no moral right to limit that distribution. (Yes, we have the legal power to do so, but there are a lot of things that are legally allowed but still immoral.)

Look at the "merge aggregation" language in the GPLv2.

This whole attempt to control other works is hidden in Section 1 of the second draft of the GPLv3, by the inclusion of "keys" into the Source Code definition:

This definition brings keys, which are otherwise part of another work (the hardware) into the scope of our "source code", and hence forces their release.

What will we put into the definition of "Source Code" in GPLv4? Perhaps "all design documents of the hardware and 10 free samples of the hardware, so that the documentation can be used in a meaningful way to modify the software in its principal context of use"?

Please answer me a simple question: what moral rights do we have to control works independent of ours, and where does the GPLv2 do the same thing, if your argument is that it already did that? The Tivo hardware is not a modification and not derived from any GPL-ed code.

In simple terms: the GPLv3 goes from the previous "Quid Pro Quo" to "eye for eye", and it is utilizing tools that limit fundamental freedoms (such as unlimited end-use and the independence of works independent from our works) that the GPLv2 explicitly granted in an unlimited way. Do you now understand why the GPLv3 is not similar in spirit to the GPLv2?

Licence text and fabs

Posted Oct 3, 2006 15:23 UTC (Tue) by stijn (subscriber, #570) [Link] (6 responses)

I do not think the GPL mentions 'quid pro quo' or 'tit for tat' anywhere.
It may very well be what *you* like about the GPL, but the GPL is concerned with the four freedoms. In this respect you seem to be trying to make the GPL be something it never was.

In earlier threads it has been stated that the FSF is now trying to impose its moral viewpoint on users, developers and the world. The GPL has *always* been about ethical issues and the four freedoms. This has been raised elsethread and has not been satisfactorily answered.

Look at 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.

Do you see 'tit for tat' anywhere? Access to the source code is (just) a "precondition". Now the FSF and many other developers have judged that the preconditions have changed (DRM enters the fray), and they have judged this in the context of the four freedoms. They have always understood 'adapt' to exclude the meaning "having to buy or assemble new hardware". The tit for tat aspect of the GPL is a means to an end and a piece of a bigger puzzle.

There is only ONE material difference between the kernel devs position and the FSF position, and it is about where to draw to the line.
If you think the GPL is about tit for tat and nothing else your position is at least understandable. In that (warped) view perhaps one can accuse the FSF of bending their position and "abusing trust for political means". But the FSF position in view of the four freedoms is entirely consistent and has always been.

Then there are a lot of entirely immaterial differences (patents and supposed license hijacking), and there is obviously a whole cesspool of bad blood. Then people have different crystal balls. Some think powerful forces are at work to force DRM down our throat everywhere. Opinions differ on this as well as on the best course of licensing even if it were true.

I find the accusations of the FSF acting in bad faith incomprehensible. It is probably due to the persona of rms and the history of what's gone before. I had hoped that people would be able to communicate with Eben Moglen, but statements from Linus Torvalds imply bad blood even there.
As someone who does not yet unequivocally support GPL v3 (but I certainly prefer free over open) I am frankly surprised by the FSF bashing on the kernel devs side.

You cannot reduce GPL v2 to 'quid pro quo' and I see no grounds for your characterization 'eye for eye'.

Licence text and fabs

Posted Oct 3, 2006 21:17 UTC (Tue) by sepreece (guest, #19270) [Link]

While I generally agree that you can't reduce the GPLv2 to "tit for tat", it was largely compatible with the viewpoint that tit-for-tat fairness was what mattered. That is, it could be used happily by authors who cared most about fairness and by authors who cared most about freedom. Some of us think that inclusiveness was an advantage.

I don't question that GPLv3 moves in the direction of the FSF's philosophical center and the aims of many of its supporters. However, it's still important to consider whether it may be going too far. The GPL has always had to balance its ultimate goal of complete freedom against more practical constraints. Some of us believe that GPLv3 has pushed too far.

The GPLv3 violates the 4 GNU freedoms ...

Posted Oct 3, 2006 22:46 UTC (Tue) by mingo (subscriber, #31122) [Link] (4 responses)

The GPL has *always* been about ethical issues and the four freedoms.

I actually believe the 4 freedoms almost directly derive from the thousands of years old "tit-for-tat" concept on source code, and thus if the GPLv3 violates the "tit-for-tat", it inevitably violates the 4 freedoms too.

Please let me prove this to you. For example, the proposed GPLv3 violates freedom 2, which is described by RMS as:

The freedom to redistribute copies so you can help your neighbor (freedom 2). (link)

Example: take the full Tivo userspace binaries (unmodified), and put it on a stock PC. (That is the only GNU piece of software on that PC, all the rest and the hardware was created independently of any GNU software.) You can freely redistribute that copy to your neighbor, as per freedom 2.

Take the very same binaries and move the harddisk to the Tivo. (All the other stuff on the Tivo (including the hardware) is independent of any GNU software, it's not a derivative nor a modification of any GPL-ed code.)

But under the proposed version of the GPLv3 now you can not redistribute that same copy to your neighbor! Just because it has been put into a Tivo - which Tivo has no GNU code in it except this harddisk which the user has put there.

How is this possible? The GPLv3 uses one of the legal powers of the copyright holder, which allows the control of how "redistribution to neighbors" happens, in a new way: to control the handling of a piece of information that was created independently of any GNU software. That piece of information is Tivo's private key, which is only in the hardware.

The GPLv3 tries to control hardware that was not copied, modified or from any GPL codebase, and prevents the redistribution of that copy of GPL-ed code, and thus GPLv3 violates freedom 2.

GPLv3 proponents might argue that this violation of freedom 2 is done to strengthen another, more important freedom, but this brings in two new problems.

Firstly, it is not acceptable to violate any of the 4 freedoms, especially not for a proposed new GNU Public License. If a measure in the GPLv3 violates one of the freedoms, even if it is done to strengthen another freedom, that measure still violates a freedom and should not be used at all. Another measure is needed.

Secondly, in reality the "freedom to tinker" [the right to modify freely] never existed in a pure form because this world is based on matter and on physics, which does bring some hard constraints of modifiability with it.

"Freedom to tinker" has been invented well after the GNU Manifesto, well after Linus released Linux under the GPL, well after i started contributing to the Linux kernel and well after even the 4 freedoms were invented. So how was Linus or i supposed to consider it when accepting the GPLv2? Furthermore, this physical world has hard constraints which are inevitably assymetric between "would be modifiers" and "producers of the hardware". For example, to modify a ROM that a hardware maker produced is fundamentally harder for someone who is not intimately familiar with that process of hardware creation - whether there's crypto in the picture or not. (But i am not blaming RMS for not realizing this, he's a mathematician after all and thus probably not infallible in matters of physics ;-) I do blame him for not listening (yet) though, and i do blame him for a license modification process that does not self-correct such errors.)

I believe your point is also missing a fundamental moral question: does RMS have the moral right to unilaterally and retrospectively change the contribution dynamics of a codebase that is roughly 1 billion lines of code written by hundreds of thousands of contributors, via a 340 lines license RMS wrote 15 years ago, without considering the motivations and moral background of the many contributors that wrote that codebase?

I know he did not want this whole "Open Source" stuff to happen, he fought against it tooth and nail, but it happened, and he has ended up with a unique legal position to affect it significantly, and he has to weigh the moral implications of that responsibility. Even if he does not feel to be part of that "Open Source" stuff. The baby has been put on his doorstep (which door has "Orphanage" written on it in large letters ;-), and he has to take care of it, whether its his or not.

Or as Lawrence Lessig has recently pointed it out in his blog :

The real challenge here will be Richard Stallmans. [...] So his challenge is whether he evolves these licenses in ways that fit his own views alone, recognizing those views deviate from many important parts of the movement he started. Or whether he evolves these licenses to support the communities they have enabled.

(Lawrence Lessig)

The GPLv3 violates the 4 GNU freedoms ...

Posted Oct 4, 2006 2:23 UTC (Wed) by sanjoy (subscriber, #5026) [Link] (1 responses)

The GPLv3 tries to control hardware that was not copied, modified or from any GPL codebase, and prevents the redistribution of that copy of GPL-ed code, and thus GPLv3 violates freedom 2.

and (from an earlier message)

trying to control what hardware does is immoral

It does not control the hardware, even if people claim many times that it does. It says only that if you distribute the code in such hardware, you need to provide another piece of information (a small piece of software, you could say): the authorization key. Tivo (if they used GPLv3 software) would be free to make whatever broken DRM hardware they like, and you would be free to fix it. How is that control over hardware?

A similar clause in the GPLv2 says that you need to include Makefiles or other compilation scripts, if you used them. Which makes sense. The Linux kernel would be a right pain to build without its Makefiles. This provision about compilation scripts is a condition on distribution: "You may distribute provided that you do the following..." Just as, under the GPLv3 draft, you may distribute Tivoized software provided that you give users the authorization key.

The GPLv3 [tries]...to control the handling of a piece of information that was created independently of any GNU software. That piece of information is Tivo's private key, which is only in the hardware.

It is not only in the hardware. It is also, like a compilation script, in Tivo's software somewhere so that they can install new kernels. The GPLv3 merely says that they must include that information, that software, as part of the source code, just as they must include the Makefiles.

GPLv3 proponents might argue that this violation of freedom 2 is done to strengthen another, more important freedom, but this brings in two new problems.

It brings in new problems only if it is a violation of freedom 2. But people are still free to redistribute copies. They need only to satisfy a few conditions and none of those conditions says anything about how Tivo manufactures hardware. With those conditions satisfied, other people can distribute improved, useful versions of Tivo software and help their neighbors, the purpose of freedom 2. So conditions on distribution are not offensive intrinsically; their moral weight depends what they are. As an example of a good restriction, the GPLv2 requires distributers to provide source code.

The GPLv3 is being consistent: It guarantees user freedom.

Suppose, under the GPLv2, you take the Linux kernel, make a version that will not boot without first getting an authorization key from Ovit Inc. You distribute that version in your hardware. Fine! Since recipients can get the source code, thanks to the GPLv2, they can undo the damage and install a less ridiculous kernel. Freedom prevails.

Now suppose Ovit Inc says: "By signing this contract, you agree not to install such a changed kernel. We will sell you an Ovit device once you sign on the dotted line." That trick too is foreclosed by the GPLv2, which says (in section 6): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Ovit could claim that it never agreed to the GPL and is therefore free to impose any contractual obligation on you (that is not against the law). However, that choice would make Ovit a copyright infringer, a ruinous proposition thanks to how draconian copyright law has become.

So Ovit Inc tries a third approach. It builds hardware with an embedded private key, and only if the keys check out with Central Command will the kernel boot. Here probably the GPLv2 has no solution (although the "compilation scripts" provision may help, but only a judge would know, or more precisely, could create an answer by making a ruling).

The GPLv3 says: "No. Just as you cannot lock the code down with boot keys or with legal provisions, you also cannot lock it down with hardware. Make whatever hardware you like, we have no opinion on that. But if you can modify the free software you are distributing, so can the people who receive it: You must give them the magic keys."

Too bad the kernel won't switch to GPLv3, due to logistical difficulties (pain in the neck to contact all copyright holders) and to ideological objections. But that doesn't mean the GPLv3 isn't a reasonable, consistent solution to a real problem.

The GPLv3 violates the 4 GNU freedoms ...

Posted Oct 4, 2006 13:37 UTC (Wed) by sepreece (guest, #19270) [Link]

I'm sorry. I can't read this argument as anything but sophistry. Yes, the literal restriction may be the requirement to include needed keys, but the practical issue is the right to install on the device in such a way that the software continues to work, on that device, and maintain its authentication status with other services.

Even in literal terms, since the keys you mention typically involve the identity of the device as well as the software, the domain of control is clearly being extended to include the hardware. You're no longer asking for the things you need to install the software, you're asking for the things you need to install the software on a particular device, in a particular way (so that it can lie to other components or services about which version it is).

Don't bother. The FSF position is clear without the contorted rationale. Some of us disagree with it, but at least it's a straightforward position based on a philosophical position.

The GPLv3 violates the 4 GNU freedoms ...

Posted Oct 4, 2006 12:29 UTC (Wed) by stijn (subscriber, #570) [Link]

I actually have problems just understanding your Tivo example (also used elsethread) and I would like to grok it - this kind of scenario is what is needed most in this type of discussion. It is likely due to the fact that I do not have a full grasp of the licensese in GPL v2 and draft v3 and its implications in the scenario. More specifically, you seem to focus on userspace (significance?), binaries (source?), and redistribution (arrival in the first place?). This pertains to your point of freedom 2) being violated.

Freedom to tinker is an essential part of the famous printer driver story. I am not sure I follow.

About the fundamental moral question now. I wanted to establish that the FSF and Richard Stallman and Eben Moglen are acting in good faith and according to a consistent view of the world. The divide now is whether v3 is 'similar in spirit' or not. I tentatively think it is although I am not sure the DRM clause can be formulated in a sufficiently clear way (or, whether it can find an unambiguous border line). I am dead certain however that the FSF *intent* is to be 'similar in spirit'. I think there has been a lack of acknowledgement regarding this.

The moral question then pertains to all the people who licensed with the famous 'or (at your option) any later version', and it pertains to whether they judge the DRM clause to be similar in spirit. I am one of them, albeit with some very small impopular user-space projects. The kernel developers are not as far as the kernel is concerned. The busybox case is not so clear cut.

Linus Torvalds has done well to do without the 'later' clause, given his liking and interpretation of 'tit for tat'. The concerns raised by the kernel developers and the rationale are genuine and your many contributions in the various LWN threads are highly valued. The general stance has been rather unforgiving, emotionally charged, and one of abandonment. In this last sentence I was going to denounce that, but who knows, sometimes conflict is necessary.

"moral right"? um...whyever not?

Posted Oct 4, 2006 21:49 UTC (Wed) by roelofs (guest, #2599) [Link]

Insofar as those contributors granted him/FSF that right, whether explicitly or implicitly, why wouldn't he have it? How naive do you have to be to grant the "or any later version" power to a third party and not expect that it might result in license changes not entirely to your liking?

If you truly want to preclude such changes affecting your code, then you don't use the "or any later version" language--just as, in fact, Linus and you and the other kernel developers did. But for everyone else--everyone in that 1-billion-LoC, 100,000-plus-contributors category, the numbers of which I'll take your word for--they ceded both legal and moral authority to the FSF when they chose that wording on their license grants.

The only vaguely comparable examples I can think of--but where the "legal" and "moral" rights arguably did diverge significantly--are the Unisys/GIF/LZW promise of a patent exception for free (not Free) software, and the amazingly similar Mozilla/Firefox promise of a trademark exception for Debian. In neither case was the promise ever a legal agreement, at least under US law, and in both cases it was later revoked unilaterally. To put it another way, "moral" rights were (temporarily) granted, but legal rights never were. However, I see no similarity to the current GPL v2/v3 issue beyond the most basic level of all three examples having to do with legal rights and additionally having a "moral" or ethical dimension. The GPL case, unlike the others, seems legally, morally, and ethically self-consistent to me.

Greg

Licence text and fabs

Posted Oct 4, 2006 9:27 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (20 responses)

The GPL even in it's v2 form controls more than the code itself. For example you can not claim you can only provide source on gold plated media available at extorsionate price (that is unless you can prove you have to use gold-plated media yourself).

Some people are currently trying to reintroduce the artificial cost asymetry the GPLv2 forbids for source at the binary level (using DRM). The GPLv3 logically forbids it too.

And BTW it's false to say the GPLv3 affects hardware, since the hardware itself is unaffected by who holds the distribution keys. What it affects is the combined harware+software behaviour.

It's not terribly immoral or astonishing that when you combine software distribution with hardware, the software distribution rules have a say on the result. Linking works both ways.

Licence text and fabs

Posted Oct 4, 2006 14:16 UTC (Wed) by mingo (subscriber, #31122) [Link] (19 responses)

that is different. I'm not talking about common-sense definitions about how the "payment" for our creative works (which payment is mostly in the form of providing source code) happens.

The thing i'm talking about here is that the GPLv3 includes another work (the key) which is independent of our GPL-ed works, in the definition of Source Code, which source code we purport to license!

(and then later on the GPLv3 uses this "defining of other people's creative works into our license's Source Code" act as a tool to prevent the hardware from being redistributed, unless the newly-defined "source code" (which now includes another person's independent creative work!) is provided too.)

Licence text and fabs

Posted Oct 4, 2006 20:51 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (18 responses)

> The thing i'm talking about here is that the GPLv3 includes another work
> (the key) which is independent of our GPL-ed works, in the definition of
> Source Code, which source code we purport to license!

I can't imagine how anyone could construct the key as a "work", it costs nothing to create or duplicate.

Take the same hardware with and without DRM. It should be painfully obvious the only "value" "created" by adding DRM and making it apply on GPLed software is the possibility to stop the accesses the GPLv2 used to imply reneging on part of the "payment" for GPLed code use.

Someone has been breaking a bargain. Someone has been extending itself unilaterally without counterpart. Is this someone the FSF? I don't think so

Licence text and fabs

Posted Oct 4, 2006 21:55 UTC (Wed) by mingo (subscriber, #31122) [Link] (17 responses)

I can't imagine how anyone could construct the key as a "work", it costs nothing to create or duplicate.

Let me give you an example of a 1024-bit key:

mQGiBDlqJigRBADpPRhgY7lPy42Hy1gk6YKT81QOGkptbUuSkKZ4lSvGT5DEsmwG
q6/l+/WdeE9401Njs55bnztcetCzcadyBIxPJz+JpzbaOjwdxTZuLHstQ5+ddK54
fdDBw76W0N/DZTV/rypPvl0p9NtnmT+Q5tWF1j/s7bLxyNBBNxRpiBm+xwCg/zEy
2YVUb9hnsna1Lknp4sxGBN8D/RvG4wXHLzFIsEjY4qlY+W0hN3dNW0mBuqLEZ3gD
E1rZyI9/6                                                wHQeGIB
m5euYv1YJ   This chunk of metal, like it or not,         1ASDFlk
WIAfA/4kS   Is our love and hate, my bright spot.        xAIQusQ
cfSBBwn68   Treat it  with  respect,  dear Alice,        AOX9D/v
VKb/Ia5Wb   To protect its keys, we promise.             y1IYXNz
byBTdGFtZ                                                WomKAQL
AwIBAAoJE   Copyright, 2006, Ingo Molnar.                8WD8g0T
mo9TCht0r                                                2AmDLM9
j2R35j0DF9sxrMLwz2JhAJ9eUCud0CxsVANJg3BsTvftvbgVIIhGBBARAgAGBQI7
Wm7tAAoJEMGC+zEYbLxm1OMAnjlzJ2MZJ2yoBzagnLesayo1qHhxAKC32HkRdxt2
bZSCQrDA7CftJLYBjLkEDQQ5aiYpEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y
4KN5xsncegus5D/jRpS2MEpT13wCFkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4Q
tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X/faY98h8ebByHTh1+/bB

This work, besides still being a pretty strong cryptographic key, is also a literary work, a creative original expression, and is copyrightable.

(The fact that it's easily copied - like any piece of digital information - has no bearing on the strength of copyright protection.)

Licence text and fabs

Posted Oct 5, 2006 6:34 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (16 responses)

Bzzt. Thank you for making my point

Copyright "works" are only protected if they are the produce of human creative expression (could not have been created by a stupid computer alone)

99,99999% of DRM keys obviously aren't.

Now you artificial unrepresentative example isn't, but IIRC in a similar case when Sega tried to lock its console by checking for the Sega word/logo at the beginning of ROMs, a judge ruled since the Sega word/logo use was 100% technical and the check could have been implemented by Sega the same way with a non trademarked/copyrighted/protected string/bitbucket, using Sega instead didn't win them any special additional protection.

Which again is academic because actual DRM keys do not look like yours.

Licence text and fabs

Posted Oct 5, 2006 7:30 UTC (Thu) by mingo (subscriber, #31122) [Link] (3 responses)

well, what i wrote into the key wasnt a simple word/logo. And yes, it can be used as a totally valid cryptographic key - it has enough random content to be cryptographically strong, and it has enough expressive content to be copyrightable. And if it's kept secret by the hardware, it can very much be a trade secret as well. The Sega logo is hardly a trade secret. Do you have any case law that says that trade secret works that are /independent/ of the copyright holder's work are trumped by copyright law? In my reading it would be contrary to the letter and the spirit of both the law and the Constitution.

This was a relatively small key i constructed, but what if that key includes actual, functional code as well, which would have to be executed by the CPU for the hardware to work correctly. What if that key is your family inheritance that your ancestors signed their legal documents with for decades, and which includes expressive content that has sentimental value to me as well. Your assumption that just because it's used as a key it cannot have expressive properties was false when you first said it, and it is still false now.

And you are still missing the larger point as well. This portion of the GPLv3 is a seemingly small but dramatic departure from the spirit of the GPLv2, which explicitly said that it does not attempt to control other works (unless those works being based on GPL-ed code), be that source code, keys or anything else. GPLv2 Section 2 says:

 Thus, it is not the intent of this section to claim rights or contest
 your rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or
 collective works based on the Program.

this language is gone from the GPLv3, and the DRM language does a first step towards using distribution rights to control other works. Today it is only used to control certain keys. So far I have not seen anyone even try to limit the scope of this new step, it seems the party line of the FSF is that "everything that /we/ think or ever thought would be needed for the 4 freedoms is a fair game". Would you ever sign a contract with that kind of open-ended language in it?

And in what way will you change the bargain next time around? Until today it was in essence source code for source code, and it took 10 years to explain even this simple concept to developers. Tomorrow it's the hardware's keys too in some cases, the day after tomorrow it will be what? Will the GPLv4 say:

 You must ship 10 free samples of hardware and design specifications
 to the FSF headquarters and offer free on-site training and free
 tools for tweakers to be able to make use of their right to tweak.

Will the GPLv4 perhaps include:

 You may only distribute copies of works that are GPL-compatible in their 
 totality. Aggregation with any non-GPL work is prohibited.

is that the plan?

Future contributors will be asking me that, and I have no answer for them, do you have any?

We are going to lose alot more contributors this way than due to this uncertainty of the deal than whatever freeloading might become possible via DRM. Freeloading was always possible - heck, a simple end-user of GPL-ed code who never contributes back and never distributes GPL-ed works is a "freeloader" almost by definition.

I'm not worried about freeloaders as long as it's economically unfeasible for them, both the GPLv2 and the GPLv3 has loopholes that enable freeloading and leaching. I'm alot more worried about having a fair and clear deal towards developers, because they wrote this 1 billion lines of GPL-ed code, not the FSF.

Or was this section of the GPLv2 just a false promise to lure developers into writing 1 billion lines of code?

Licence text and fabs

Posted Oct 5, 2006 8:45 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

> I'm not worried about freeloaders as long as it's economically unfeasible
> for them, both the GPLv2 and the GPLv3 has loopholes that enable freeloading
> and leaching. I'm alot more worried about having a fair and clear deal
> towards developers, because they wrote this 1 billion lines of GPL-ed code,
> not the FSF.

Of course, that's assuming no developper shares the FSF concerns, which is patently false. You can no more claim the developers support as the whole that the FSF can

Licence text and fabs

Posted Oct 5, 2006 9:18 UTC (Thu) by mingo (subscriber, #31122) [Link] (1 responses)

Is there any reason why you have not replied to my points below, i think they are important:

 Thus, it is not the intent of this section to claim rights or contest
 your rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or
 collective works based on the Program.

 You must ship 10 free samples of hardware and design specifications
 to the FSF headquarters and offer free on-site training and free
 tools for tweakers to be able to make use of their right to tweak.

Will the GPLv4 perhaps include:

 You may only distribute copies of works that are GPL-compatible in their 
 totality. Aggregation with any non-GPL work is prohibited.

is that the plan?

Future contributors will be asking me that, and I have no answer for them, do you have any?

Licence text and fabs

Posted Oct 5, 2006 11:19 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> And you are still missing the larger point as well. This portion of the
> GPLv3 is a seemingly small but dramatic departure from the spirit of the
> GPLv2,

To be honest, I didn't feel I needed this portion of your argument needed to be rebuted, as better people than me (Alan Cox for example) already stated they didn't feel it was the case.

I happen to agree with them.

Licence text and fabs

Posted Oct 5, 2006 7:31 UTC (Thu) by mingo (subscriber, #31122) [Link] (3 responses)

And no-one has explained it to me yet how it would reduce the amount of DRM in hardware if the GPL adopted anti-DRM language. All the indicators are that such a step /increases/ the amount of DRM done, because a fair portion of current embedded Linux would switch to other OSs. (partly because they are forced by other content makers to use DRM, partly because they'd sense a fundamental uncertainty in the licensing foundations of Linux.)

Also, the FSF should be well aware of the fact that it's always the first layer of software that matters for DRM, most of the time. So it's the kernel that has to deal with hardware and DRM issues. It's the kernel's contribution rules that you are playing with here. In fact without the kernel moving to GPLv3 the whole DRM section is almost totally pointless. (unless you count Hurd, which would have to remove tons of Linux code to begin with, if it wants to switch to the GPLv3) The remaining free software projects are mostly just curious bystanders. Yeah, i oppose DRM just as much as you do, but do /you/ have to deal with the fallout of this happy activism?

Licence text and fabs

Posted Oct 5, 2006 8:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

> And no-one has explained it to me yet how it would reduce the amount of DRM
> in hardware if the GPL adopted anti-DRM language

Read the transcripts of MP discussions when local EUCD/DMCA law are passed. One question they ask is "it will help Hollywood, but will blanket legal DRM protection/mandate hurt any other economic actor ?". Of course the major representatives try to convince them the answer is no.

The GPLv3 is a very clear way to show MPs blanket legal DRM protection/mandate hurts someone.

Licence text and fabs

Posted Oct 5, 2006 9:37 UTC (Thu) by mingo (subscriber, #31122) [Link] (1 responses)

The GPLv3 is a very clear way to show MPs blanket legal DRM protection/mandate hurts someone.

How would that happen in practice? Lets take Tivo, an FSF-selected example (presumably because it's the best example of harmful DRM they could find), ok? How does the GPLv3 show that blanket legal DRM protection hurts someone, in the Tivo example? Lets assume the kernel goes GPLv3. Please outline the scenario of likely action that would/could happen in your opinion.

The only way i could theoretically imagine would be for a large non-DRM hardware base with GPLv3 kernel+userspace to be built up right now, which industry would complain loudly if a change in laws would made their product illegal to distribute under the GPLv3. Given that essentially every medial player and every mobile phone on the market includes some form of DRM currently, as per the wishes of the content industry (whose content consumers actually want to enjoy), how do you see the likelyhood of that happening in practice, /without/ a huge body of free content that consumers would be equally crazy about?

Please outline the scenario that you think would/could happen.

Licence text and fabs

Posted Oct 5, 2006 10:51 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> How would that happen in practice?

Very easily.

Mr V. goes to his local MP to make DRM mandatory and protected by law on all media processing boxes. The MP asks if it will hurt someone. Mr V says "of course not, it will only catch evil pirates".

Mr F can then come saying "But this will ban use of FLOSSTV, which is licensed under the GPLvx which is uncompatible with the proposal" competition and free market is good, you can't do that. This is a strong argument.

Right now M F can only say "But this will harm FLOSSTV, which is licensed under the GPLvx which intent/spirit is uncompatible with the proposal" competition and free market is good, you can't do that. This is a weak argument, spirit and intent count for zip.

In case you think I'm making all this up, I'm only repeating from memory some of the arguments used in the French Parliament when the EUCD directive was translated in local law this year.

Some of the articles proposed by the majors were clearly uncompatible with existing Free Software license terms and could be amended. For others the uncompatibility was not so clear cut and unfortunately opposing them proved impossible.

The harm BTW was not only FLOSS-side. The law hurt numerous actors, but they all found out nothing but the most blatant problems (such as law/license uncompatibilities) had any weight against the majors' money.

Licence text and fabs

Posted Oct 5, 2006 7:36 UTC (Thu) by mingo (subscriber, #31122) [Link] (7 responses)

Which again is academic because actual DRM keys do not look like yours.

[sarcasm] Oh, thank goodness no-one else will think of this and they will not produce DRM keys that are copyrightable. Phew, that was close, i was almost getting worried! [/sarcasm]

Licence text and fabs

Posted Oct 5, 2006 8:42 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (6 responses)

Oh, some people will think of it.

But you know what? I don't care. They'll be laughted out of court since judges have a very low tolerance for this kind of legal trick.

The judge's test will be the following: are the copyrighted/trademark/whatever parts functionnaly necessary? If the answer is no and they've been knowingly inserted only to make copyright/trademark/whatever law conflict with another legal requirement, game over. You're trying to game the law and wasting the judge's times. Too bad for you if you loose some IP property in the process, no one forced you to expose it.

Even if someone managed to construct some functionnal reason for the use of these parts, copyright/trademark/whatever law wouldn't win automatically -- the judge would balance one requirement against another, and the more artificial convoluted one would lose.

Licence text and fabs

Posted Oct 5, 2006 9:12 UTC (Thu) by mingo (subscriber, #31122) [Link] (1 responses)

Sensing some fundamental disagreement that causes us to argue circularly i have read back some of your other replies in other threads and I think your core argument in favor of DRM is in one of your sentences:

  GPLv2+DRM happens to enable corporations to do the BSD on GPL code they    
  wanted all along.

Does that fairly summarize your points around DRM up in essence?

If yes then i contest your suggestion above. (i thought i did that before, but hey)

GPLv2+DRM still gives us the source code. BSD doesnt. Tivo gives us their source code for the DRM-ed kernel they utilize. So where does the GPLv2+DRM combination create the "BSD on GPL code" situation in the Tivo case? I'd really like to understand your logic here.

I'd agree with you that if GPLv2+DRM would be equivalent to the BSD then that would not be acceptable to me and i'd find little joy in hacking the kernel. (when i started developing Linux years ago i made a conscious choice against BSD, mostly due to their license)

Licence text and fabs

Posted Oct 5, 2006 11:16 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> So where does the GPLv2+DRM combination create the "BSD on GPL code"
> situation in the Tivo case

Very easily, you only need to make DRMed PCs the cheap norm and open PCs the expensive exception.

for every-market-without-GPLv3-software ; do
{
// Get MS/Hollywood money and help
release (spec-mandating-DRM-on-next-hardware-gen);

// Making exceptions costs money and the majors don't like hairies
apply (DRM-on-GPLv2-software);

// Need some GPLv2 devs with access to DRMed hardware
// Or the FLOSS ecosystem will collapse brutaly, regulators notice
// and floss users not buy the new hardware generation
hire (some-gplv2-devs-to-do-life-support);

// This only takes a few years with modern lifecycles
wait (DRM-hardware-is-the-norm);

// This takes a tad longuer, as hairies will hoard previous gen hardware
// However without hardware access they're bound to disappear and find
// a cheaper hobby
wait (floss-hobbyists-have-disappeared);

// Without hobbyists there are less floss devs on the job market
// All the new software contributions come from competitors
// May as well make a consortium and work together
// Denying entry to new would-be competitors
replace (GPLv2-software,consortium-software);

note (floss-in-market-nonexistent);
}

This is the usual BSD pattern of hire key community people, stop contributing downstream, redeploy once the community is anemic

Licence text and fabs

Posted Oct 5, 2006 10:15 UTC (Thu) by mingo (subscriber, #31122) [Link] (3 responses)

But this is not "another legal requirement". This is the GPLv3's attempt to extend its scope to works created independently of that work. How do you know that it's "defendant laughed out of court" instead of "GPLv3 plaintiff's copyrights being judged unenforceable, due to misuse of copyright"?

Licence text and fabs

Posted Oct 5, 2006 11:33 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

> How do you know that it's "defendant laughed out of court" instead of "GPLv3
> plaintiff's copyrights being judged unenforceable, due to misuse of
> copyright"?

As the GPLv2 enforcements efforts have shown, a judge will tend to consider someone availing himself of some provisions of a licence (free code access) has no legs to stand on contesting the obligations part later (as long as the obligations are clearly expressed).

Nobody forces anyone to use copyrighted/trade secrets/trademarks as DRM keys.
Nobody forces anyone to use GPLv3 software.

Licence text and fabs

Posted Oct 5, 2006 14:25 UTC (Thu) by mingo (subscriber, #31122) [Link] (1 responses)

Oh, the GPLv2 enforcements so far were mostly about clear-cut violations like "not giving out the source code", or trying to hide the origin of the code and copyright ownership by modifying binaries.

I believe you are over-simplifying the picture. A more realistic case would be like this:

- hardware maker fully living up to all provisions of the GPL. Source code made available on their website, etc.

- separate content provider (provider of expensive GPS maps, movies, pay-per-view events, etc.) insists on copy protection of their content.

- hardware maker use of DRM to restrict the extraction of that content from the hardware, by only allowing trusted installs approved by the hardware maker.

GPLv3 copyright owner sues. The judge will weigh: on the one side, the legitimate interests of the content owner, and the trade secret of the hardware maker, and the contractual obligation of the hardware maker to not make the content copiable, against the interest of the GPL owner, who gets his modified source code. The hardware maker even contributed back to the copyright owner's project.

But besides the source code (which was the main object of trade in a previous version of the same license, which was "similar in spirit"), the GPL work owner now also insists on a new-found and pretty far-fetched "right to tweak the hardware".

The hardware does not look all that tweakable to the judge, it's a sealed pink plastic cube. The copyright holder insists on the defendant either ceasing distribution (which likely bankrups the defendant) or requires the giveout of the trade-secret crypto key (which likely bankrupts the defendant too, because he was contractually obligated to the content owner to protect stuff and to not give out the key).

Furthermore, the judge will look who the people with this "right to tweak the hardware" are. They describe themselves as certain "hackers", and they want to "hack on the hardware". To do good stuff, amongst them, as the defendant will point out, "to enable pay-per-view piracy".

On the other hand, the judge will weigh the "harm" that the denial of this request for keys causes the copyright owner, but that harm seems rather remote: the copyright owner has only a personal interest in modifying the hardware. Out of curiosity. No matter how difficult technically. And he could run the manufacturer's code on his home PC. No, of course he does not want to watch pirated content.

Do you think the decision is so clear-cut against the defendant, especially if the defendant insists on a jury trial?

Licence text and fabs

Posted Oct 5, 2006 15:22 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

The answer is simple :

1. hardware maker uses GPLvx code -> he's now bound by the license requirement

2. here comes content provider, asking something incompatible with the hardware maker licensing obligations :
A. hardware maker can refuse
B. hardware maker can accept to breach his legal obligations, and be sued
C. hardware maker can accept, replacing the GPLed code with something compatible with the content provider demands. He won't be sued. If he's smart, he'll make the content provider pay for the change

No judge will defend someone promising to do foo to A and not-foo to B.

Licence text and fabs

Posted Oct 5, 2006 18:44 UTC (Thu) by espeer (subscriber, #39062) [Link]

stevenj wrote:

> The only problem comes if the manufacturer wants the ability to modify
> the software while denying this ability to users.

No, by not providing keys, hashes or whatever, the manufacturer is not
denying the user's ability to modify the software at all. The GPLv2
guarantees access to the source - so you can modify it all you want. You
may not be able to run your modified version on that particular
manufacturer's hardware, but you are most welcome to develop your own
hardware to run it on (or run in on a suitable open hardware platform).

The question here is, should we be dictating requirements on the openness
of hardware in GPLv3?

the beef

Posted Oct 2, 2006 22:34 UTC (Mon) by coriordan (guest, #7544) [Link] (18 responses)

Thanks for your reply.

why does it single out keys from the myriads of existing ways of restricting hardware capabilities

There are two motivations for singling out keys. One is that rigging hardware to require a key, and then distributing the hardware without the key, is something that is currently being done, and is even supporting a business model. It is practical and profitable. A second is that closing this loophole is simple and can be done in a way that only restricts the handful of people who are pushing things through that loophole.

There will always be other loopholes, but maybe no one (or nearly no one) will exploit them because they are difficult, or impractical, or unprofitable. Burning software onto ROMs or locking the harddrive in a safe are indeed effective ways to prevent people being free to modify the software.

The reason those scenarios are not being adressed by GPLv3 is because the two motivations that exist for keys do not (currently) exist for physical lock-out. Physical lock-out is not in wide spread use, at least not for desktop computers (I'm open to correction on that point, but the next point is reason enough on its own). Phyical lock-out is not easy to fix - not without inconveniencing users or manufacturers.

GPLv3 only influences hardware design in the rare case when the designer is looking for ways to prevent users from being able to tinker with the software. Less tinkering means less contributors. We don't gain from helping people who are trying to prohibit tinkering.

About talking to FSF, the best way to do this is through the commenting system. Just go to your sent emails folder, copy the text that explains your issue, and paste it into the dialogue box on gplv3.fsf.org/comments after selecting that sentence about keys. If you do this, your comment will be viewable by the public, other commenters will be able to comment on it or note that they agree with it, and then your comment will go to the 130 people in the four discussion committees (business, lawyers, software projects, individuals). The committees can also do a better job than FSF can of responding to a large volume of input, and according to members of the committees, they are being listened to.

As for purple, it doesn't scare me.

Re: the beef

Posted Oct 2, 2006 23:10 UTC (Mon) by mingo (subscriber, #31122) [Link] (14 responses)

There are two motivations for singling out keys.

Thanks for acknowledging that the GPLv3 does single out keys to limit the use of GPL-ed code on certain hardware. The GPLv2 did not do that, the fundamental freedom to run code on any hardware is very much in the GPLv2. A change to that concept results in a license that is not "similar in spirit", at least to me (and this should answer your original question of why i think the GPLv3 is not similar in spirit to the GPLv2). The GPLv2 did not try to define "source code" in a nonsensical way.

The key in question, no matter how inconvenient to me as a developer, is a property of the hardware, not a property of software. It is a bad precedent (and morally questionable) to extend the reach of the license to hardware design details. I thought only Hollywood wants to do that ...

Where will we stop on this slippery slope of adding more and more restrictions to our license to remove inconveniences we meet during our everyday life? Will we require hardware makers to open up specifications in the future, via the license? Will we require hardware makers to contribute money to free software developers? Where will it stop? What is the moral line? So far you have not drawn any moral line into the sand. The GPLv2 was simple in that regard: it was about the source code and the ability to copy, run and modify code. (And no, "modify" did not include "modify in any way contemplated by the developer, on any hardware, and in a way convenient for the developer".)

Re: the beef

Posted Oct 3, 2006 1:03 UTC (Tue) by stevenj (guest, #421) [Link] (13 responses)

The GPLv2 did not do that, the fundamental freedom to run code on any hardware is very much in the GPLv2. A change to that concept results in a license that is not "similar in spirit"

As has been explained repeatedly, you have the freedom to run the code on any hardware you want. What you don't have is the freedom to distribute GPLv3'ed code as part of hardware that forbids the user to run modified versions.

Re: the beef

Posted Oct 3, 2006 4:42 UTC (Tue) by svkelley (guest, #37299) [Link] (11 responses)

This is absurd. One is now restricting use of hardware if I don't allow someone to hack the GPLv3 software on the device? Complying with providing the source code is not enough? I now must give one access to programming the hardware itself, if I can do the same in the field using my special loader?

Why?

So I have a portable electronic device that I manufacture and sell. I comply with all aspects of providing access to the source code and any and all mofidications. Yet, if I do not allow one to "hack" this device through either encryption, private key, signed loader -- I am now in violation?

In my opinion, that is the quickest way to kill commercial embedded Linux development.

Sean V. Kelley

Re: the beef

Posted Oct 3, 2006 6:30 UTC (Tue) by gmaxwell (guest, #30048) [Link] (2 responses)

If you don't want someone modifying a device... don't pass ownership on to them.

If you pass ownership on to someone else but then attempt to prevent them from modifying it, I wouldn't just call that a violation of the intent of the GPL... I'd call that fraud.

Re: the beef

Posted Oct 3, 2006 21:44 UTC (Tue) by sepreece (guest, #19270) [Link]

There are, of course, many devices in our lives whose manufacturers make it hard or impossible for us to modify them. That's not in any way fraud, so long as they made a good-faith effort to make sure the device does what it was sold to do.

Re: the beef

Posted Oct 3, 2006 22:36 UTC (Tue) by liljencrantz (guest, #28458) [Link]

If you pass ownership on to someone else but then attempt to prevent them from modifying it, I wouldn't just call that a violation of the intent of the GPL... I'd call that fraud.

By your reasoning, credit card companies are comitting fraud by not letting you easily change the identification on credit cards to match those of Bill Gates.

Re: the beef

Posted Oct 3, 2006 14:47 UTC (Tue) by mingo (subscriber, #31122) [Link]

This is absurd.

yes, it is.

In my opinion, that is the quickest way to kill commercial embedded Linux development.

If the kernel moved to the GPLv3, it would be, yes. Given that the kernel is the closest to the hardware, we kernel developers will be the first ones to see the bad effects of any bad construct within the GPLv3 affecting hardware. That is i think partly the reason why the growing resistance against the GPLv3 comes from the kernel community.

And even if the GPLv3 does not yet limit wide aspects of the hardware (only certain types of keys are included for the moment), a dangerous precedent is set and the possibilities for excuses to widen the definition of "Source Code" are unlimited.

The GPLv3 in this point significantly departs from the spirit of the GPLv2, which explicitly grants the freedom of unlimited end-use and the freedom of not having GPL-ed code control works (such as hardware) independent of that GPL-ed code. Even if that end-use or hardware is highly inconvenient (and thus makes the modification of software harder) for certain classes of developers: it is an atomic bomb, a landmine or a Tivo.

Re: the beef

Posted Oct 4, 2006 9:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (6 responses)

> This is absurd. One is now restricting use of hardware if I don't allow
> someone to hack the GPLv3 software on the device

In case you didn't notice the GPL was always about passing "permission to hack" downstream (unless hacking was materially impossible, such as a ROM but DRM is not a ROM - if it were you couldn't hack the device either).

What's absurd is people having chosen to forgot this basic, if inconvenient fact.

The DRM=ROM argument is stupid - if DRM=ROM just use ROM and be done with it. Neither the GPLv2 nor the GPLv3 forbids it. That people beg for being allowed to use DRM instead of ROM clearly shows they are different.

Re: the beef

Posted Oct 4, 2006 13:59 UTC (Wed) by sepreece (guest, #19270) [Link] (5 responses)

Of course ROM and DRM are different. The question is whether they are difference is qualitative or quantitative. The intended end result, from the device distributor's point of view, is the same: the end user can't change the software in the device so that it does things other than what it is supposed to do.

The FSF is arguing that the difference is qualitative, and has created the "you must pass along the same rights you have"[*] argument to support that point. Nothing in the four freedoms provides a base for such an argument, but, hey, they're reasonably inventive people.

The device distributors would argue that the difference is quantitative; that preserving the ability to repair devices lowers the lifecycle cost of the device. If they had to budget for recalls to replace devices when software defects were discovered in the field, they would have to charge more for the devices to get the same profit margin.

Yes, the device distributors want to have a right on the device that the end user does not have, as a condition of using the device with their service. Some of us honestly don't have any problems with that; the FSF obviously does. That's fine - I just wish they would assert their conviction that an additional freedom is required, rather than rationalizing.

--
[*] Actually, of course, it's a subset of the rights you have - just the ones covered by the license. Also, they usually ignore the fact that in typical cases (like Tivo and cellphones), the device distributor actually asserts rather more rights over the device than are consistent with a simple transfer of ownership to the end user; they usually claim most of the rights to administer the device, at least when it's used with their service.

Re: the beef

Posted Oct 4, 2006 19:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (4 responses)

> The intended end result, from the device distributor's point of view, is
> the same: the end user can't change the software in the device so that it
> does things other than what it is supposed to do.

What they actually care about is the device behaviour, and it's not even an absolute requirement, or they'd be selling welded steel enclosures not cheap plastic ones anyone can open to install mod-chips.

The intended end result is to make the device somewhat harder to modify as long as it does not cost too much. Shock! DRM is only about saving a few bucks! One could easily argue the costs of having to forgo DRM are largely couterbalanced by free access to the GPL software pool.

> preserving the ability to repair devices lowers the lifecycle cost of the
> device

Nothing forbids repairing devices in a GPLv3 world. It only forbids repair accesses closed to the device owner. That screwdrivers are widely available never stopped an appliance manufacturer from using standard screws, precisely because lowering lifecycle costs has priority over keeping the owner out at all costs.

> Yes, the device distributors want to have a right on the device that the
> end user does not have, as a condition of using the device with their
> service.

This argument does not stand:

1. many of the DRM-ed devices are intended for standalone use (media players...) with the service part completely absent or optional

2. if it's really a condition of using the service then there is something called "terms of service" for this, and it's not even deprecated by DRM, since many terms can not be DRM-enforced.

If the device is sold to the user what he does with it is none of the service provider business as long as it does not impact the service infrastructure (if it does impact the service infrastructure you can detect it infrastructure-side without device-level DRMs)

If the service absolutely depends on total control on the appliance there's a well known solution: providing the device free of charge to the user, and recouping costs with the service fee.

Of course some businesses want to sell appliances without passing control to the user, have customers provide seed money for services by paying for the required appliances beforehand, benefit from GPL code without allowing the tinkering conterpart the GPL was about and so on.

I want a pony too. Will I get one?

Re: the beef

Posted Oct 7, 2006 1:38 UTC (Sat) by vonbrand (guest, #4458) [Link] (3 responses)

The intended end result is to make the device somewhat harder to modify as long as it does not cost too much. Shock! DRM is only about saving a few bucks! One could easily argue the costs of having to forgo DRM are largely couterbalanced by free access to the GPL software pool.

One could also easily argue that the costs of other software alternatives is not significantly higher, and moreover the GPLv3 (and possibly even more agressive GPLv4 to follow, and...) creates a high potential liability cost ("But, yerhonnor, we used GPLv3ed code because it was cheaper, and the plaintif modified said code and our so modified device cut off her feet" can very easily be answered by "Then it was reckless design to leave it open to modification").

Nothing forbids repairing devices in a GPLv3 world. It only forbids repair accesses closed to the device owner. That screwdrivers are widely available never stopped an appliance manufacturer from using standard screws, precisely because lowering lifecycle costs has priority over keeping the owner out at all costs.

You'd be surprised then by the strange screws I've had to deal with... plus swabs of paint over screws, etc. Point of most of them was clearly making it harder to get inside, or making modifications visually obvious to whoever is handling the device. What if the "handling" of the device is remotely, over a network?

Re: the beef

Posted Oct 7, 2006 12:44 UTC (Sat) by nim-nim (subscriber, #34454) [Link] (2 responses)

> "But, yerhonnor, we used GPLv3ed code because it was cheaper, and the
> plaintif modified said code and our so modified device cut off her feet"
> can very easily be answered by "Then it was reckless design to leave it
> open to modification"

But was the reckless design to use GPLv3 or DRM instead of ROM? If you have this kind of liability hanging over your head, you can certainly afford ROM, or protected hardware jumper, or whatever

Re: the beef

Posted Oct 8, 2006 1:44 UTC (Sun) by sepreece (guest, #19270) [Link] (1 responses)

If the TC is good enough, there's no need to go to ROM. As noted elsewhere, there are disadvantages to using ROM. And it's usually sufficient to make it difficult to modify, so the user clearly has to jump over intended barriers (and thereby demonstrate that it's their fault, and not the manufacturers).

I'm neither a lawyer nor on the business side; I don't know what factors they use in deciding how hard to make it to crack the security.

Re: the beef

Posted Oct 8, 2006 9:12 UTC (Sun) by nim-nim (subscriber, #34454) [Link]

> As noted elsewhere, there are disadvantages to using ROM.

But are the disadvantages sufficient to refuse using GPLv3 software if it implies ROM?

> And it's usually sufficient to make it difficult to modify, so the user
> clearly has to jump over intended barriers (and thereby demonstrate that
> it's their fault, and not the manufacturers).

This part is easily done without blocking GPLv3 by making the update process interactive and spewing big red warnings if the updating binary is not signed by the manufacturer

Re: the beef

Posted Oct 3, 2006 15:16 UTC (Tue) by mingo (subscriber, #31122) [Link]

Firstly, the GPLv2 did not try to control works independently created of the works we created. I'm curious about the basis for your claim that it is "similar in spirit" for the GPLv3 to suddenly break this promise by trying to control hardware that includes no GPL-ed code at all (and is hence outside of the 'moral scope' of our license) - just because it's distributed together with GPL-ed code.

Secondly, does your interpretation also mean that, by recursion, in future versions of the GPL we should brace ourselves for the prohibition of the distribution of GPL-ed code on the same hardware that also contains non-GPL code? (for example closed-source code?) Because controlling that is within the exclusive rights of the copyright holder too, and by your argument it's fine to do it, as long as it makes the modification of the system more convenient?

Thirdly, the mechanism you (and the GPLv3) are proposing breaks a fundamental symmetry of the GPLv2: that if end-use and distribution together with certain independent works by one person is allowed, the same end-use and distribution with other independent works is allowed for another person too.

Let me give you an example: lets suppose i take the binary packages of the Tivo and run it on my PC. The only GPL-ed code on that system will be those binary packages. I can run it on my PC, and i can distribute that PC. But if someone else puts those very same unmodified packages on a Tivo, he would not be able to distribute that system. Nothing else on either the PC or on the Tivo is GPL-ed - only those binary packages. The code that is used is totally the same in both cases, and the hardware (and other software) is neither a modification or a derivative of any GPL-ed code. But the GPLv3 forbids the distribution of the Tivo system!

Fourthly, as the above example I gave to you, the practical effect of the prohibition of distribution of certain combinations of unmodified GPL-ed works with other, independent works simply punishes certain types of end-uses, and hence limits those end-uses. Legally it might not be an end-user limitation (because hey, in theory everyone has the ability to build a Tivo from scratch in private, right?), but the end-effect is still very much the same.

Re: the beef

Posted Oct 2, 2006 23:17 UTC (Mon) by mingo (subscriber, #31122) [Link] (2 responses)

Do you realize that the only effect this will have on hardware designers is not the removal of DRM but the removal of Linux? That is what reduces the number of contributors. There's no DRM in use (or planned) where it's Linux that people desire. The only DRM i can see is where there's some body of content owned by someone else, not us, which content people actually want: pay-per-view content on the Tivo, console games, DVDs, etc. So please give me a single example of current DRM use where it's not some other people's (valuable) content that is being restricted, but purely free content.

So instead of growing the community, you are shrinking it. Furthermore, you are also isolating lots of users from being able to experience and understand the power of free software, because you are making it artificially harder for them to use the closed content they are interested in.

Re: the beef

Posted Oct 3, 2006 1:09 UTC (Tue) by stevenj (guest, #421) [Link] (1 responses)

Do you realize that the only effect this will have on hardware designers is not the removal of DRM but the removal of Linux?

If the Linux kernel developers would prefer to subsidize DRM'ed hardware with their efforts, in order to gain more users and contributors at the expense of those users being about to modify the code, that is their choice. They can continue to use v2. (And anyway, it looks like they don't have much choice barring lengthy relicensing efforts.)

This is no different from the fact that GPLv2 does not eliminate all proprietary software. If you want to maximize the number of users and contributors to your code, use BSD.

Your double standard here is confusing.

Re: the beef

Posted Oct 5, 2006 19:48 UTC (Thu) by AJWM (guest, #15888) [Link]

> If you want to maximize the number of users and contributors to your code, use BSD.

Okay, I'll bite. How does the BSD maximize contributers?

FSF is creating a problem that never existed!

Posted Oct 2, 2006 11:25 UTC (Mon) by mingo (subscriber, #31122) [Link]

We should not only have the ability to see the process, but also the ability to modify it.

Huh ? Can you do it with Linux ?

yes, i can do it with Linux, and more than that, i have already done it with Linux. You can fork Linux anytime, and people do, routinely. If Linus messes up then people just take over. It's very easy to do.

If Linus does not like your approach - he'll write thing himself and your contributions will be thrown away. Linux will include the things Linus likes and only things Linus likes.

Please let me just prove how wrong you are, with real events. Linus wrote this about "Priority Inheritance":

"Friends don't let friends use priority inheritance. Just don't do it. If you really need it, your system is broken anyway." .

So by your logic, Linux would have no Priority Inheritance until Linus maintained it, because he monopolizes the decision process and goes against patches that he feels strongly about?

How come then that just 9 months after Linus wrote that, the v2.6.18 Linux kernel added support for priority inheritance?

And i could list dozens of examples. So far I have yet to see any technical issue over which Linus isnt keeping an open mind. Even if the end-result is embarrasing to the position he took earlier. Even hugely embarrasing sometimes. (Those are the dangers of an open decision process.)

And why is it so? Because Linus has no control over forks, and he has no unfair advantage. (He does actually know quite a few things about Linux and he is also a very good maintainer, so that is a real advantage he has over forks - but anyone with better abilities can replace him and the barriers to that are low.)

FSF is creating a problem that did not exist before!

Posted Oct 2, 2006 14:19 UTC (Mon) by mingo (subscriber, #31122) [Link]

The people who do care can always remove "or later" clause FSF already did the most of the work: "or later" clause is not part of license, but only part of the grant text.

This still misses the point. Nothing that i do in the future can affect the rules of the contributions i did in the past. Still there's a single person on this planet who can do it: RMS has the legal power to retroactively change the meaning of my contributions, by releasing a new version of the GPL. (Yes, i trusted and empowered him to be able to do it by contributing "or later" licensed code, and i might regret it if he releases a new version of the license that is contrary to what i thought the GPL was about and people would be able to co-opt my code under a later version of the GPL without me being able to merge back their modifications into my codebase.)

Or is your point that RMS does not have this legal power vested in him and only him? Or if you agree with me that this power does exist, dont you think this power has more moral obligations attached to it than trying to advance his own moral rules?

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 2, 2006 18:33 UTC (Mon) by landley (guest, #6789) [Link] (15 responses)

The bogeyman the FSF has been waving for years is "we may have to ammend
GPL if a court case proves it unenforceable". This didn't happen, instead
a bunch of case law has piled up around the world showing that GPLv2 is
very enforceable.

The FSF isn't doing GPLv3 because GPLv2 is no longer useable. The FSF is
doing GPLv3 because the FSF now wants more. With GPLv2 you still get back
modified source code, but that's not enough for the FSF. People were
burning code into ROM 20 years ago, but now the FSF wants to dictate how
the hardware is made, and is using the "or later" clause to do it.

As Darth Vader said: "I am altering the bargain. Pray I don't alter it
any further."

Rob

FSF is creating a problem that did not exist before!

Posted Oct 2, 2006 20:08 UTC (Mon) by mingo (subscriber, #31122) [Link]

As Darth Vader said: "I am altering the bargain. Pray I don't alter it any further."

Hehe ;-)

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 2, 2006 21:56 UTC (Mon) by stevenj (guest, #421) [Link] (13 responses)

People were burning code into ROM 20 years ago, but now the FSF wants to dictate how the hardware is made

If you're going to criticise GPLv3, try to do so without distorting the facts.

The DRM provisions don't prevent ROMs. They only affect the situation where the hardware manufacturer can upgrade the software but the user can't, which is relatively new. The FSF has explained this repeatedly:

But if there really are regulations which forbid software on certain devices from being modified once it's installed, it's still possible to use software licensed under the GPL — simply burn the software into a ROM.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 3, 2006 0:12 UTC (Tue) by mingo (subscriber, #31122) [Link] (12 responses)

but now the FSF wants to dictate how the hardware is made

If you're going to criticise GPLv3, try to do so without distorting the facts.

Your (rather impolite) statement is directly contradicted by pro-GPLv3 people in this very thread acknowledging that indeed the FSF wants to dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on such hardware)

Of course what this will result in is the non-use of GPLv3 software, not the change of hardware - so what will be achieved is only harmful to Linux and free software in general. The only entities that will win from the DRM language are Hollywood and Microsoft.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 3, 2006 2:15 UTC (Tue) by stevenj (guest, #421) [Link] (8 responses)

Your (rather impolite) statement is directly contradicted by pro-GPLv3 people in this very thread acknowledging that indeed the FSF wants to dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on such hardware)

My statement was directly referenced to the authors of GPLv3, not to your paraphrasing of "pro-GPLv3 people". Moreover, I never suggested that the FSF didn't want to restrict certain aspects of the hardware design.

All I said was that the FSF has clearly stated it has neither the intention nor the desire to restrict the use of ROMs, which had been falsely implied above. (This is also backed up by a direct quote from Eben Moglen in another post of mine above.)

If you find it impolite to point out that the facts are being distorted by certain posters, I find the distortion itself even more impolite.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 4, 2006 6:42 UTC (Wed) by svkelley (guest, #37299) [Link] (7 responses)

So, letś say you have some GPLv3 code you wrote that say deals with rotating images. Caterpillar has a new vehicle that runs embedded Linux for its driver's display. The software is used for the backup camera. if Caterpillar doesn't allow you access to their firmware with an unsigned loader, you have the right to revoke use of the code?

This is bull. The original intent of the code had nothing to do with tractors or what ever. Again, I feel this whole motivation is without merit, spiteful, and dictatorial.

Why would they care if you change the code?

Posted Oct 4, 2006 9:41 UTC (Wed) by kleptog (subscriber, #1183) [Link] (6 responses)

Where does this "right to revoke" come from? You don't have the right to do anything, the Caterpiller violated your licence. If you don't like that effect, don't use that licence. Duh.

My real questions are:

1. Why would the people who made the tractor not want to give you the code? It doesn't matter to them at all, does it?

2. Why would they care if you changed the installed code? In your example I can't even see why they'd want to stop you making your own changes. Changes would void the warrenty obviously, but that's about it... What is this "signed bootloader" acheiving in the Caterpillar?

Similarly, I can't imagine why a TiVo-like device would want to stop you changing the userland GPL code. They control the kernel, so letting people do whatever they like in userspace seems like the obvious thing to do.

Why would they care if you change the code?

Posted Oct 4, 2006 14:17 UTC (Wed) by sepreece (guest, #19270) [Link] (5 responses)

Caterpillar would not want you to be able to modify the code in their device because if you did, and ran over somebody because the device failed in use, the victim and the driver might both choose to sue the manufacturer for liability in the accident. And they might very well win.

For Tivo there are two issues: (1) their contract with the content owners almost certainly requires them to make a good-faith effort to assure that there is no point where a user can get access to unencoded content and (2) if someone installed software that allowed them to copy content out and subsequently posted such content for sharing, Tivo might well be sued for liability for the claimed losses of the content owner(s).

Companies have to factor their potential liability into the cost of using components. If they believe the financial risk of using the components is unacceptable, they'll go elsewhere.

Why would they care if you change the code?

Posted Oct 5, 2006 23:11 UTC (Thu) by svkelley (guest, #37299) [Link] (2 responses)

Well said. And when companies go elsewhere, Linux loses.

Why would they care if you change the code?

Posted Oct 7, 2006 14:35 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

Think it will fare any better if DRM is generalized?

Hint:
1. any general-purpose computer nowadays is multimedia-capable
2. media companies want to control all the devices able to play their stuff

Why would they care if you change the code?

Posted Oct 9, 2006 14:18 UTC (Mon) by malor (guest, #2973) [Link]

I'm not sure whether or not this was sarcastic, but if a company doesn't choose Linux in its DRM-locked product, what does Linux lose, exactly?

You are willing to sacrifice your freedom for a few points of *market share*? WTF are you thinking? The whole point of an open source operating system is to be free, except when freedom would result in a few less locked-down systems running it?

Yes, requiring DRM keys will reduce Linux's market share. But the whole point of a free-software operating system is that market share doesn't matter. It's irrelevant. You're giving away the one thing in the whole deal that really matters for a shiny but meaningless bauble.

I'll give you three beads and a blanket for Manhattan. Deal?

Why would they care if you change the code?

Posted Oct 6, 2006 17:37 UTC (Fri) by spitzak (guest, #4593) [Link] (1 responses)

That's nonsense. Caterpillar would win the case, as you modified their device without their authorization!

Why would they care if you change the code?

Posted Oct 6, 2006 19:01 UTC (Fri) by sepreece (guest, #19270) [Link]

Most companies are willing to go to significant lengths to lower the probabilities. Juries do sometimes do things you would not expect. The cost of going to law are substantial, even if you win.

I can say that I know of design decisions taken specifically to avoid liability potential, over things with much less potential impact that replacing major parts of the operating software.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 4, 2006 9:58 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (2 responses)

> Your (rather impolite) statement is directly contradicted by pro-GPLv3
> people in this very thread acknowledging that indeed the FSF wants to
> dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on
> such hardware)

1. Who holds the DRM keys do not change how the harware is made.
2. GPLv3 does not forbid GPLv3 code use on DRM hardware, provided you give the users the keys (which you have or you couldn't deploy the software in the first place)

What it stops has nothing to do with hardware and everything to do with software distribution, which was the GPL function all along

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 4, 2006 14:27 UTC (Wed) by sepreece (guest, #19270) [Link]

While the specific restrictions are written in terms of software distribution, the result is the same, a requirement for the right to update a particular device, if that device is updatable. There's no way to look at that without seeing it as extending some degree of control over the particular device. It's not enough that the user be able to run the software on some hardware device, she has to be able to run it on the particular device in question.

FSF is SOLVING a problem that did not exist 10 years ago

Posted Oct 5, 2006 2:40 UTC (Thu) by jmorris42 (guest, #2203) [Link]

> GPLv3 does not forbid GPLv3 code use on DRM hardware, provided you give the users the keys

Everyone seems to be forgetting there is another option here. Tivo doesn't need to hand out their signing key to be GPLv3 compliant. Instead they could add one jumper to the board. Put a cap on it, apply power and it does three things: 1) erase the keyring and 2) permit loading unsigned binaries and 3) voids the warranty and makes the machine unable to obtain services from Tivo.

I think they could make a strong argument that this complies because a Tivo is both a hardware sale and a subscription service. It is somewhat reasonable for a service to be restricted to controlled hardware/software platforms. Installing the jumper would allow installing MythTV on the hardware but it wouldn't be a Tivo anymore.

Of course this is a bad example since Linux is going to remain GPLv2.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 9:01 UTC (Mon) by atai (subscriber, #10977) [Link] (57 responses)

The fact that someone named Linus Torvalds can manipulate people against an open discussion process with his own "karma" (in his own words) is a parody of free software, or open source, if you will.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 9:31 UTC (Mon) by mingo (subscriber, #31122) [Link] (56 responses)

The fact that someone named Linus Torvalds can manipulate people against an open discussion process [...]

You are attacking Linus (unfairly) instead of replying to the issues i raised.

One of those issues is right in your attack: "open discussion process". Why is the GPLv3 process only an open discussion process (like most of Microsoft's Shared Source is), why not an open decision process (like GPL-ed code and Linux itself is)?

Linux follows a closed decision process

Posted Oct 2, 2006 10:11 UTC (Mon) by man_ls (guest, #15091) [Link] (55 responses)

So now "Linux is an open decision process"? Excuse me, but I don't find the "join" or "vote" buttons on kernel.org. Whatever happened to benevolent dictators? Furthermore, how come "GPL'd code is an open decision process"? Excuse me again, but if I write some piece of code I get to decide the license, not some "open decision process". If I modify GPL'd code and distribute it, I can hardly choose the license.

What did you exactly mean? It is hard to follow a logical discussion if factoids like these are thrown around at every turn without explanation.

Linux follows an open decision process, and you can fork it if you dont like it

Posted Oct 2, 2006 10:59 UTC (Mon) by mingo (subscriber, #31122) [Link] (54 responses)

So now "Linux is an open decision process"? Excuse me, but I don't find the "join" or "vote" buttons on kernel.org.

It's called the /bin/cp command and it's very easy to do. You do:

cp linux-2.6.18.tar.bz2 my-forked-linux.tar.bz2

or if you have Git installed, do:

git clone git://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ my-forked-linux/

Linus has no monopoly on Linux. You are free to fork Linux anytime. In fact _I myself_ have a fork of the Linux kernel currently, and if Linus doesnt take that code for abitrary reasons then i will keep that fork and it might grow into something larger. (this has not happened so far, so i'm using my fork not as a maintainance fork but as a technical fork, to keep my latest stuff available to testers)

Yes, ask Linus and he'll readily call himself a dictator because: he does not want people to trust him, he wants people to trust the result of his work - and people can walk away and continue the work if Linus messes up. Linus will also readily call himself a stupid moron, so what?

And yes, this basic, symmetric competitive pressure of a fork has forced Linus to stay sharp and honest during all these years. This is not just a theoretical possibility, there were specific instances in the past where Linus messed up and kernel developers showed discontent - but Linus adopted to those concerns and kept a hostile fork from happening. This same competitive pressure forced RMS off the maintainership of some GNU projects when others just forked his code and did a better job.

Now where can i fork the GPL 'next version' decision process and create the next version of the GPL myself, without the huge barrier of having to write 350 million lines of code from scratch or having to convince all the authors that they accept my license and relicense to it? (where the former is probably easier than the latter)

That basic lack of competitive pressure on RMS has allowed him to stay unchanged during all these years. He is now using the "or later version" and "similar in spirit" legal wildcards (that RMS has put there himself and which clauses contributors left in the COPYING file due to trust or due to laziness), to do something that no person on this planet can do: change the licensing dynamics of 350+ million lines of code. Without any competitive pressure whatsoever. The "openness" of this process would make Microsoft proud i think ;-)

Linux follows an open decision process, and you can fork it if you dont like it

Posted Oct 2, 2006 12:18 UTC (Mon) by dmantione (guest, #4640) [Link] (33 responses)

Let me show how to make your own GPL:

wget http://www.gnu.org/licenses/gpl.txt
mcedit gpl.txt

... and modify to taste.

However, we're of course talking about Stalman's GPL, and Linus' kernel.
Linus is the primary kernel maintainer and, to say it blunt, does so in a
dictatorial manner. Of course Linus listens, but ultimately nothing gets
in the kernel (Linus' kernel) that Linus doesn't like.

It is exactly the same with the GPL. The FSF listens, but ultimately
nothing gets in that the FSF doesn't like.

Linux follows an open decision process, and you can fork it if you dont like it

Posted Oct 2, 2006 13:15 UTC (Mon) by mingo (subscriber, #31122) [Link] (30 responses)

Let me show how to make your own GPL:

your example is inapposite, it does not reply to the issue that i raised. See the highlighted portion of my sentence you replied to (and which you did not quote in your reply):

Now where can i fork the GPL 'next version' decision process and create the next version of the GPL myself, without the huge barrier of having to write 350 million lines of code from scratch or having to convince all the authors that they accept my license and relicense to it? (where the former is probably easier than the latter)

your suggestion to 'fork' the GPL will only fork the 340 lines of the license text itself! It does not 'fork' the 350+ million lines of codebase that is tied to the current GPL version. (That bond is either via trust or via laziness - both of which brings with itself moral responsibilities.)

my suggested solution to fork Linux will fork the whole thing, all ~7 million lines of it. All currently active developers could go over to the fork in a matter of a single day, if they wanted to. There are no barriers whatsoever to do this - and it's being done quite frequently, sometimes to prove Linus wrong.

Of course i never suggested it should be possible for a single person to fork the GPL license, together with the whole codebase. That would be insane. In fact, what i suggest is that it is so insane that no-one, not even RMS himself should have the legal power to unilaterally and in essence retroactively change the practical meaning of hundreds of thousands of contributions!

It is a very simple point that no-one from the FSF side was willing to confront heads-on so far. Perhaps because the thought is uncomfortable to them and the moral implications are so clear? Perhaps because giving up power and "letting the community go" its own way is so hard to do?

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 13:28 UTC (Mon) by man_ls (guest, #15091) [Link] (29 responses)

Again, since the option of choosing GPLv2 or any later version lies on you, the recipient of my gracefully licensed code, it is you who makes the decision, not Stallman.

I don't think it is such a big deal. Don't like v3, then stay with v2.

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 14:04 UTC (Mon) by mingo (subscriber, #31122) [Link] (28 responses)

Again, since the option of choosing GPLv2 or any later version lies on you, the recipient of my gracefully licensed code, it is you who makes the decision, not Stallman.

I think you are again skipping the fundamental moral question. (I dont think you are doing that intentionally, so please dont take this as an attack of any sort.)

Yes, of course the contributor decided under which license the code was released. He might even have left the "or later version" and the "similar in spirit" language in the COPYING file for one of the following factors:

- fully intentionally, understanding all the legal and moral implications of that decision and leaving the power to change the license with the president of the FSF, or

- due to misunderstanding the goals of the GPL and the legal implications of the license, not being a lawyer himself, or

- due to laziness, because legaleese is boring stuff when we can do some real coding.

So my question is: does your position reduce to: "You made your decision when you released the code, now deal with the consequences. The president of the FSF has the legal power to do things with your contributions you possibly never thought of before - it's really your fault you did not read the legal fineprint and let it happen!"?

Or do you agree with me that the president of the FSF is in a unique legal position (and has the unprecedented legal power) to change the license affecting the contribution dynamics of 350 million lines of code instantly? Do you agree with me that such huge power brings with itself a minimal moral obligation to at least /understand/ and adopt to the position of the community that created that codebase, instead of trying to advance his own moral position? Or if that adoption is not possible, to voluntarily give up his unique legal powers (which powers are contrary to the philosophy of free software itself) and remove the "or later version" language from the license and let people only pick a specific version of the GPL, hoping that people would consciously pick up his new version of the license for new contributions?

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 15:48 UTC (Mon) by madscientist (subscriber, #16861) [Link]

I understand your point, and agree with it to a certain extent. But let us turn this around: is it your contention, then, that because some developers did not fully grok the intent and ideals of RMS and the FSF when they licensed their code, that now RMS and the FSF should be permanently enjoined from pursuing their goals as they see them? That they should just pack it in and go home because their hard work and unwavering belief and advocacy (for little reward and often in the face of ridicule) for over twenty years has been misunderstood by a vocal subset of the community?

The idea that RMS and the FSF should subordinate themselves to the "will of the community" is such an obvious non-starter that I can't believe it's being seriously discussed. They are where they are today, and the GPL is where it is today, precisely BECAUSE they had a moral vision to which they steadfastly held, and they did not allow that vision to be diluted by people arguing for practicality or appeasement. You may not agree with them: many don't. But to the extent that ANYONE is surprised or dismayed by the fact that they are not allowing some kind of ultra-democratic "vote for your favourite clause" in the GPLv3, they are being naive IMO. Although the FSF wants to make the best license they can, and so they are soliciting input from every side, there was never any possibility that the GPLv3 would contain any language which did not align precisely with the vision of the FSF... how could it be otherwise?

The fact that some didn't understand that vision or where it might lead in the future is quite understandable. But saying that because of this, the FSF has some sort of obligation to abandon its principles and vision seems unfair... and, frankly, given what I know of the people involved, it will never, ever happen.

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 19:40 UTC (Mon) by cventers (guest, #31465) [Link] (6 responses)

Ingo,

I'll start off as some others have and say that I have a lot of respect
for your work. So I hope you don't hate me after I tell you why you are
wrong. :)

There are those of us that identify with "Free Software" over "Open
Source". We're the kind of people that would do something like watch RMS
speak or donate to the FSF.

As awesome as the Linux kernel is - fantastically portable, capable and
scalable, and as smart as the kernel community is (when I think of 'very
smart developer' your name is one of the ones that pops into my head),
you need to remember that you guys aren't the only software project out
there.

When Linus announced that Linux would not convert to GPLv3, there was
some disappointment and confusion over why. That's natural, to be
expected, and totally okay. As I've said before, I have no stake in
whether or not Linux uses GPLv3. And I think that most of the rest of our
community will cease caring about the license issue as it pertains to
Linux if the kernel developers wouldn't make so much noise about it. The
only case I can see concern bubbling back up in the future _for the
kernel_ would be if the kernel suffered a disaster that would have been
preventable under v3. We could debate whether or not it is possible that
this could ever happen, but that's beside the point.

I hear you that you are concerned about the power that the FSF wields
over code out in the world. But I ask you to consider that there are
people out there who are free software supporters that _want_ the GPLv3
to continue as it has been. If the FSF instead made "Really Free GPL", a
different license, the upgradeability clause many existing projects
deliberately use would be useless, and projects that wanted GPLv3 might
not be able to have it for the same reason that Linux would have legal
trouble moving forward.

The trouble with many of the attacks I've seen on RMS and the FSF is that
they presume that everyone else on Earth agrees, as if RMS is on some
diabolical power trip and is ignoring the world and using some kind of
power he shouldn't have to force us to all do his bidding. I'm sorry, but
RMS is not alone in thinking the anti-DRM provisions are an absolute
necessity. And I'm not talking about something we think would be nice.
It's not the "free music foundation". The issue is _only_ emphasized in
the license because in a world where electronic devices are more and more
a part of our lives, slowly displacing (to some extent) the general
purpose personal computer, our ability to _control_ our lives through
hacking will be diminished if we don't stand up for it.

And the really big, important point here is that RMS can't force anyone
to use his license. In fact, the most vocal community - the kernel
developers - are the one group who will be clearly unaffected by it. In
this latest discussion, there was talk about "voting with your code". Do
that! Your code is a very strong vote for that matter because you're damn
good at what you do.

Although I respect your concern about the moral question I don't share
it. Did it really take 16 years for everyone to figure out that the GPL
is a free software license, especially when the PREAMBLE section at the
very top of the license starts off talking about the freedom to modify -
the freedom that the new anti-DRM provisions are designed to defend?

I agree with you that the concern of some GPL users should be addressed.
But even the disagreement of a very vocal, large project using the
license (that technically can't use the new one anyway) should not
prohibit the rest of us from having the free software license we always
wanted and built for. I get that there are a number of people upset with
the FSF and the GPLv3 that would prefer the process not go on - most
certainly, not with the anti-DRM provisions. And this is really where I
get frustrated. I want to vote with my code! I want to vote for anti-DRM
provisions. I know that any patches I submit to Linux aren't going to be
votes for anti-DRM and that is fine with me, but when I do an independent
work I expect the right to choose a strong free software license. And
since that's what the GPL has always been - a free software license - it
is _wrong_ of others to tell us what we can't do with our license,
especially when they have the very natural right of not using it!

So why does the "or any later version" thing really worry you?

1. Joe can take my code and distribute it under the GPLv3, and I don't
agree with the anti-DRM restriction!

- Why does this matter? This doesn't stop you from (a) changing your
license to GPLv2 only or (b) continuing to distribute as v2 or later. Joe
is not creating any extra permissions, and the only extra restriction he
is creating is saying "don't use technical means to circumvent the
license". If you don't think the license is the right place to address
that, or you don't see it as a problem, you're perfectly free to continue
providing manufacturers with code they're free to slap crypto chips on.

2. Joe can take my code, modify it, release the mods only under GPLv3,
and then I can't merge his changes back!

- Joe is voting with his code!

Is there really any serious contention over this license other than that
anti-DRM clause? Because there really aren't many other feature
modifications I've heard people this upset about. If you go from saying
"I don't want to use GPLv3" to "This GPLv3 is wrong and must be stopped",
isn't that a bit of an over-reaction?

I share your concerns that we're going to suffer some pain over this
license. But I want to emphasize that it's not the GPLv3's fault that the
Busybox maintainer quit. That's about _people over-reacting_. The more
FUD that flies around about GPLv3 the more everyone's nerves are going to
get jumpy and the more pain we're all going to feel. And this is
absolutely over-reacting - the freaking license hasn't even been released
yet, and there's still another discussion draft coming! If someone forks
or quits over it now, that is totally absurd!

But you know, I wouldn't be surprised if I saw one or more code forks
over which version of the license to use. But you know what, I don't
expect to see many because the contentious anti-DRM clause really only
matters today for a certain class of software (say, an operating system
kernel or system utility set). And I think that if we could all stop
yelling at each other, or leaving stink-bombs in the press, people
wouldn't be so fanatical as to fork over something like an anti-DRM
provision. After all, most of us don't like our code to be used in this
way (Linus being a notable exception), it's just that some don't think
the license is the right place to stop it.

And if some projects fork, tough! People who fork are voting with their
code.

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 7:23 UTC (Tue) by jimi (guest, #6655) [Link]

This is exactly how I feel. If anything, the FSF is giving both the developers and the end users more choices and doing their absolute best to protect freedom - freedom for both the developers, hardware manufacturers, and users. If some copyright holder feels that the GPLv3 is wrong, then simply remove the language permitting any later version. This is not hard or even reproachable. My little GPLed project will be licensed under the new version.

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 16:02 UTC (Tue) by mingo (subscriber, #31122) [Link] (4 responses)

you need to remember that you guys aren't the only software project out there.

Oh absolutely! Two quick points:

Firstly, we "kernel guys" (which includes some exceptions, the kernel developer community is not homogenous regarding this topic - as it is rarely homogenous on any other topic to begin with ;-) are the nearest to the hardware (almost by definition), so we will be amongst the first ones who will feel the bad effects of the GPLv3 limiting hardware design. The FSF justification for the DRM language sounds nice and fine, i'd like the DVD monopoly to go away just as any other free software developer, but i also realize that:

- embedded manufacturers are /forced/ to use DRM most of the time by external factors (such as licensors of DVDs, licensors of pay-per-view content that people want, or licensors of GPS maps), so when they are faced the choice of removing DRM or removing Linux, they'll remove Linux. There's just no way we can win in this scenario, and the result is less freedom. Needless to say, i'm not happy about that angle.

- even accepting that we need to do something about DRM (and i dont think we /can/ do anything meaningful about DRM - hence we shouldnt even try, due to the clear danger of collateral damage) the FSF chose an awful solution to solve the DRM problem: they now propose to control works created independently of GPL-ed code (such as hardware), by creatively including portions of those works (certain "keys") in the definition of "Source Code", and thus forcing the release of such keys (or the ceasing of the use of such keys) when GPL-ed code is distributed together with that independent creative work (the hardware).

This sets a bad precedent because the GPLv2 never did this - the GPLv2 was very clear that our work is ours and your work is yours (as long as it's not based on our work). Trying to use distribution related legal powers to affect independent works is worthy of SCO and the MPAA, not of the free software community. It is also a material deviation from the spirit of the GPLv2. I find such a deviation from spirit and morals far more dangerous than any damage DRM could do to us.

Secondly, i believe most of the non-kernel free software projects are watching this from an armchair so to speak, without being directly involved in the issues around hardware.

While the current GPLv3 changes are mostly directed at the kernel (for example the Tivo bootloader checks the signature of the kernel it loads - not of userspace programs), but non-kernel projects could be affected by future versions of the GPL, come GPLv4 - and the precedent of compromising on the spirits of the GPLv2 and removing freedoms has already been done in the GPLv3, so it might be too late for you to object at the time of the GPLv4.

For example, would you be content with the GPLv4 requiring that only GPL-licensed code be distributed on a piece of hardware? As per the logic articulated in connection to the proposed GPLv3 changes, such extra restrictions of distribution freedoms are possible.

So if you see anyone suggest that we kernel developers are out there to compromise on freedoms it's the opposite: we are objecting against the GPLv3 restricting certain freedoms, and we are also objecting against certain measures on the grounds that the damage caused by those measures will be far larger than the supposed benefits they bring. Remember: if unfixed, the GPLv3 does not remove or impact DRM in any way, but it very much removes some of our freedoms!

Plus, i personally like some parts of the GPLv3: for example the patent language (but i also like the more robust formulation in other areas). So it's not all bad, but right now it's more bad than good in our opinion. That was expressed in the vote of the top kernel contributors too.

Please participate, for real!

Posted Oct 3, 2006 18:12 UTC (Tue) by cventers (guest, #31465) [Link] (2 responses)

Ingo,

I'm not sure I agree with you about what power we actually have over DRM.
Now would be a good time for me to point out that I sympathize with Linus
when he feels like the FSF was trying to co-opt Linux into the DRM fight.
I don't for a second believe that FSF would try and do that maliciously -
that is to say they would be happy to have Linux cooperation but I doubt
they'd try to get it with a hammer. (And indeed, Linux is GPLv2, and will
likely stay that way.)

The anti-DRM provision has really two aims. One is to keep free software
from being co-opted into devices and locked in such a way as to make it
unfree. And you're right when you say that the kernel is right up against
the metal and would feel the effects of this first. That's one of the
things I was pointing to in my last message - there's a certain class of
software that will really feel the effects of the anti-DRM provision
today.

To explain then why I think differently, I think that when Eben Moglen
says that the free software community has something the hardware
manufacturers need, he's right. Now, a big part of that 'thing' is Linux,
but as I said there is a lot more software out there. And as I said I'm
sure the FSF and perhaps some others would love to see Linus bring his
mighty muscles into the ring, but having spent a few years in LKML I dubt
Linus would :P.

Proprietary forms of production are beaten. And I know this is probably a
contentious point, and we could spend all day arguing it, but I'm really
not trying to tell you that you're wrong about GPLv3, even though I have
a different opinion. One of the things that always made the free software
revolution so special was that people could vote with their code. Merely
by doing what we love - doing what we do best - we can move solar
systems. And so for myself, and I believe many others who do support
GPLv3, it breaks down into:

1. We don't want to see our code abused and artificially locked up
2. We think we're becoming important enough that the time might be right
to flex a little muscle.

I say these things in the midst of developing a project (trying to get a
first alpha done) that is the sort of thing that might end up on an
embedded device. If no manufacturer ever embeds it, hey, that's okay - I
think its real value is mostly elsewhere anyway. If it does get embedded,
and no manufacturer tries to lock DRM on it since it runs in user-space,
great. In this case, the anti-DRM provision wasn't needed. But if it does
get embedded, and a manufacturer does lock DRM on it, clearly against my
wishes, I have legal recourse to make them stop.

And you know, I'm not even sure that manufacturers in 2006 want to lock
DRM onto projects like mine because they're not being forced to at
gunpoint. But it's about closing a loophole too. RMS has made some pretty
important predictions in the past (patents, etc) that have come true. And
so if RMS says "DRM is going to be a problem," and we look around in our
own neighborhood and see hardware manufacturers competing over who can
make the more stringent DRM, you've got to bet we're listening.

So I suspect that you disagree with me, perhaps on some factual grounds
(me saying proprietary software is dead) and perhaps on some opinionated
ones as well. When Linus said no GPLv3 for Linux some time ago, I was
disappointed. But I have nothing more than a small semantics fix patch in
mainline and a small bugfix in -ck. And I think both of those things even
came after Linus said "no GPLv3". So even if I'm disappointed, I'm not
delusional. I know that my only say would be the say of a user, which in
our community is far less important than the say of a real developer.

The reason I replied to you is over the same reason that I got pretty
frustrated with Linus recently. I know we don't agree on the GPLv3, but
that doesn't stop some of us from wanting it. And it seemed like Linus
was out in the press being dishonest about the FSF's drafting process and
intentions. Whether or not he was trying to damage the FSF or its
reputation is beside the point; it's red hot fire we don't need. We think
we have a right to have our GPLv3, and if Linus and LKML don't like it,
that's totally okay. (Let me point out that I'm not trying to paint you
with the same brush here, I'm responding to you because you seemed pretty
upset about the fact we're even moving forward with the license.)

So we're talking about GPLv3 in context of the Busybox maintainer
quitting. That's a sad event. But doesn't this just go to illustrate that
the more irrationally crazed we all get over these license debates, the
more damage we will see and the more pain we will feel?

> Please stop this licensing madness before it's not too late! We have
> already wasted too much time and effort on this, and the new license
> has not even been released. At the sight of this self-destruction of a
> once powerful community Microsoft must be laughing all the way to the
> bank.

If you don't like GPLv3, please say so. But please do so in a way that is
fair to all the participants, and in a way that doesn't cause more
trauma.

I'll say one more thing. Eben has re-invited the participation of kernel
developers in the licensing discussion. I think there's still another
discussion draft due before the final license in January. You have a real
concern about this anti-DRM provision, but right now the two communities
have just been lobbing press releases at each other. It would be very
much appreciated not only by the FSF, but by me personally and I'm sure a
lot of other people if you and some of the other developers would accept
Eben's invitation, and if you would ask your colleagues to join you. This
'licensing madness' will not stop if that's all you think of it, but if
some kernel people start to plug in to the process rather than just
yelling about it from afar (which damages your credibility in some
people's eyes, by the way) we might see some careful alterations to the
anti-DRM provision that would at least make you _less_ worried. Are you
willing to do that?

Please participate, for real!

Posted Oct 3, 2006 21:40 UTC (Tue) by sepreece (guest, #19270) [Link] (1 responses)

I completely agree that the kernel developers should post their thoughts on the comments site. However, I'm not sure I see a fundamental difference between lobbing press releases and lobbing comments. If there were a discussion in the comments process, I might feel differently, but since the most we can do is post comments that go into a back-room drafting committee, I'm not sure what the real difference is.

Please participate, for real!

Posted Oct 3, 2006 21:59 UTC (Tue) by cventers (guest, #31465) [Link]

I can't speak for Eben but it sounds to me like what the FSF was hoping
for (and what I and others hope happens too) is that concerned kernel
developers will contact them directly so as to open a line of
communication on the kernel developer's terms. The comment website is
designed to allow anyone off the street to walk up and provide useful
input; this was done to lower the barrier to entry and because it would
probably be prohibitively difficult to involve _everyone_ on a deeper
level.

Obviously, the kernel developers represent a body of very important GPL
code and so it's important that the FSF gets the chance to talk to some
of them directly.

So what do you say Ingo? Might we be able to con you and some of your
partners into opening up a chat with the dialogue directly with the FSF?

Keys and hardware

Posted Oct 3, 2006 18:39 UTC (Tue) by man_ls (guest, #15091) [Link]

Ingo, just a(nother) fine point.

[...] they now propose to control works created independently of GPL-ed code (such as hardware), by creatively including portions of those works (certain "keys") in the definition of "Source Code".

How come the cryptographic keys are now part of the hardware? Is your key part of your house? Part of your door, or even part of your lock? A crypto key is just a number; it is a necessary piece of the algorithm to install the software onto the hardware, true, but the same is true of any ./configure scripts. Are they part of the hardware too?

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 21:02 UTC (Mon) by alonso (guest, #2828) [Link] (15 responses)

Hi Ingo, I agree with you on the moral obligation of FSF. I think that in the end GPLv3 will be irrelevant, in fact it can be relevant only if linux will be licenced under it... of course in my opinion. But that said, I really don't see the reason to allow DRM infected device to use Linux. I see no difference from source+DRM from binary only. Ok you have the source you can modify it, but you never have the ability to use the modified kernel on you device. But of course THEY have it. Why are kernel developer supporting this kind of use of their work?
If in the end all device will be equipped with DRM you will have a lot of source to use like toilet paper :)

Thank you for you hard work!

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 21:26 UTC (Mon) by mingo (subscriber, #31122) [Link] (14 responses)

I'm a bit more pessimistic, but hey. My worry is that the pure "inertia of laziness" that infests all of us developers will just cause the blind copying of "GPLv3 or later" COPYING files and will gradually increase the pressure on "GPLv2 or later" projects to go "GPLv3 or later" too. And i fear we might lose many good contributors along the way, once they feel their moral trust has been abused. They'll just be disgusted by the constant flaming and bickering and will leave. Just count the number of times GPLv3 proponents called Linus' arguments "FUD" (without bothering to actually argue point by point), to get a feel of the times to come.

I see no difference from source+DRM from binary only. Ok you have the source you can modify it, but you never have the ability to use the modified kernel on your device.

Here i'm a bit more optimistic than you :-)

Just watch current market trends, where is DRM used or where will it be used? Only in limited spaces where there's content that people are crazy about and that the content owners want to protect: DVDs, HD-DVDs, Xbox, PS3. (It shows up on desktop CPUs too, but in its little isolated corner, not affecting the generic programmability of the hardware. Good enough to play HD-DVD, but not annoying enough to disable Linux.)

Note what they are not trying to do: they are not trying to do DRM-ed Linux hardware designs where people are interested in Linux content.

And the reason is simple: DRM is expensive and cumbersome, for everyone involved, hardware maker, software developer and user alike. And that wont change, no matter how much legislative power Hollywood has. Hardware makers are very much aware of this and they are resisting DRM in every place where Hollywood's content does not matter. (and they are able to do this because where Hollywood's content does not matter there Hollywood has no licensing power. Hollywood has yet to amend the Constitution.)

Furthermore, there is not much we can do, because Tivo exiting the PVR market is precisely in the line of Microsoft's and Hollywood's intent! They want small players like Tivo to exit the market, very much. So by disabling Tivo we /help/ Microsoft and Hollywood. (again, the reason of that situation is that people dont want the Linux in Tivo, but Hollywood's content)

So the solution: stop worrying about the Tivo and about the Xbox. You might see DRM in desktop hardware too, but it will be in its own corner and wont really affect Linux. Rather work on making more people want Linux. Work on replacing Hollywood's content by contributing to the Creative Commons project. And the path to the hearts of minds of people isnt via adding stupid key restrictions to the license that does nothing but annoys hardware makers who are trying to adapt Linux, but by building technology and content that people want.

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 22:41 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (13 responses)

> And the reason is simple: DRM is expensive and cumbersome, for everyone
> involved, hardware maker, software developer and user alike. And that
> wont change, no matter how much legislative power Hollywood has.

Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish. Because this will promote DRM from "cumbersone feature" the no-name chinese competitor does not bother with to "expensive feature" the customer is forced to buy.

The legislator does have the power to remove competition, and competition is the only reason companies can not thrive on ill-advised features and products. You don't hear hardware companies complaining in countries which tax DVDs or hard drives. They don't care as long as their competitors are treated the same way. Because if it's the case they can safely pass the costs on customers.

Actually Hardware/software companies would love a DRMed world - it would offer all sorts of forced obsolescence "opportunities".

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 0:03 UTC (Tue) by mingo (subscriber, #31122) [Link] (8 responses)

Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish.

So your solution: exclude all of Linux from those markets? Now how will that solve the problem??

The real solution is this: allow people to actually use DRM where mandated by either the industry, by laws or by convenience, because allowing Linux in such scenarios fights the content monopolies by giving people a bridge into free content. Also work on free content and eventually enable a new class of devices that need no DRM, because they only play free content! If we are any good, those devices will emerge, and Hollywood has yet to amend the Constitution to forbid such devices. (DMCA-alike laws only operate on hardware devices because the content industry's content is used on those devices.)

If we are not good enough to create free content, then nothing we put into the license will prevent Linux from failing in those markets. The DRM provisions will just accelerate that failure.

But if we are good at creating free content then allowing people to bridge from the closed world into the free world helps us and them. The DRM provisions of the GPLv3 will only make it harder. If we are unlucky they might even tip the balance from "slow success" into "slow failure".

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 6:42 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

Clear legal opposition to DRMs by a large GPLv3 codebase is actually a pretty good way to stop or limit the scope of DRM laws (go read the transcripts of pre DMCA/EUCD discussions they're enlightening)

Once DRM laws are enacted worldwide and win some years of legitimacy expecting to create free devices is illusory. Hollywood knows pretty well their laws will only stand if no open devices can compete with DRMed ones. They are doing all they can (and mostly succeeding BTW since people like you let them lobby alone) so DRMed is made mandatory not on hardware that manipulates their content but on hardware that *may* manipulate their content. Which happens to cover all content devices (and more), since they can always argue there is no technical difference between free content and pirated drmed content.

I don't see any manufacturer doing anything but blanket DRM once DRM is mandatory, since DRM smart enough to distinguish between closed and open content would be
1. expensive and cumbersome
2. legally dangerous
3. economically useless in the abscence of a large pool of open content (which in turns requires a large pool of open devices to develop)

You can make great code by pooling the free time efforts of many individuals worldwide, you can not make great hardware without someone owning an expensive factory somewhere.

Expensive factories are a lawsuit target.

GPLv2 or, at your option, any later version

Posted Oct 9, 2006 14:48 UTC (Mon) by malor (guest, #2973) [Link] (6 responses)

If they don't use Linux, so what? Does Tivo give you anything?

Some customers are bad. Some market share is share you don't want. What benefit is there for you in having DRM-locked Linux kernels on the market? From this perspective, it looks like they just stole your code and locked everyone out of their device. They're bad customers, market share that costs more than it's worth. For a few more share points, you trade away your freedom to fully use any device that uses your code.

The GPL code base gets bigger every year, and harder to compete with. Success is absolutely inevitable, if you are willing to be patient enough. At some point, the base of GPL code will be so enormous and so *good* that it will be economic suicide to try to compete with it. That may take another generation, maybe two. But eventually, there will simply not be room for closed licenses on mainstream products anymore.

The problem is that you're not thinking big enough. If you think in a multigenerational timeframe, the Linux kernel is not *that* critical. Code can be replaced, but lost freedoms are damnably hard to get back. Changing the GPL to suit any one project, even one as large and important in the present day as Linux, will have unpleasant ripple effects for decades.

It appears that you want the project you've put your whole life into to be wildly successful. And maybe you were never one who particularly cared about this particular issue... maybe it's okay, from your perspective, for someone to sell you a device running your own code that you're not allowed to change. Or maybe you're willing to overlook that if it means your project becomes dominant in the marketplace.

But for the FSF, whose goal is software freedom, not the success of any particular project, it would be very foolish to do what what you want. Their goal is freedom for generations; yours appears to be success over the next few years.

I wish you both well, but IMO, the FSF's goal is important to the entire world, where yours is important primarily only to Linux kernel devs.

GPLv2 or, at your option, any later version

Posted Oct 12, 2006 3:26 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

tivo gave us their code (it turns out that not much of it is wanted, but that's not a requirement)

as a result tivo boxes are extremely hackable, once you jump through the initial hoops to defeat the encryption

GPLv2 or, at your option, any later version

Posted Oct 12, 2006 8:04 UTC (Thu) by malor (guest, #2973) [Link] (4 responses)

Right, but with Trusted Computing, you will not be able to do that anymore. If the kernel isn't signed with Tivo's private key, it won't run on that hardware, period.

Is it okay if they put chains on stuff if you know how to break them? What happens when you don't know how to break them anymore? You can go from A to B almost overnight, and if you don't have any legal protections in place, don't you think they've stolen your code?

It strikes me that just the ATTEMPT to steal your code, even though they may not succeed, is highly noxious, and something to be prevented.

Think of the DRM provisions in GPL3 as a life preserver. The real things are a little awkward to wear on a boat, and make your day a little less fun. But if you need one, you REALLY need one, and you'd better have put it on ahead of time.

GPLv2 or, at your option, any later version

Posted Oct 13, 2006 2:13 UTC (Fri) by sepreece (guest, #19270) [Link] (3 responses)

You describe it as "stealing" when a manufacturer uses your code in a device, but doesn't give you the right to modify it in the device. How is that any more "stealing" than, for instance, using it inside a company, embedding it in a device you can't afford or just don't want, or putting it in a device in ROM so that it can't be modified?

If you choose to consider it unfair, that's a choice that I think you should be free to make, but it's no more "stealing" than unauthorized copying of content is "stealing" or "piracy".

GPLv2 or, at your option, any later version

Posted Oct 13, 2006 19:21 UTC (Fri) by malor (guest, #2973) [Link] (2 responses)

Of course I describe it as stealing. The whole point of copyleft/GPLv2 is that the original author of the code maintains full rights, but gives up some of those rights voluntarily. In exchange, all other users of the code cannot reserve more rights for themselves than people they give it to.

That's really it. That's the contract. If you write Neato Program A, and kindly give it away under the GPL, I can build on that and make it into Neato Program B. But I can't distribute it in such a way that my downstream users can't add on to make it Neato Program C. And none of us can distribute it in such a way that YOU can't take our changes, incorporate all of them into Super Neato Program D, and then freely distribute that as well.

If I, as a device manufacturer, want to make a non-modifiable device that I can't change, I can use GPL code to do that. But I can't reserve rights for myself that my end-users don't have. If I can modify the device, they must be able to also.

Tivo, in other words, is stealing code. They are taking the kernel code and releasing a locked device with it; they are using GPLed code with a hardware addition to reserve rights for themselves that their end users don't have. If they want to release a locked device, that's fine, but then they can't piggyback on the work of thousands of volunteers. They have to create the device themselves, with their own code, or buy it from someone that has the right to release it under a non-GPL license.

If you argue to the contrary, you're in favor of giving hardware manufacturers special powers to enslave those who write software. You're relegating the software guys to second-class citizenship.

GPLv2 or, at your option, any later version

Posted Oct 14, 2006 20:22 UTC (Sat) by sepreece (guest, #19270) [Link] (1 responses)

As you must know, if you've been paying any attention to this issue, many key kernel developers, among others, disagree with you that this is even unfair, let alone illegal. Note also that the manufacturers, in your example, are NOT witholding the code, only the right to modify the device by installing new software. Note also that they generally do NOT retain the right to modify the software in the device, since they generally no longer have access to the device. The only way they can install modified software is if you let them, either by asking them to ("run iPod updater") or by subscribing to a service that may load new firmware (like Tivo service). Since they are then acting as the owner's agent, I'm not sure there's really an issue here at all...

Referring to it as "stealing", in any case, is just wrong. Copyright infringement is not theft, regardless of what the RIAA and MPAA would have you believe.

GPLv2 or, at your option, any later version

Posted Oct 14, 2006 22:51 UTC (Sat) by malor (guest, #2973) [Link]

Yes, I realize that key kernel developers don't like this. However, in watching their verbal gyrations on the issue, I have come to the belief that this is not because of any particular ideal of free software. Rather, it appears to be because the GPLv3 will slow the adoption of their pet project and, thus, the spreading of their fame and future employability.

The whole point of the GPL is that I can't use your code, distribute it to others, and keep rights to myself that I don't give to my end users. If I load it onto a device, but retain the right to modify software in the device, they must also have that right. And your assertion that I can only install modified software with their permission is incorrect. The fact that most manufacturers have been polite and done so, does not mean that they are required to. If I'm the manufacturer of a Tivo-esque device, I do not have to ask for any permission from anyone to update 'my' device.

And no, calling it stealing isn't wrong. Copyright infringement is not theft, because the producer of music/movies/whatever isn't deprived of anything, except possibly a potential sale. But in the case of software, part of the original agreement is to allow end users (including the original author of the code) full rights to any distribution of that code.

Distributing it in a locked hardware device does indeed deprive the original developer of something, the ability to use the device in the way he or she wants. 'Stealing' is perfectly appropriate; they have taken something from you and not fulfilled their primary responsiblity, which is to give end users the exact rights that they have. You have a clear and demonstrable loss.

If the FSF bends to the pressure of the loud kernel devs, they are trading away the future of their entire movement for a little near-term success for one project. They permanently relegate software developers to second-class citizenship behind hardware manufacturers.

I think they know that, and I hope they will refuse to bend on this issue.

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 6:46 UTC (Tue) by JoeF (guest, #4486) [Link] (3 responses)

Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish.

And the result will be that the manufacturers will use Windows or other non-free software. The FSF will have reached their goal, no GPL software on such devices. Unfortunately, it will be a hollow "victory", as there will be no free software on these devices.
Operation succeeded, patient dead...

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 7:07 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (2 responses)

And there will be a clear victim of DRM laws which will cause legislators to think, instead of GPL software being progressively and quietly killed on those devices, because no one but the manufacturers can deploy code on them and no third parties are interested by GPL code if there's no harware to run it on.

And you can go complain at the legislator then, you won't have any bargaining power left.

HDCP cards are making their way on computers. So we're losing displays. If you believe the open computer will resist long if no one opposes Hollywood you are a fool. GPLv2+DRM happens to enable corporations to do the BSD on GPL code they wanted all along

GPLv2 or, at your option, any later version

Posted Oct 5, 2006 20:24 UTC (Thu) by AJWM (guest, #15888) [Link] (1 responses)

> which will cause legislators to think,

What planet are you on? Sounds nice, legislators that might actually think, even if it does take some force.

If (hypothetically) Tivo were to die because a GPLv3 Linux was no longer allowed on it, that would NOT be seen as "a clear victim of DRM laws", but as "a victim of the capriciousness of those leftist hippies in the free software community", and held up as a cautionary tale against using GPL'd software.

GPLv2 or, at your option, any later version

Posted Oct 6, 2006 7:32 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

> > which will cause legislators to think,

> What planet are you on?

A planet were I do actually read reports of the parliament debates on subjects I'm interested in.

The GPLv3 may seems strange and surprising to some. For people who followed the DADVSI/EUCD debate in France (of which the FSF was one actor BTW) it's a very logical development.

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 21:21 UTC (Mon) by man_ls (guest, #15091) [Link] (3 responses)

Or do you agree with me that the president of the FSF is in a unique legal position (and has the unprecedented legal power) to change the license affecting the contribution dynamics of 350 million lines of code instantly?

Agreed, but I would say that the process instituted to update the GPL is also unprecedented. In 1991 Stallman sat down and wrote the GPLv2 on his own. 15 years later he is runnning an unprecedented consultation process: constant legal counselling by Moglen, FSF support, world-wide consultations, 4 conferences, industry-wide committees, and even a web-wide legal hunt for side effects. Even the opposition (as in Linus Torvalds) has admired how it was set up.

Do you agree with me that such huge power brings with itself a minimal moral obligation to at least /understand/ and adopt to the position of the community that created that codebase, instead of trying to advance his own moral position?

I would say Stallman has understood you quite well, and then consciously rejected your position. It is evident in the "most people don't appreciate freedom" quote that you dislike so much; or in his endless rants about "free software vs open source". If Stallman placed convenience or development process over freedom, then we (as in those who like GPLv3) would be disappointed.

GPLv2 or, at your option, any later version

Posted Oct 2, 2006 23:46 UTC (Mon) by mingo (subscriber, #31122) [Link] (2 responses)

I would say Stallman has understood you quite well, and then consciously rejected your position.

And you think that's fair and morally justified?

Do you now see why such an arbitrary "rejection of a position" combined with "unparalleled legal power" scares most of the kernel developers?

If Linus did that, and if it mattered to enough people, they'd walk away and start another kernel tree.

But there is no real remedy for RMS's behavior, and he acts accordingly.

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 6:43 UTC (Tue) by gmaxwell (guest, #30048) [Link]

If he accepted your position he would reject mine. Is that morally justified?

Inaction has no special virtue... a failure to act can be just as unethical as an action.

Reasonable people can believe an argument that the FSF is not even acting in this case... but rather clarifying an intended part of the licenses which was always there.

Or, to put a systems analogy on it: You've used a module as a black box without reading the comments and documentation, and now you are aggregated because the new version of the module has had code changes so that it continues provide the intended behavior (as documented) in an environment which has changed.

GPLv2 or, at your option, any later version

Posted Oct 3, 2006 8:34 UTC (Tue) by man_ls (guest, #15091) [Link]

Do you now see why such an arbitrary "rejection of a position" combined with "unparalleled legal power" scares most of the kernel developers?

I would not say the rejection was arbitrary. It has been justified repeatedly and since a long time ago by Stallman.

You said above you did not agree with the GNU manifesto but found GPLv2 reasonable; that anti-DRM clauses were out of scope. I think that is just because you have seen one in action (GPLv2) but not the other (GPLv3). Your distrust is justified but, as gmaxwell said above, inaction against a visible threat would not be welcome by most people. Leaving these issues to "markets" would be like trusting Microsoft to open up their protocols.

If Linus did that, and if it mattered to enough people, they'd walk away and start another kernel tree.

I gather from LWN (not an expert by any means) that many people keep parallel trees; e.g. micro-kernel advocates, alternate security framework proponents, and lately yourself. Has it changed Linus' attitude towards these issues?

On the other hand, many people have proposed alternative licenses, even copyleft licenses. You are free to relicense all of your extant code if you want; not in the kernel, but the kernel is not an option for GPLv3 either.

Linux follows an open decision process, and you can fork it if you dont like it

Posted Oct 2, 2006 14:54 UTC (Mon) by sepreece (guest, #19270) [Link] (1 responses)

Actually, you're not allowed to modify the text of the GPL. You would have to write your own similar license. Though the FSF has said they would not pursue copyright infringement against alternative licenses that copied text from the GPL, so long as they did not represent themselves as the GPL, they hold the copyright on the license text and have not formally granted a license to modify it, so you would need to start from scratch if you wanted to be legally clear.

Yes, you can modify the GPL terms

Posted Oct 2, 2006 16:54 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

While you can't modify the GPL text itself, you can still use the GPL as a basis to form a license with slightly different terms. The only restriction is that you have to do it in two parts.

Include the GPL test in your distribution.
State terms such as "This progrem is licensed under GPL version n, with the following exceptions:
Then state whatever you wish to change (example: you could add language permitting DRM usage to GPL v3).

There's nothing new about this: there's already a lot of "GPL with exception" code out there, sometimes done to permit linkage with code that has a GPL-incompatible license.

Forks are not part of the decision process.

Posted Oct 2, 2006 12:29 UTC (Mon) by man_ls (guest, #15091) [Link] (6 responses)

It's called the /bin/cp command and it's very easy to do.

Do not confuse "forking" with "deciding". The decision process of Linux is closed and ruled by the benevolent dictator Linus Torvalds; you may like him, his decisions or his kernel a lot, and I will agree with you; but that doesn't make the process any more open. Forking is not part of the decision process.

Of course you can fork the code, find a new name (Linux is a trademark you know), a domain and start hacking. We are not discussing that: this is a consequence of Linux being free software, which nobody discusses here. The result of a fork would not be Linux anymore.

He is now using the "or later version" and "similar in spirit" legal wildcards (that RMS has put there himself and which clauses contributors left in the COPYING file due to trust or due to laziness)

There is a reason this clause is there: the option of using GPLv2 or GPLv3 is not made by the original developers, but by the recipients of the code. If you want the received code to stay GPLv2, it stays v2. If you prefer to switch it to v3, you can do so.

Of course there are practical problems in maintaining either version of the license, but projects can choose or just let the decision to their users.

Without any competitive pressure whatsoever.

Since the option of choosing either v2 or v3 (or eventually v4) is left to you, the recipient of the code, I'd say there is a lot of competitive pressure. Not to speak about the tens of equivalent licenses that have sprouted all around; for the vast majority of projects, which have a few contributors, relicensing is just a few clicks away.

Forks /are/ part of the decision process.

Posted Oct 2, 2006 12:58 UTC (Mon) by mingo (subscriber, #31122) [Link] (5 responses)

The decision process of Linux is closed and ruled by the benevolent dictator Linus Torvalds

Wrong, as explained in my detailed reply further above. So per your logic the 2.6.18 kernel would not have something like priority inheritance today? (and if you reply then please reply to my post above, which gives the full context. Thanks.)

Forks /are/ part of the decision process.

Posted Oct 2, 2006 13:13 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] (2 responses)

>Linus has no monopoly on Linux. You are free to fork Linux anytime.
But he does hold a copyright to the symbol "Linux", so you can't fork and call your shiny new kernel Linux.
He also is the sole, final committer to his/The Mainline Tree.
It's a "de facto monopoly", for all he manages it admirably.

Forks /are/ part of the decision process.

Posted Oct 2, 2006 13:26 UTC (Mon) by mingo (subscriber, #31122) [Link] (1 responses)

Linus has no monopoly on Linux. You are free to fork Linux anytime.

But he does hold a copyright to the symbol "Linux"

Wrong. Symbols like "Linux" cannot be copyrighted.

And as i said, i am maintaining my own fork of the Linux kernel.

(The word "Linux" can be trademarked and is trademarked in some countries, and Linus so far has never used any trademark power against a fork of the kernel. But it's not even an issue, you can run a simple script over the whole codebase and replace every occurance of "Linux" with "Lanux" or whatever. In fact the Hurd project uses quite a bit of Linux kernel code and so does Xen. It's perfectly legitimate.)

But you cannot do the same with the GPL, and you cannot fork the license together with the codebase attached to it. Only RMS has the huge, unprecedented legal power to do that. (as explained in detail in the posts above.)

Forks /are/ part of the decision process.

Posted Oct 2, 2006 15:20 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

Yes, I meant trademark, sorry.

Forks /are/ part of the decision process.

Posted Oct 2, 2006 18:24 UTC (Mon) by Ross (guest, #4065) [Link] (1 responses)

You are talking about convincing Linus to add a feature. The equivalent would be convincing the FSF to change the terms in v3. They do have a process for that, but there is no guarantee you will change their mind. I don't see the distinction at all.

Forks /are/ part of the decision process.

Posted Oct 2, 2006 18:55 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

>change the terms in v3. They do have a process for that

One of the contentions is that the process is superficial.
Possibly the FSF could show the first circulated drafts, and diffs against it, to show prove that there substantial community input has affected the draft. This might dampen the squaks in the peanut gallery.

Again, forking is not deciding

Posted Oct 2, 2006 13:19 UTC (Mon) by man_ls (guest, #15091) [Link] (7 responses)

Ok, I will reply here then. So you think the decision process is open because fear of forking keeps Torvalds honest. Or even because people can keep separate branches; somehow separate branches (or even forks) make the decision process open. Even though only Linus Torvalds gets to decide what goes into the official kernel.

To me that is like saying that "this basketball game is open because I get to decide who plays here; and if you don't like it there are plenty of basketball courts. It is open because if you didn't like my decisions, you might go and play somewhere else."

I disagree. Keeping Torvalds honest and sharp is a consequence of Linux being free software; you made an accurate description not of an open decision process, but of an open development process. One person gets to make the decisions nevertheless, like it or not. Might be a fine point, but it is the one discussed here.

forking code /is/ deciding - except for the GPL itself

Posted Oct 2, 2006 13:44 UTC (Mon) by mingo (subscriber, #31122) [Link] (6 responses)

Ok, I will reply here then.

thanks!

So you think the decision process is open because fear of forking keeps Torvalds honest. Or even because people can keep separate branches; somehow separate branches (or even forks) make the decision process open. Even though only Linus Torvalds gets to decide what goes into the official kernel.

Actually, Linus delegates much of that "decision power" to others. Why does he do it? Because he has no real decision power! He is only the maintainer of Linux because his decisions make sense. Linus has no legal power to keep Linux from forking - and he knows it and acts according to that fact!

As a result a large number of Linux kernel forks emerged (and eclipsed) over the years, and the only reason why a fork did not take over his maintainership was that Linus was able to renew and he was able to stay ahead of the pack. Will that continue to be the case in the future? Certainly not, Linus will eventually get old and senile, like most of us. Or if he messes up earlier then he could be succeeded by whoever does it better: be that Alan Cox or Andrew Morton or someone else who is still in primary school today. And that's perfectly fine and well understood by everyone involved.

(Also, you did not reply to my fundamental question: you claimed that it would be just as easy to fork the GPL as it would be to fork the Linux kernel. I pointed out the it's just not true and that RMS has unprecedented legal power that Linus does not have - but you left those points unreplied. Should i take them as conceded?)

I disagree. Keeping Torvalds honest and sharp is a consequence of Linux being free software; you made an accurate description not of an open decision process, but of an open development process. One person gets to make the decisions nevertheless, like it or not. Might be a fine point, but it is the one discussed here.

No, what keeps Linus sharp and honest is the fact that he has no legal power to keep forks from happening. The GPLv2 license itself is an expression of that fact. The president of the FSF on the other hand has no such "danger of competition" hanging over his head. He can put into the GPL what he thinks is right and release it, and it instantly and retroactively affects the contribution dynamics of 350+ million lines of code. No other person on this planet has this power. On the other hand anyone can fork Linux (and many try and do) and continue from that base and leave Linus behind. Linus has no legal power to keep that from happening, and that is very much by design.

Let's all develop just by forking

Posted Oct 2, 2006 17:09 UTC (Mon) by man_ls (guest, #15091) [Link] (5 responses)

thanks!

You are welcome :D

Also, you did not reply to my fundamental question: you claimed that it would be just as easy to fork the GPL as it would be to fork the Linux kernel. I pointed out the it's just not true and that RMS has unprecedented legal power that Linus does not have - but you left those points unreplied. Should i take them as conceded?

I did not claim that you could fork the GPL, it was somebody else. In fact I don't think that the GPL can be forked at all; the FSF keeps copyright on it, so you cannot change it. You can create a similar license with equivalent terms.

As to the unprecedented legal power: that power is voided if nobody will ever take advantage of the "at your option" clause and choose the GPLv3. In fact, almost every recipient of v2 code will have that option. Linux kernel developers and users will not.

Now, as it happens the Linux kernel developers (who are not affected by it) are the ones most vocally arguing against the GPLv3. Odd.

No, what keeps Linus sharp and honest is the fact that he has no legal power to keep forks from happening.

Whatever. No way to verify that statement to good effect.

The president of the FSF on the other hand has no such "danger of competition" hanging over his head. He can put into the GPL what he thinks is right and release it, and it instantly and retroactively affects the contribution dynamics of 350+ million lines of code.

That is his prerrogative. After you create a license which is used by hundreds of thousands of developers, you have to concede that many of them trust the man to create a good successor to v2. Those who don't trust him should remove the "at your option" clause anyway. Those in between should confort in the fact that they can stick to v2 and remove the clause, if they don't like v3.

Let's all develop just by forking

Posted Oct 2, 2006 20:45 UTC (Mon) by mingo (subscriber, #31122) [Link] (4 responses)

As to the unprecedented legal power: that power is voided if nobody will ever take advantage of the "at your option" clause and choose the GPLv3.

It is not voided because once it has been used, and if the resulting GPLv3 license is backwards-incompatible with the GPLv2, any GPLv3 project can take any GPLv2-or-later code and incorporate it - but changes might not be backmergable into the original GPLv2 codebase!

Please think about it. It is a huge factor. It changes the whole ballgame.

It is also very unfair to those who created the "GPLv2 or later" code to begin with, and who wanted the basic Quid Pro Quo (which is also one of the 4 freedoms): I give you my source, you give back yours. Now the GPLv3 might change that to: "I take your source code, but you can only take it back if you change your project to GPLv3."

Is it your position that it's "that developer's fault, for having released it under 'GPLv2 or a later version' license"? Is it your position that because RMS has the legal power to create such a situation, that it is automatically fine, no matter what RMS's decision ends up to be?

That is why i call it unprecedented legal power, and only a single person on this planet has this legal power: Richard Stallman. There is no equivalent power Linus has in the Linux kernel space. He does not even come close. All the "power" he has is his technical experience and maintainance skills.

So your previous points of trying to claim that Linus has a similar legal position in the Linux kernel space as RMS has in the GPL license space is materially false. (Which i kind of see conceded by you implicitly, because you did not advance that point any further.)

Let's all develop just by forking

Posted Oct 2, 2006 21:30 UTC (Mon) by man_ls (guest, #15091) [Link] (2 responses)

Is it your position that because RMS has the legal power to create such a situation, that it is automatically fine, no matter what RMS's decision ends up to be?

No, of course not. If the license was unfair or inconsistent I would complain loudly. I just don't see how banning DRM (which is a bad thing, as I tried to explain on other pages) can be that bad -- especially for a group of people which aren't threatened by the GPLv3 update.

So your previous points of trying to claim that Linus has a similar legal position in the Linux kernel space as RMS has in the GPL license space is materially false.

I assure you I'm not trying to win my arguments blindly. The previous point was that GPLv3 drafting was as closed a process as Linux development. Linus has the same "benevolent dictator" status for Linux as Stallman for GPL. Their legal positions are as you say very different, since one is developing software and the other one updating a license.

Let's all develop just by forking

Posted Oct 2, 2006 21:56 UTC (Mon) by mingo (subscriber, #31122) [Link] (1 responses)

I tried to answer this before, but lets try another approach to get my point across:

Linux decision process: anyone can replace Linus, Linus has no legal power to decide what goes into Linux. Hence he has no choice but to be open about every decision. He delegates "merging decisions" to subsystem maintainers and generally keeps an open mind about stuff. (i have proven this with an actual incident of Linus strongly opposing something and then merging it anyway. I could show many other similar incidents too.) If the Linux decision process were dictatorial then you'd sure be able to cite me at least one example of Linus arbitrarily rejecting a change?

GPL decision process: no-one can replace RMS, and RMS has the sole legal power to unilaterally decide what goes into the GPL. There's little outside pressure on RMS to change or adapt.

How you can claim that the Linux decision process is "closed as the FSF decision process" and in fact how you can claim that the two decision processes are similar in any way, is beyond my cognitive capabilities :-)

Control over the kernel

Posted Oct 3, 2006 9:33 UTC (Tue) by man_ls (guest, #15091) [Link]

Linus has no legal power to decide what goes into Linux.

In fact he does: below this same page you can read:

Linux is a registered trademark of Linus Torvalds

It is not a fine legal point; he may not use that power, but that is his prerrogative. He has de iure control on Linux. Besides he publishes the kernel.org main kernels, so he also has de facto control.

He delegates "merging decisions" to subsystem maintainers and generally keeps an open mind about stuff.

He chooses to do so, sometimes. There are counter-examples like micro-kernel design and alternative security frameworks, as I gather from LWN.

If the Linux decision process were dictatorial then you'd sure be able to cite me at least one example of Linus arbitrarily rejecting a change?

Those mentioned above, or his unillateral decision of using a proprietary tool (BitKeeper) despite lots of people advising against it (including many kernel submaintainers like Morton). People proposed free alternatives or even developing a new one but they were all rejected. Remember that the arguments in favour of BitKeeper were that it enabled Linus' workflow, there were no free alternatives and developing one would take years. After withdrawal of the free client, in 15 days Linus had a working replacement. Allowing binary modules is another area where Linus' opinion is final.

Discussing these issues with a kernel developer is funny. I'm sure domain experts can suggest many more dictatorial changes in areas where there is no consensus.

GPL decision process: no-one can replace RMS, and RMS has the sole legal power to unilaterally decide what goes into the GPL. There's little outside pressure on RMS to change or adapt.

Little pressure? I don't think so. 22 years ago he had the whole industry against him; 8 years ago he confronted a pro-industry lobby (OSI) on his own. Free software (and "open source") licenses sprout every month. And still the GPL is used in 85% of free software projects. I would say that is enough pressure.

RMS plus Moglen plus the FSF decide what goes into the GPL, just as Linus decides what goes into Linux. If you don't like it you can discuss it on the GPLv3 page (or on lkml), otherwise just choose another license (or another kernel). You can fork the kernel, and you can impose additional restrictions or permissions on top of the GPL (or rewrite it and change some aspects).

Both are top-down processes; the fact that the dictators disagree on certain respects and you are friends with one of them does not change anything, Ingo. Linus listens to you, but that is because you think like he does; if you proposed a change to a micro-kernel architecture would he listen to you? If suddenly most kernel submaintainers proposed it? Would they be submaintainers for long?

Let's all develop just by forking

Posted Oct 3, 2006 15:01 UTC (Tue) by southey (guest, #9466) [Link]

It is a given that GPLv3 will be backwards-incompatible as the DRM story shows. But also there will be GPLv2-or-later code that will be incompatible with GPLv3. This is simple logic as the GPLv3 has more restrictions than the GPLv2 like potentially requiring all code free or not (especially code linking to less-free or closed libraries) and items covered by a patent (does not have to be software patents).

In part, I think the aspect of spirit is part of your core argument in this whole discussion. It is very clear to me that the written spirit of the GPL license has changed from GPLv2 to the draft of GPLv3. Just because Richard Stallman has decided that GPLv2 does not reflect his view of code 'freedom', it does not permit the him to change the written spirit of GPLv2 and force everyone with GPLv1 or GPLv2 licensed code to support his new revised view. (Yes, it is new and revised if for no other reason than changes in technology.) So, if the code owner considers that the spirit has changed, is the or a later version aspect still binding (if it was in the first place)?

Normative reference for 350+ MLOCS?

Posted Oct 2, 2006 18:34 UTC (Mon) by piggy (guest, #18693) [Link] (4 responses)

... 350+ million lines of code ...

Does anyone have a normative reference for this 350+ million LOC available under the GPL? Translating that to total developers over 15 years gives me something between 2000 and 10,000 developers working on GPL'd code. That is about the range I estimate for developers CURRENTLY working on the Linux kernel alone.

Normative reference for 350+ MLOCS?

Posted Oct 2, 2006 19:41 UTC (Mon) by mingo (subscriber, #31122) [Link] (3 responses)

I did some pretty precise measurements ~2 years ago on the total sourcecode of FC3, and i extrapolated from that to FC6 and got 370 million lines of code. (and that takes code duplication into account already)

Note that FC6 has ~2200 packages right now, while Debian has well over 15000. The gzip compressed source code size of FC6 is 2.6 GB, the compressed source code size of Debian is 8.8 GB. So Debian's size is somewhere around 1.2 billion lines of free code.

So i think it's probably fair to say that free software has recently hit (or will soon hit) the 1 billion lines of code landmark. I said the 350+ mloc metric in the discussion because i'm reasonably certain about that metric. (i did it myself)

The kernel, when it was 4.2 million lines of code, was estimated to be equivalent to the value of commercial code developed from scratch for 175 million US dollars, under a hand-tuned COCOMO model with a multiplicator of 2.40.

370 million lines of code, even assuming a default 1.0 COCOMO complexity multiplicator and developed from scratch, is worth 6.2 billion US dollars. Under the same metric, Debian's 1.2 billion lines of code is worth 21.2 billion US dollars.

Of course the freedom offered by free software cannot be measured in US dollars, but still it's good to know the rough value of the economic foundation this community has built for itself.

Normative reference for 350+ MLOCS?

Posted Oct 2, 2006 22:15 UTC (Mon) by cventers (guest, #31465) [Link] (2 responses)

> Of course the freedom offered by free software cannot be measured in US
> dollars, but still it's good to know the rough value of the economic
> foundation this community has built for itself.

This is why I think it is very important that the FSF has been doing the
GPLv3 drafting as they have, by involving people from around the world in
the review and commentary over 3 discussion drafts over a one year
period. They know that they are doing important work on everyone's
behalf, and not everyone wants the same thing out of this work, so
they've been trying to bring people together.

I don't think Linus's implication that the FSF didn't care what he
thought is fair. Thats why I attempt to remind of the difference between
listening to someone and unilaterally doing what they say. But the
feedback of Linus, you, and the other developers is still important. If
you are at all concerned about the license, please don't sit out from the
discussion. You don't have to answer to anybody - you can walk right into
the discussion process as Ingo Molnar with whatever opinions and concerns
you have. You might not alter the course of the license, but is it more
important for LWN readers to hear you, or the people doing that which
concerns you?

Normative reference for 350+ MLOCS?

Posted Oct 3, 2006 0:06 UTC (Tue) by mingo (subscriber, #31122) [Link] (1 responses)

You don't have to answer to anybody - you can walk right into the discussion process as Ingo Molnar with whatever opinions and concerns you have.

What makes you assume that i have not done so already?

Normative reference for 350+ MLOCS?

Posted Oct 3, 2006 2:27 UTC (Tue) by cventers (guest, #31465) [Link]

Well, when I refer to the discussion process in this way, I'm refering to
formal participation. And laf0rge posted elsewhere in this commentary on
LWN that he was the only kernel developer he saw at 3 conferences. And it
seems like from some of the statements of the other developers that no one
really got directly involved for various reasons.

But you are right. I made an assumption, and for that I must apologize.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 12:03 UTC (Mon) by laf0rge (subscriber, #6469) [Link] (17 responses)

Ingo, I don't really understand your hatred against the GPLv3 and the process. I've personally witnessed (and contributed some minor issues to) the GPLv3 process, and I can absolutely not support the statement of it not being open.

In fact, very early on, I feared that the process wouldn't be open. But especially looking at the changes between the first and second draft, you can't really claim that the feedback from the community has no influence on the license drafts, can you?

Isn't it just that you happened not to care about the GPLv3 process until it was already going on for more than six months? Why was I the only kernel developer present at those three GPLv3 conferences that I've been to?

If you feel like basing your criticism on a solid basis, I suggest you outline which comments you made at which state of the process, how those comments were submitted to the FSF, and which response you got or didn't get.

btw: Almost all my old code is GPLv2 only. Because I never know in advance how any later version might look like. Now that v3 starts to materialize, I'm sure I'll switch to "v2 or v3" wording. The openness of the FSF license drafting process might even make me dare to use "or any later version" in new code that I write from now on.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 15:00 UTC (Mon) by sepreece (guest, #19270) [Link] (1 responses)

In practical terms the GPLv3 process has been very open to input, but there is no evidence that it is open to change of substance. Since the actual decision process is out-of-sight, and since RMS gets the final say, it's hard to describe this as a fully open process.

Note, however, that I have no reason to believe that the issues of substance (like anti-DRM) are things on which a more open decision process would make any changes. I'm prepared to believe that the FSF core membership shares RMS's position on the necessity of those changes.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 18:05 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

There is one ample difference between the GPLv3 process and free software development:

If Linus gets a major thing wrong, he puts on his brown paper bag, fixes the problem, and releases a new version. If a tiny-little bug was found, it would probably wait for the next release.

In this case there is no "next release". All bugs need to be found in the current release (GPLv3). Or they'll remain for practically forever.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 15:23 UTC (Mon) by mingo (subscriber, #31122) [Link] (14 responses)

Ingo, I don't really understand your hatred against the GPLv3 and the process.

If you read my replies, they outline all the worries that i have. There is no "hatred" (for every issue i raised i have written down the basis of that worry - which i believe is not irrational), just a deep disapproval/frustration of monopolistic/dictatorial practices, and a worry that a previously unified community would be split by using legal powers - a disapproval shared by many others on this and on other forums. While i can see little in the GPLv3 that will solve practical license related problems we have in free software today (i see a few things that could solve future problems), i already see real collateral damage caused by it: we wasted way too much time on this unsolvable problem already, we just lost the busybox maintainer, and i'm afraid more pain is to follow.

I'm also worried that RMS justifies the closed decision-making process of the GPLv3 because: "Most of our community does not appreciate freedom" .

To answer your points, the fact that /you/ like the end result might have something to do with the fact that you are content with the process, dont you think?

Do you agree with me in theory that if i dont like the end result (so far), and i see that it is in large part due to the fact that RMS keeps full legal control over the next version of the GPL (which only he can do - no other person on the planet), that i have the right to at least be worried about the concentration of so much power in a single hand? Or should i queue up with you just because you like the end-result?

Even if i were happy with the GPLv3 i'd still accept the right of others to be upset about it, if they are ready to articulate their points.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 18:22 UTC (Mon) by man_ls (guest, #15091) [Link] (6 responses)

I'm also worried that RMS justifies the closed decision-making process of the GPLv3 because: "Most of our community does not appreciate freedom".

To put it in context, Stallman says just above that:

These are the kind of people that assume that you should choose between Free Software and proprietary software based on practical convenience, which is another way of saying that they value freedom at zero.

Why is that worrying? I thought most kernel developers were all for practical convenience, and freedom was just a secondary concern. (Maybe not valued at zero, but very little.) Linus Torvalds himself chose to use a proprietary program for source code management because it was more convenient than the competition in the free software camp. If you appreciate convenience features more than your freedom, then you will agree that you don't appreciate freedom too much. Most people are like that. That is not bad, just a fact of life.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 18:58 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

>>These are the kind of people that assume that you should choose between Free Software and proprietary software based on practical convenience, which is another way of saying that they value freedom at zero.
>Why is that worrying?

It is a sad day when one voice levels the accusation "unethical" at someone else's behavior, while falling short of defining what "ethics" is.
Recent history shows that intolerance must be viewed with suspicion.

FSF is creating a problem that never existed!

Posted Oct 3, 2006 9:40 UTC (Tue) by cate (subscriber, #1359) [Link] (4 responses)

Freedom is very subjective. Anarchy is the most individual freedom, but do this means that you have more freedom possible? If we don't want anarchy, it means that we don't consider freedom, right?
Your (and RMS) arguments are far to extreme.

Anyway, are you saying? The GPLv2 was not about freedom and only the GPLv3 give us freedoms?

Freedom over convenience

Posted Oct 3, 2006 9:55 UTC (Tue) by man_ls (guest, #15091) [Link] (3 responses)

You don't have to interpret Stallman's sayings; you have a lot of his own exegesis online. He just asks you to value convenience over freedom, and freedom is a well defined set of conditions. The guy is not asking you to give your life for the revolution, just to give up OpenGL with certain cards, or wait a little. I don't think those conditions are too extreme. I live according to his precepts and have been happy ever after! (Just joking :)

Both GPLv2 and v3 are about freedom; times change and licenses must be updated to reflect the new conditions and close any loopholes.

Freedom over convenience

Posted Oct 3, 2006 21:58 UTC (Tue) by sepreece (guest, #19270) [Link] (2 responses)

I suspect that was supposed to be "to not value convenience over freedom".

I would note, though, that "content vs freedom" is a different equation than "convenience vs freedom". A lot of content is simply not available (legally) without DRM. And that's because the content owners are exercising their right to control the circumstances under which they release their content, just as GPL authors control the circumstance under which they release theirs.

Stallman, of course, says "movies are generally no good - you're better off without them" and "if you really want movies, go find copies that people are sharing in violation of their licenses." [those are paraphrases, but definitely in the spirit of the actual quotes]

Freedom over convenience

Posted Oct 4, 2006 10:10 UTC (Wed) by stijn (subscriber, #570) [Link] (1 responses)

When exercising their rights the content owners are using a big club and overwielding it to the extent that 1) you loose the rights or the power to exercise rights you had before (think fair use, time/space shifting). 2) the means they use encroach in other technological areas as well.

Increasingly ridiculous EULAs will be substituted by and implemented with DRM. Information or content if you will will be licensed under EULA type restrictions.

I am not sure I disagree with anything you say, but somehow I have trouble grasping the symmetry between DRM-licensed content and GPL-licensed code, looking at it from the perspective of nourishing creativity and progress - rip and mix.

Freedom over convenience

Posted Oct 4, 2006 14:49 UTC (Wed) by sepreece (guest, #19270) [Link]

The symmetry is pretty straightforward. The GPL says "you may redistribute so long as you meet these conditions." Movie and music producers say to their distributors "you may redistribute our content so long as you meet these conditions".

I'm certainly not saying that the content owners are nourishing creativity and progress by restricting their content, just that what they are doing appears to be within the rights granted them by copyright. For that matter, I have reservations about the GPL on the same point.

As to fair use, it's a very slippery concept. There's never been a hard definition that allows you to know exactly what use is fair use. In any case, fair use limits the owner's ability to sue you for certain uses of hte material, it doesn't require that the content owner make it easy to make fair use of the material.

For instance, a reporter clearly has a right to quote from a public speech, but there is no requirement that the speaker provide even a written transcript, let alone an electronic transcript or recording. Similarly, the fair-use right to quote from a movie for a review doesn't require that the owners provide clips, either on request or by capture from a playback device; it just means you're not infringing if you use clips in a review [note,however, that if you got those clips by circumventing DRM, as opposed to by videotaping a playback, you may still be violating the DMCA].

FSF is creating a problem that never existed!

Posted Oct 2, 2006 19:26 UTC (Mon) by landley (guest, #6789) [Link] (6 responses)

> I'm also worried that RMS justifies the closed decision-making process
> of the GPLv3 because: "Most of our community does not appreciate
> freedom" .

While I remain as amused as ever by those who would impose democracy at
gunpoint, spread by the sword the philosophy of turning the other cheek,
or otherwise force people to be free against their will, I'd like to point
out that the argument being covered here wasn't really about the contents
of GPLv3. It's about GPLv2 being "good enough", and a dual license being
extra work to maintain.

Some people consider a BSD license to be "good enough". I disagree
because a BSD/MIT style license seems to encourage forking by having your
developers hired away to work on a proprietary version (ala the history of
BSD: Bill Joy leaving Berkeley for Sun in 1982, the CSRG going to BSDI a
decade later, Jordan Hubbard going from FreeBSD to MacOS X a few years
ago...) GPLv2 prevents that; the forks can converge because you always
get the patches back, and Linus or Andrew can change employers freely
without jeopardizing their ability to contribute to the project. This is
pragmatically useful.

With GPLv3 the FSF is off on an ideological kick trying to open up the
Xbox, which has _NOTHING_ to do with the purpose of GPLv2. I see the
purpose of GPLv2 as to keep open source projects from forking off closed
source proprietary versions that suck away seasoned developers every time
they develop enough momentum to become commercially interesting. GPLv2
keeps code commodity, and prevents anybody from trying to corner the
market by throwing money at developers. (Maybe this is bad for some
individual developers, but it's very good for the _project_ and thus
better for _most_ developers. And Linus hasn't exactly gone hungry.)

GPLv2 has an excellent pragmatic effect, good for the project's
development. And when shooting for this effect, GPLv2 nails it. Thus I
continue to want to use GPLv2, no matter what the FSF says. Now the FSF
seem to be pissed that Google won't let users run arbitrary code on its
servers, and are trying to draft me into this new fight over Tivo and the
Xbox (I own neither), and I'm just not _interested_. That's not what I
thought this "or later" clause was for, I dislike being coerced, and I'm
not giving them any more blank checks.

But fundamentally, the central issue for me is that GPLv2 is good enough,
it still works fine for me, I don't need other licenses, and I never asked
for more than GPLv2 provides. There didn't used to _be_ a GPLv3, and I
still don't see the need for it. Using "but what if it goes away"
fearmongering to leverage a whole new agenda is kind of slimy, and despite
the chicken little act GPLv2 is NOT going away as long as the Linux kernel
uses it. And if I have to make a choice between throwing in my lot with
the Linux kernel developers, or throwing in my lot with the FSF? It's no
contest.

FSF is trying to solve our coming problems

Posted Oct 2, 2006 20:28 UTC (Mon) by man_ls (guest, #15091) [Link] (5 responses)

And people still wonder why Stallman tells the printer driver story all the time.

GPLv2 was not about forking, gainful employment or development at all; it was about replacing the darn printer driver in the 90's. GPLv3 is about replacing it in the 21st century. Once the printer server runs a TPM chip it's back to square one. With the GPLv3 Stallman is just saying: "you can do it, but not with my code". It's simple, really.

FSF is making the Tivo situation worse

Posted Oct 2, 2006 21:05 UTC (Mon) by mingo (subscriber, #31122) [Link] (4 responses)

GPLv2 was not about forking, gainful employment or development at all; it was about replacing the darn printer driver in the 90's.

The printer driver situation was materially different from the Tivo situation. The printer driver was closed-source and he could not get the source code to fix obvious bugs in it.

Today most of the printers have free drivers. Why? Not because the printing industry symphatises with RMS's desire to hack his printer driver, but because they saw an economic necessity to serve a growing market. (Linux servers and Linux desktops)

In other words: the printing industry reacted to people's desire to run Linux, and to use their printers under Linux. Please remember: the key to having open printer drivers was people wanting Linux.

But the Tivo situation is completely different.

The Tivo was DRM-ed because it plays content from an industry that required its copyrighted works to be protected. There were people (besides honest tweakers) who were "hacking" not to fix bugs in the Tivo but to avoid having to pay for "pay per view" content. So replying to content industry pressure Tivo closed it down more than they have originally done (being an appliance, they never anticipated it being modifiable), and added this crypto based virtual-ROM technology that restricts the hardware to run only certain kernels that match a given hash. As far as the user is concerned it behaves like old-fashioned ROM, in practice it is not modifiable. (but the manufacturer can come and can flip in an upgraded ROM - just like with old-fashioned ROMs)

If Tivo couldnt use Linux they'd be using LynxWorks or some other embedded OS, because people are not interested in the Linux in the Tivo, people are interested in Tivo's userspace app and in the content the Tivo is offering.

Please think about it. By trying to go "eye for eye" with Tivo we only hurt Linux and help Hollywood's monopolization efforts, because one more small player would exit their market - and that small player does it all voluntarily, via a licensing change. We'd also further isolate Linux from a market that people are interested in. Whoah, Microsoft's dreams come true!

So what we are doing via the anti-Tivo language is that we hurt Linux and help Hollywood. It will not result in free Tivos. It results in no DVD playing hardware or software being associated with Linux at all! The reason again: people are not interested in the Linux aspect of these players.

And if the Tivo case is completely inapposite, if it achieves precisely the opposite effect, then why is the GPL trying to "address" it? Why are we doing all that anti-DRM stuff in the license to begin with, if it only hurts the little guy and helps big corp, even for the case that was singled out by RMS himself: Tivo?

Tivo sucks

Posted Oct 2, 2006 21:41 UTC (Mon) by man_ls (guest, #15091) [Link] (3 responses)

Ingo, do not let those Hollywood arguments drive you. Just imagine that the Tivo player, apart from recording movies and replaying them, has an attached printer and you want to print a screen capture. Or a program listing, whatever. Then you discover that the printer is not working for you, since the driver is broken. Then you, who are an excellent kernel programmer and knows that the thing runs Linux, want to repair the driver. Then you find out about the TPM and how it won't let you upgrade the device you legally bought, because the guys who took your money are treating you like a thief. Then... déja vu.

And if the Tivo case is completely inapposite [...]

My goodness, inapposite is a word! Anyway, I would gladly leave that bastard market to Microsoft. It would save Linux from the creepy associations that DRM brings, and would be one more reason to see DRM crumble. But then it's not my code in there.

Tivo sucks

Posted Oct 3, 2006 15:46 UTC (Tue) by southey (guest, #9466) [Link] (1 responses)

I don't see your point. What I understand, as I don't have Tivo, is that they provide the source code so you can fix your issues. So it is incorrect to say that it won't let you upgrade the device you legally bought.

The real issue for you is that you still want to run Tivo when you have modifed your Tivo system. However, Tivo is the combined package of hardware, software and content, so you can not have one without the others. Also, you are not clear on what you actually brought and under what terms when getting a Tivo system. By modifying your software and/or hardware you have appeared to violated the terms of sale and/or contract with Tivo in that you can use the hardware and software just not with Tivo. If MythTV and other similar software got easy to install and competitive then current Tivo situation probably would become disappear.

In your argument you seem to be forgetting the rights of the people that are involved. If Tivo did not use TPM it would have to find some other method of control to protect the rights of itself and the content providers. The real answer is not DRM or GPLv3 but working with the likes of Tivo and other content providers to protect everyone's rights.

Tivo sucks

Posted Oct 3, 2006 23:27 UTC (Tue) by man_ls (guest, #15091) [Link]

What I understand, as I don't have Tivo, is that they provide the source code so you can fix your issues.

Except that you can't. You can't run modified software so source code is useless.

In your argument you seem to be forgetting the rights of the people that are involved.

I forget them for a reason. Imagine that I tell you that the U.S. Constitution must "balance" the rights of the people and those of the Government: you would probably laugh at me. The government doesn't need rights, since it has the power. Or suppose we are talking about slavery and I tell you that we need to "balance" the rights of the slave with those of the master. The imbalance is so strong to begin with that it is ludicrous.

The right to copy (or copyright) was called that way because it expressed the rights of the author to be paid by a publisher. Here the powerful party was the publisher; no rights of his were "balanced" against those of the author. Now the "author" has become so powerful that you, the reader, have nothing to bargain with -- except your money, and money can hardly be called "a right". There is no way I can balance e.g. my rights of fair use with anything else; the publisher just locks the work of art and I'm screwed. Yes, Tivo can "balance" their contract with content providers, but I'm left out of the loop: I lose every time. The "rights" in "Digital Rights Management" are farcical. So I prefer to forget them to avoid cronic depression.

Tivo sucks

Posted Oct 20, 2006 10:52 UTC (Fri) by blujay (guest, #39961) [Link]

I know this is an old thread, but...

The answer is: Don't buy the Tivo! You keep using an argument
of, "Imagine if *your* Tivo...." If that was an issue for me, I would
simply not buy the Tivo! Vote with your wallet and give your money to
those that make better (and perhaps more open) products.

Imagine a situation where Linux went GPLv3. Can you force Tivo to start
using Linux/GPLv3? Or will they A) continue using Linux/GPLv2, or B)
switch to something not licensed under GPLvx, perhaps even a BSD?

I read a comment earlier that basically said, "I think we're important
enough now that we should flex our muscle." That strikes me as a bit
arrogant. Those that feel this way about GPL-ed software may be in for a
surprise when they find out that these device manufacturers they're
trying to coerce don't really care about Free Software at all; they're
interested in practicality, much like the kernel devs, and will quickly
ignore any GPLv3 software, and even switch to proprietary software. Then
what have you accomplished? Well, "your" Tivo will be no more hackable
than it is now, and probably less so. Free Software will become less
relevant in these industries (which I'm not sure matters anyway; again,
vote with your wallet). Microsoft will probably be happy and you might
even see some "Powered by Windows Vista technology" stickers on "your"
Tivo.

Linux and Free Software are getting some pull in enterprise systems, it
seems, but I think some people overestimate their value in these kinds of
embedded systems.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 16:37 UTC (Mon) by mrfredsmoothie (guest, #3100) [Link]

Without realizing this enormous moral obligation, and without codifying that obligation into the license and into the license update process i feel there is no possibility for the GPLv3 process to be open in the sense of free software: we should not only have the ability to see the process, but also the ability to modify it.

Why is it only contributors that deserve this freedom-to-modify? What about users?

Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.)

This is by far the more valid concern, IMO. I don't think contributors who wouldn't have agreed to new terms should be bound to them after-the-fact, and I don't know how well the whole "spirit of the license thing" would hold up in court WRT the "or any later version" thing (I doubt any court is going to enjoy sorting out what each developer "meant" when they licensed under the GPL).

FSF is creating a problem that never existed!

Posted Oct 7, 2006 2:53 UTC (Sat) by mikov (guest, #33179) [Link]

I have to say that while until now I was hesitant on the GPLv3 issue, after reading your excellent posts on LWN, you have managed to convince at least one person -> me.

It is obvious to me now that even if hypothetically the world would be a better placee with GPLv3's additional restrictions, the FSF has no right to introduce them, because those restrictions are not what many developers agreed to when they were accepting the GPLv2 license. Even if those developers were foolish for not considering and fully understanding what they were accepting, the FSF has no moral right to take advantage of that.

Practically speaking, even if the GPLv3 really IS universally better (obviously many people think that it is), it should not automatically apply to GPLv2-licensed projects who happen to have the "or any later version" text.

All problems will be solved by renaming the GPLv3 to "NGPLv1" so that it isn't covered by the "later version" text. Projects are completely free to adopt it deliberately and knowingly.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 9:11 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

Who will interpret the "similar in spirit" clause, and in what way?

Court, of course - who else ? Since FSF can only relicense code for GCC, GLibC and other projects under GPLv3 if the GPLv3 is considered "similar in spirit" to GPLv2 (that's part of contract between FSF and contributors) you can stop all this nonsense if you'll go to court and prove that GPLv3 is not "similar in spirit" enough. Are you ready to do this ?

FSF is creating a problem that never existed!

Posted Oct 2, 2006 10:29 UTC (Mon) by mingo (subscriber, #31122) [Link] (1 responses)

Since FSF can only relicense code for GCC, GLibC and other projects under GPLv3 if the GPLv3 is considered "similar in spirit" to GPLv2 [...]

Again, you are missing so many points that i hardly know where to begin with.

Firstly, the few hundred contributors who assigned their copyrights over to the FSF also did so with an implicit trust attached: that these copyrights wont be abused. If the FSF relicenses their code to the GPLv3 without making sure that they agree with those license changes, then it runs the risk of abusing that trust. The "oh, the license and the assignment document allows this" defense might work legally, but it does not work morally.

Secondly, by allowing a huge body of "GPLv2 or later" code, written by over one hundred thousand contributors, to be incorporated into more restrictive "GPLv3 or later" licensed codebases, the FSF runs the risk of abusing the trust these people have put into the FSF when they made their "GPLv2 or later" contributions: that the modifications to those codebases wont automatically be back-mergable into the "GPLv2 or later" codebase they originated from. (At least the current GPLv3 draft has such unfair "self-propagation" properties, by setting up assymetric contribution dynamics.)

Here too the "but you allowed this scenario by lazily keeping the default 'or later' condition in the COPYING file" defense might help legally, but it does not help morally.

Do you acknowledge that all these contributors do have a moral expectation of their contributions being used fairly, and that the FSF has a moral obligation to meet those expectations?

FSF is creating a problem that never existed!

Posted Oct 2, 2006 11:12 UTC (Mon) by walken (subscriber, #7089) [Link]

> Secondly, by allowing a huge body of "GPLv2 or later" code, written by over
> one hundred thousand contributors, to be incorporated into more restrictive
> "GPLv3 or later" licensed codebases, the FSF runs the risk of abusing the
> trust these people have put into the FSF when they made their "GPLv2 or
> later" contributions: that the modifications to those codebases wont
> automatically be back-mergable into the "GPLv2 or later" codebase they
> originated from. (At least the current GPLv3 draft has such unfair
> "self-propagation" properties, by setting up assymetric contribution
> dynamics.)

Once again there is nothing new here. This is the same old "GPL is a virus" argument: one can get BSD code into a GPLv2 project, but GPLv2 code can not go back into a BSD project (or it can, but the resulting binary is covered by GPLv2). You've never had a problem with that, so why do you feel the equivalent situation with GPLv2 and GPLv3 is a moral issue now ?

FSF is creating a problem that never existed!

Posted Oct 2, 2006 16:28 UTC (Mon) by mrfredsmoothie (guest, #3100) [Link]

The FSF, in their false zeal to kill the "evil Tivo" are trying to use their unprecedented legal power to add new moral considerations to the license - which were not in the license before.

The suggestion that moral considerations weren't a part of the license of *every* GPL-v2(whether "or later" or not)-based project seems either incorrect or at least over-simplified to me. So Linus says on Groklaw that he was primarily interested in first anti-commericalism and subsequently the tit-for-tatness. He's one developer. How many other contributors had the "give every user the same rights" motivation as their primary one? The anti-DRM provisions are merely extensions of the same "Freedom 0" idea that RMS wrote the license for in the first place.

While I'm not arguing for the kernel, BusyBox or any other project adopting the GPLv3, part of me is very sympathetic to the fear that DRM has the ability to render "every user is free to modify" as "every employee of a hardware manufacturer is free to modify" and I strongly suspect that that's not what a very large number of contributors to most GPL-licensed projects had in mind.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 18:14 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (5 responses)

> I'm sad that the FSF is creating a problem in free software projects
> where none existed before: the GPLv3 process is polarizing the community
> along moral lines that were artificially injected into the GPLv3 draft.

Ingo, I am deeply respectful of your work, but the party who released an inflamatory statement, backed by a 30-people informal private closed poll¹, taking pride in its refusal to participate in any discussion, is not the one you point out.

"But it we had discussed they wouldn't have listened to us anyway" is kindergarten-level excuse.

Also when a select few argument it was "obvious" GPL v2 = open source and != free software², I can only wonder in what hole they've been living these past years, and why they never bothered to inform all the people feeding them patches and testing about this strange opinion. As someone who did all those things for years, discovering I've been lied to and it was actually a BSD after all is quite offensive.

You've been using the FSF license for years, and people have been working with you knowing this (sometimes because of this) so you're in the same boat as the FSF whether you like it or not. Please stop this blind FSF bashing this is the only self-destructive madness I see.

Last I've heard, no one, least of all the FSF, pretended the FSF had the legal ability to unilaterally change the Linux kernel license. But I *am* seeing some people claiming ability to unilaterally stop the free software community³ from thinking about updating its main license, and so convinced of their holy right they're not even bothering to contruct any sensible argument.

Who do you think is losing credibility fast these days ?

¹ and even then not everyone of those little few agreed to sign the statement
² yes, someone actually claimed this
³ which is not limited to the people contributing to the Linux kernel, not that this smaller population was even consulted before statements where put out in its name

FSF is creating a problem that never existed!

Posted Oct 2, 2006 18:33 UTC (Mon) by cventers (guest, #31465) [Link]

Well said!

FSF is creating a problem that never existed!

Posted Oct 2, 2006 20:06 UTC (Mon) by mingo (subscriber, #31122) [Link] (3 responses)

sorry, but the only non-personal-attack point i could make out from your post was this one:

Last I've heard, no one, least of all the FSF, pretended the FSF had the legal ability to unilaterally change the Linux kernel license.

(if you had any other arguments then please repeat them without any slant, side-kick or accusation. Thanks!)

and even this one misrepresents what i said. The kernel is under a GPLv2-only license, and as such outside of the reach of the FSF. But as an amusing sidenote, the FSF did try to claim behind the scenes that:

1) Linus did not really mean it when he has put "this license only" into the COPYING file, or

2) that main contributors have the ability to relicense the kernel to GPLv3 without the consent of all contributors, and without the consent of Linus in particular.

Most of the 350+ million lines of code codebase i referred to is currently under a "GPLv2 or later" license, and yes, i contributed to some of that codebase too, not only to the GPLv2-only kernel. Also, even as a kernel developer i do worry about the future of free software in general.

Have i understood your point correctly, that you deny that the FSF has unilateral legal power to change the contribution dynamics of that huge codebase?

(But i dont really expect any response to the essence of my posts - as i didnt get any response once i got down to the boring details of reality in other discussions. I have yet to see a single proponent of the GPLv3 who is willing to argue it through fairly and objectively, without calling names or avoiding topics once the discussion gets uncomfortable to them. I might be surprised positively and i might have to concede that i was wrong all along, but that has yet to happen.)

FSF is creating a problem that never existed!

Posted Oct 2, 2006 22:18 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

> The kernel is under a GPLv2-only license, and as such outside of the
> reach of the FSF

So no one dragged the kernel developpers in the debate, they could work with the FSF on its new project, or ignore it altogether.

I see your point on non-kernel code, but you know, I don't find claiming a position of authority as a core kernel developper to discuss the problems of other projects much more tasteful than what the evil things FSF is supposed to have done.

> Have i understood your point correctly, that you deny that the FSF has
> unilateral legal power to change the contribution dynamics of that huge
> codebase?

IANAL so I won't speculate on the value in international IP law of a license preamble. Especially if you add a vague "contribution dynamics" to the mix (though a judge would probably agree that any person following Linux development knew perfectly well what "GPLv2 or later" meant after the numerous "GPLv2-only" clarification messages of Linus)

Moraly, as far as I know the GPL v3 is perfectly consistent with the GNU manifesto, so should the FSF relicense code which has been assigned to them to the GPLv3, I don't see who could honestly complain (of course legally the FSF can relicense it to whatever it wants to)

Practically, for code which hasn't been assigned to them the FSF can at most argue they're allowed to create a GPLv3 fork, and this fork won't fly unless :
1. they convince the major existing contributors
2. they write enough useful new code

(true both on the enforcing license and maintaining code front)

And this is mostly how big decisions are taken in FLOSS forks anyway. The orbital laser power of the "GPLv2 or later" clause seems greatly overrated to me (except for simplifying the management of past or minor contributions). The basic rule doesn't change a FLOSS fork which pisses of its contributors is a dead fork.

On the dynamics front, should the FSF write a pleasing license, it will certainly impact the contribution dynamics of both new and existing projects. IIRC one of the "GPLv2-only" clarification messages Linus wrote argued that :
1. he didn't blindly trust the FSF but
2. the code churn of the kernel was sufficient for relicensing, should most of the developpers agree with the new license

So I certainly do not agree with the idea the GPLv2-covered codebase is so big it's impossible to pull a GPLv3, even for the Linux kernel.

Nevertheless what ultimately counts is the quality of the actual GPLv3 text. Arguing about things the FSF may or may not have said (and never enacted) behind the scenes is pointless. There's an easy way out for everyone to get a good GPLv3 out of the door. The FSF already pulled its baby past the point where a little flaming could kill it.

FSF is creating a problem that never existed!

Posted Oct 2, 2006 23:54 UTC (Mon) by mingo (subscriber, #31122) [Link] (1 responses)

So I certainly do not agree with the idea the GPLv2-covered codebase is so big it's impossible to pull a GPLv3, even for the Linux kernel.

Oh, as long as it's on a voluntary basis, once the GPLv3 is known, so that people can do an informed decision based on its true contents, for either new contributions or for relicensed old contributions, i'm perfectly on your side.

But that voluntary basis is not actually what the GPLv3 does. What it does is it retrospectively affects a huge codebase and it potentially makes it "half-incompatible" with GPLv3 projects, which incompatibility is fundamentally slated in favor of GPLv3 projects: by not allowing fixes to be backmerged from GPLv3 codebases into "GPLv2 or later" codebases - even if the code originated from the "GPLv2 or later" codebase.

FSF is creating a problem that never existed!

Posted Oct 3, 2006 6:56 UTC (Tue) by nim-nim (subscriber, #34454) [Link]

The "can not go back" aspect of the GPLv3 is the same as the GPLv2 so the GPLv3 is no worse in this regard than the v2.

That the possibility of relicensing v2 code to v3 exists is an accident of history, namely the FSF writing a great license which has served well many projects. That is has the authority to lead many persons in this fork is a consequence of them trying to wrangle with the legal problems of FLOSS software while others wouldn't be bothered with them.

On the whole even if the FSF exerts this fork-"right" hostilely (which it hasn't so all this is "trial of intentions" so far) I'd say they'll have won the moral right to do so. They're doing the legal work.The BSDs, wine and others have shown it's not something which can safely be ignored because coders find it un-cool.

FSF is creating a problem that never existed!

Posted Oct 3, 2006 15:41 UTC (Tue) by jzbiciak (guest, #5246) [Link] (2 responses)

Firstly, keep in mind that the "or any later" language has always been optional. If, as a programmer, you chose "GPL v2 or later" as your license, and you did so without thinking, that's too bad. I personally specifically chose to keep it. I want my software to be as broadly used as possible, but with the notion "contributing back." My choice of "GPL v2 or later" allows my code to be incorporated into nearly all GPL'd software, regardless of what GPL variant the person borrowing my work uses. The only "danger" I run is that GPL vX ends up being equivalent to "public domain," which is only likely to happen if the FSF wins the "Software Wars," making all software Free. (Highly unlikely.)

Also, I think you misunderstand the "or any later" language. If I release software written under the GPL and release it with the license "GPL v2 or any later version," that means code from that software can be incorporated into GPL v2-only programs, GPL v3-only programs, and programs that allow GPL v2 or later.

Note that my code retains its "GPL v2 or later" status. When someone takes a portion of it and puts it into their more-specifically-licensed project, the resulting aggregation is what collapses that vague "range of licenses" to a specific license. So if someone takes my "foo.c" (licensed as GPL v2 or later), and drops it into "BarBaz" (licensed as GPL v2 only), the resulting BarBaz is GPL v2 only. If someone else takes my "foo.c" and drops it into "QuuxQuux" (licensed as GPL v3 only), the result is GPL v3 only. Later still, someone could stumble upon my foo.c, present in either BarBaz or QuuxQuux, and extract it. Assuming that extracted file wasn't modified after inclusion in BarBaz or QuuxQuux, its entire contents retains my original license.

In other words, the license an aggregate ships under must be within the intersection of all the licenses of its consituent pieces. Those consituent pieces do not automatically lose their identity. Placing a piece of code under "GPL v2 or later" simply increases the likelyhood its license overlaps with the licenses of other code.

That isn't to say the results are perfect. For instance, I've released jzIntv under GPL v2 or later. Someone could take jzIntv and fork it, releasing a GPL v3-only version. GPL v3 patches to that version could not be pulled into my GPL v2-or-later version without relicensing the patch, or without the aggregate becoming GPL v3. But, as long as someone cares about the GPL v2 version, it doesn't go away. If I or someone else decides to switch to GPL v3 for new code, the old code doesn't disappear.

FSF is creating a problem that never existed!

Posted Oct 24, 2006 22:34 UTC (Tue) by landley (guest, #6789) [Link] (1 responses)

> Firstly, keep in mind that the "or any later" language has always been
> optional.

Actually, you have to go out of your way to opt out. The last sentence
of section 9:

> If the Program does not specify a version number of this License, you
> may choose any version ever published by the Free Software Foundation.

So if you just said "This is GPL" when GPLv2 was the law of the land, the
FSF gets to arbitrarily relicense it because you didn't go out of your
way to say they couldn't.

FSF is creating a problem that never existed!

Posted Oct 24, 2006 22:51 UTC (Tue) by jzbiciak (guest, #5246) [Link]

I don't think that's going any further out of your way than saying "this is GPL." If you're sloppy when you pick your license, it's clear you don't really care what the license is. The real debate should center around people who thoughtfully chose "GPL v2 or later" who are now re-evaluating that choice. And, I argue, there's not a real problem there, since you can fork and move on.

I still don't see the issue with the "or later" language. If someone writes a GPL v3-only patch to a GPL v2-or-later program, the patched program is GPL v3-only. The unpatched program still exists, though. So, if someone else didn't like GPL v3, they could continue developing the GPL v2-or-later program, perhaps making the result GPL v2 only if they so desire.

Busy busy busybox

Posted Oct 1, 2006 22:14 UTC (Sun) by dlang (guest, #313) [Link]

assigning the copyright to the FSF avoids this problem legally, but only by makeing the FSF legally able to ignore the wishes of all the origional authors.

if busybox had such a policy then Bruce could just be told to shut up as the code now beloged to the project, and they could do anything they wanted with it (including releasing it under a closed license if they decided to)

as it is Bruce's code is still in there, still with his origional license choices. however the combination with other people's code makes the result GPLv2 only.

note that if all the code had been GPLv2 or later (or compatable) and a patch licensed under the GPLv3 or later was accepted you would have the same debate, becouse all the origional authors wanted GPLv2 and including the new patch would eliminate that possibility, potentially causeing a fork at that time to create a version that's compatable with the GPLv2

David Lang

Busy busy busybox

Posted Oct 1, 2006 22:41 UTC (Sun) by daney (guest, #24551) [Link] (1 responses)

Although on the surface the disagreement was over the busybox license, I think the real underlying problems were of a non-technical and non-licensing policy nature. My personal opinion is that the (now former) maintainer was in some cases lacking in civility and took many issues personally. If a different approach to interacting with the contributers to busybox had been taken, I think the project and all involved would have been better off.

Unfortunately this type of situation is not rare in the world of FOSS.

Busy busy busybox

Posted Oct 2, 2006 17:28 UTC (Mon) by bronson (subscriber, #4806) [Link]

Tell you what. Why don't you sink that much of your own time and effort into a similar project? Then, when some absentee father comes out of dusty history and starts wasting you and your lawyers' time by unilaterally declaring what you should do with it, let's see how YOU take it.

Not well, I'd guess. I do wish Rob could have been more civil but, all said, I hear where he's coming from. And I do hope he stays part of the project; BusyBox is great largely thanks to his efforts.

This is ridiculous!

Posted Oct 1, 2006 23:56 UTC (Sun) by paravoid (subscriber, #32869) [Link] (5 responses)

It's always sad to see a competent maintainer leave a project because of flamewars among the developers.
It's even sadder to see one to leave because of flamewars that involve people that hadn't contributed to the project for _a decade_.

Bruce's demands are outrageous. He did license his code as GPLv2 *or* later. Anyone is feel free to keep the "or later" part or drop it at any point. Just as anyone is free to relicense code under the (2/3-clause) BSD to GPLv2 (or any other license for that matter).

Bruce made no legal "demands"

Posted Oct 2, 2006 0:21 UTC (Mon) by stevenj (guest, #421) [Link] (4 responses)

Bruce's demands are outrageous. He did license his code as GPLv2 *or* later.

Go back and read Bruce's messages. He made no "demands", only requests that his wishes be accorded some courtesy—at least with respect to the code that he wrote. Bruce explicitly said:

However, it's free software, and Rob has the right to do what he did. You, however, might want to think twice before you go along with this strangeness. [emphasis added]

(Over and over again, I see the fallacious argument that if you don't legally require something, you are somehow wrong to request it, feel strongly about it, or to try to persuade people of it.)

Bruce made no legal "demands"

Posted Oct 2, 2006 6:38 UTC (Mon) by rsidd (subscriber, #2582) [Link] (3 responses)

Go back and read this message. He says "I request and require that you add a notice to the license statement for busybox that portions of the program are copyrighted by me, and may be licensed under the GNU General Public License without regard to the particular version of that license."

Sorry, that is a demand not a request, and a clueless demand at that. His existing copyright notices are there and not modified. They say "GNU General Public License", and the version would be by implication the then-current version of that licence; they do not say "or later". Even if they did, the key conjunction is "or", not "and". The current project's maintainers are free to use Bruce's version in a GPLv2 only project. People who want to use GPLv3 are free to go back to Bruce's original sources and use that.

For one of the open source movement's loudest self-appointed prophets, Bruce Perens (like Eric Raymond) is singularly uninformed, offensive and has contributed almost nothing since the movement started getting taken seriously (ie, since around 1998).

Bruce made no legal "demands"

Posted Oct 2, 2006 9:09 UTC (Mon) by atai (subscriber, #10977) [Link] (2 responses)

They say "GNU General Public License", and the version would be by implication the then-current version of that licence; they do not say "or later"

This is wrong. There is no such implication and the original author's statement (as available in this case) is the only correct interpretion. Even of the whole project is v2 only, keeping the copyright notice as requested by the author is something to do out of basic respect and morality.

Bruce made no legal "demands"

Posted Oct 2, 2006 10:07 UTC (Mon) by rsidd (subscriber, #2582) [Link] (1 responses)

Go back and read those messages. The copyright messages are being kept, unchanged, in the files where they belong. To remove them would be a violation of the GPL (any version). What Bruce "requests and requires" is not this, but additional text inserted in the licence file, saying that while busybox is licensed under GPLv2, those bits written by Bruce may also be licensed under GPLv3. Such a notice is not required by the GPL and Bruce cannot demand it.

Bruce made no legal "demands"

Posted Oct 2, 2006 18:25 UTC (Mon) by landley (guest, #6789) [Link]

> What Bruce "requests and requires" is not this, but additional text
> inserted in the licence file, saying that while busybox is licensed
> under GPLv2, those bits written by Bruce may also be licensed under
> GPLv3.

I started the forensic analysis to figure out what actual code Bruce was
demanding these notices on. When I found out how little he actually did
in the first place (and that essentially none of it had survived into the
modern version anyway), I got kind of annoyed. (The initial objective
actually wasn't to remove his code, but it's hard to remove his code from
the project when he hasn't _got_ any.)

I find it odd that this is considered newsworthy...

The "or later" clause and marriage

Posted Oct 2, 2006 0:02 UTC (Mon) by riddochc (guest, #43) [Link] (24 responses)

I must admit, first, that I haven't decided how I feel about the GPLv3. I'm still trying to sift out real arguments from straw men, on both sides, and I wish there were better resources on copyright, patent, and contract law available for study online. I want my opinion, whatever it will be, to at least be informed.

I remember when I first took notice of the "or later" clause about seven or eight years ago, and it worried me: what if the future versions of the GPL would be completely in conflict with the spirit of the GPL as I understood it then?

I just got married last month, and that was the first time I felt good about believing that come what may, I'm committed. The future is uncertain, people change, circumstances could make anyone do things that their younger selves might have been aghast at. It was a real leap of faith for me to accept that even if things do change in my relationship, I'll make my best effort at finding real solutions rather than bailing out.

I don't make leaps of faith like that lightly. The FSF has been, overall, a good organization. Past performance can predict future actions, but given enough time, anything can change. Do I absolutely trust that every future version of the GPL is one that I'll want to use for my projects? Not without knowing what the future GPLs will say.

I will not decide what I think of licenses until I've read, studied, and understood them. The kind of trust the "or later" clause requires has no place outside of intimate relationships.

The "or later" clause and marriage

Posted Oct 2, 2006 0:29 UTC (Mon) by sanjoy (subscriber, #5026) [Link]

Larry Rosen's book Open Source Licensing: Software Freedom and Intellectual Property Law (Prentice-Hall 2005) is available online, under an open-source license, the Academic Free License.

It's an excellent book.

every other major copyleft forces you to allow later license versions

Posted Oct 2, 2006 0:42 UTC (Mon) by stevenj (guest, #421) [Link] (22 responses)

Omitting the "or later" clause causes enormous practical problems, as we are seeing now, because it reduces compatibility and means that the license can be extremely difficult to update if legal problems with it are found, or if copyright law changes. IMO, this outweighs any "danger" that the FSF will abuse the trust—and in any case, the worst that can happen is not very bad since you always have the option of restricting the license versions for future code releases.

And the FSF is hardly alone in this practice. For example, the Creative Commons ShareAlike license says:

You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License ... [emphasis added]

Same for the Mozilla Public License (MPL), which says:

You may also choose to use such Covered Code under the terms of any subsequent version of the License published by Netscape.

So, Creative Commons and MPL don't even give the licensor a choice about whether to allow license upgrades—the ability to use later versions of the license is built directly into the license terms. And yet the FSF, which merely encourages people not to lock themselves into one version, is the one asking for unreasonable trust?

Who let the sane person into this discussion?

Posted Oct 2, 2006 0:47 UTC (Mon) by GreyWizard (guest, #1026) [Link]

Well said.

every other major copyleft forces you to allow later license versions

Posted Oct 2, 2006 1:14 UTC (Mon) by dlang (guest, #313) [Link] (20 responses)

quote:
this outweighs any "danger" that the FSF will abuse the trust

does it?

in the eyes of many people they are already doing so.

many supporters of the GPLv2 are ignoreing the fact that it's very possible to agree with GPLv2 and what it states without having inherent, unrestricted trust in the FSF.

then you say quote:
n any case, the worst that can happen is not very bad since you always have the option of restricting the license versions for future code releases

the worst that happens is that projects tear themselves apart arguing over which license to use, either destroying themselves in the process, or resulting in two incompatable projects doing the same thing (with neither having the critical mass to survive for long)

arguably we are seeing this happen now (and the GPLv3 isn't even out yet).

every other major copyleft forces you to allow later license versions

Posted Oct 2, 2006 1:50 UTC (Mon) by stevenj (guest, #421) [Link] (19 responses)

the worst that happens is that projects tear themselves apart arguing over which license to use

That's true for any free-software license—the contributors can always have philosophical disagreements that lead to forking.

It has nothing to do with any supposed legal risk of giving "inherent, unrestricted trust" to the FSF. The legal risk of making your code "v2 or later" seems very minor because of the "or"—you always have the option to use the old version.

every other major copyleft forces you to allow later license versions

Posted Oct 2, 2006 4:20 UTC (Mon) by viro (subscriber, #7872) [Link] (18 responses)

GPLv2 or later == giving up the expectations of always being able to
merge distributable modifications. Alice releases code under GPLv2 or
later. Bob uses that code in his project and makes modifications,
putting them under GPLv3. Carol does the same for her project and
makes modifications putting them under GPLv2. Both Bob and Carol
can distribute the results just fine. Alice, on the other hand,
can _not_ merge modifications from both sources - result will not
be legally distributable at all.

And for many people that ability to merge modifications back is
_the_ reason to use GPL on particular codebase.

GPL "v2 or later" may prevent merging back modifications? in practice, probably not

Posted Oct 2, 2006 5:09 UTC (Mon) by stevenj (guest, #421) [Link] (9 responses)

That's true, but it has nothing to do with the FSF abusing its trust, which was what the original poster feared. The FSF has always made it clear that they would update the GPL from time to time, and that updates could be incompatible unless licensors give permission to use license updates. It's hard to have a reasonable discussion if people keep shifting their arguments — please start a new thread if you want to discuss a distinct complaint.

Regarding your point, however, I'm skeptical that it will be a problem in practice. If a project is well managed and sets a firm policy that all contributions must be licensed compatibly with "v2 or later" (which didn't happen with BusyBox), past experience suggests that nearly all contributors will respect this (and troublemakers who don't can be ignored).

For example, there are numerous projects that are LGPLed, and any contributor who insisted on switching to the regular GPL (as is legally possible) could theoretically force the project to either fork or switch licenses. And yet, in practice, this does not seem to happen—zillions of LGPL projects seem to be continuing quite happily without continual relicensing battles.

In any case, incompatibility between copyleft license versions is almost unavoidable (which is probably why other copylefts like MPL and CC require "any later version" language). So, basically your argument boils down to either: FSF should never upgrade the GPL, regardless of what loopholes are found or whether legal conditions change; or that everyone should specify only a particular version, which would lead to much, much more incompatibility when the GPL is updated.

GPL "v2 or later" may prevent merging back modifications? in practice, probably not

Posted Oct 2, 2006 5:47 UTC (Mon) by dlang (guest, #313) [Link] (8 responses)

people aren't arguing that the license should never be changed no matter what.

what they are arguing is that they don't see the new license being in the same spirit as the old one. they don't see major loopholes that need to be closed.

the FSF does see large holes that desperatly need to be closed, and they seem willing to take drastic measures to do so (and a major license change is such a drastic measure)

unfortunantly, for many people these actions are prooving their worst fears about the 'or later' clause to be true, and this loss of trust will hurt any future changes that the FSF attempts to make (including those made in response to much more pressing problems)

GPL "v2 or later" may prevent merging back modifications? in practice, probably not

Posted Oct 2, 2006 6:40 UTC (Mon) by stevenj (guest, #421) [Link] (7 responses)

unfortunantly, for many people these actions are prooving their worst fears about the 'or later' clause to be true

These are their "worst fears?" *Yawn, hyperbole alert.* If they used "v2 or later" and the developers don't like the final version of GPLv3, they can always stick with v2's terms. Yes, hypothetically people could fork a v3 version of your code, but FUD about forking of FLOSS projects has almost always been proven false, regardless of license (whether GPL or BSD or LGPL), and the few exceptional cases (e.g. X11) were usually for good reason and ended up being applauded by the community. If the main developers of a project agree with one another, then no fork will survive; and if the main developers have basic philosophical differences then the project has problems regardless of license.

And anyway, forking of v2-only and v3-only projects could happen regardless of whether the changes in v3 were big or small, and regardless of whether you agree with them. There's nothing the FSF could have done to prevent this, except for not updating the GPL at all. (Except in a fantasy world where every developer on the planet likes v3 better than v2, which would never happen regardless of what v3 changed.)

In any case, considering that the FSF's changes are totally in line with what they have always said the goals of the GPL are (ensuring the user's right to modify, run, and redistribute the programs they receive), saying it's not "in the same spirit" seems tenuous. If you lose trust in the FSF because they stick to their stated ideals in the face of technical countermeasures (DRM and patents), then you haven't been paying attention for the past 20 years.

(I can easily come up with much worse fears. e.g. that GPLv3 == X11, which would open up all past "v2 or later" code to closed-source exploitation. This would be a true abandonment of the spirit of the license.)

GPL "v2 or later" may prevent merging back modifications? in practice, yes

Posted Oct 2, 2006 8:26 UTC (Mon) by mingo (subscriber, #31122) [Link] (6 responses)

unfortunantly, for many people these actions are prooving their worst fears about the 'or later' clause to be true

These are their "worst fears?"

You are materially misrepresenting what was said. He said: "their worst fears about the 'or later' clause".

*Yawn, hyperbole alert.* If they used "v2 or later" and the developers don't like the final version of GPLv3, they can always stick with v2's terms.

You are now compounding your misrepresentation of what was said with a false ridicule of their fears over the 'or later' clause.

Who are you to ridicule them over what they (which category, btw., includes me) genuinely believe? May i ask you what kind of free software projects you have participated in so far, and what the level of your participation was?

(In my judgement, if this attitude and social skills of yours isnt just an unfortunate one-time deviation in the heat of the moment but common practice then you could not have gotten very far into contributing to free software - but please by all means surprise me with facts to the contrary.)

GPL "v2 or later" may prevent merging back modifications? in practice, yes

Posted Oct 2, 2006 11:45 UTC (Mon) by walken (subscriber, #7089) [Link]

>> *Yawn, hyperbole alert.* If they used "v2 or later" and the developers don't like the final version of GPLv3, they can always stick with v2's terms.

> You are now compounding your misrepresentation of what was said with a false ridicule of their fears over the 'or later' clause.

It would help if you could clarify, in a concrete way, what these fears are.

Say you contributed code under "GPLv2 or later". now GPLv3 comes out and adds additional restrictions to v2 (the no-tivoisation clauses). tivo can stil use that code you wrote under the v2 terms. no immediate harm done as far as I can see (it'd be different if v3 was relaxing restrictions instead, though).

Later on someone might write a v3-only change, which would be an issue if you want to use his change, and he cares strongly about excluding v2, and you care strongly about allowing it. I suppose that would be too bad, but this is hardly RMS's fault if you can't agree on licensing terms with that future contributor.

Can you clarify what your fears are about GPLv3 ?

> (In my judgement, if this attitude and social skills of yours isnt just an unfortunate one-time deviation in the heat of the moment but common practice then you could not have gotten very far into contributing to free software - but please by all means surprise me with facts to the contrary.)

Aaaaw come on now, as if we don't know of any kernel devs with bad social skills... :)

Ad hominem

Posted Oct 2, 2006 16:22 UTC (Mon) by GreyWizard (guest, #1026) [Link]

You seem to be suggesting that challenging what some people believe is wrong regardless of the merits of that belief -- in other words that opposition to GPLv3 is some kind of religion that needs to be respected outside the boundaries of reason and argument. Dismissing an argument based on the credentials and social skills of the author without regard for the merits of the argument is an elementary logical fallacy.

http://en.wikipedia.org/wiki/Ad_hominem

I suggest you work on your own social skills before policing those of others.

GPL "v2 or later" may prevent merging back modifications? in practice, yes

Posted Oct 2, 2006 16:38 UTC (Mon) by stevenj (guest, #421) [Link] (3 responses)

He said: "their worst fears about the 'or later' clause".

Yup. And this is hyperbole...one can come up with much worse fears, as I pointed out at the end of my message; you're the one who is misreading what I wrote. If your "worst fear" about "or later version" permissions is that the FSF will add restrictions (regarding DRM or patents) you don't like, then your doomsday scenario is pretty tame—you can always stick with v2. The FSF cannot force you to add restrictions you do not want.

PS. I'm not going to take the bait and get into an ad hominem pissing contest with you. Please try to stick to rational arguments.

GPL "v2 or later" may prevent merging back modifications? in practice, yes

Posted Oct 2, 2006 17:17 UTC (Mon) by stevenj (guest, #421) [Link] (2 responses)

Lest you misunderstand me again, by "one can come up with much worse fears" I meant "one can come up with much worse fears in this context".

In case you haven't noticed, throughout this entire thread I've focused exclusively on the context of the "or any later version" permission. I believe this is clear if you read each posting in its entirety, as opposed to snipping out isolated phrases. (You're acting like I said, "Well, nuclear war is a much worse fear," when I said no such thing, and if you read what I wrote this is clearly not what I meant.)

Ingo, native English speakers rely on context and good-faith readers/listeners in order to make themselves understood. Only lawyers have to be careful to precisely turn every phrase to avoid any possible ambiguity, because lawyers have to prepare for people who deal in bad faith. Please don't make people who deal with you write like lawyers.

GPL "v2 or later" may prevent merging back modifications? in practice, yes

Posted Oct 2, 2006 17:41 UTC (Mon) by bronson (subscriber, #4806) [Link] (1 responses)

You said, Only lawyers have to be careful to precisely turn every phrase to avoid any possible ambiguity...

And yet you yourself have spent much of your time nit-picking Ingo's language and have mostly ignored his very clear intent.

Bull

Posted Oct 2, 2006 18:19 UTC (Mon) by stevenj (guest, #421) [Link]

And yet you yourself have spent much of your time nit-picking Ingo's language

Bull. All through this thread I've tried to stay on-topic regarding whether using "v2 or later" permission opens you up to some vague and terrible legal risks, and whether the FSF is fulfilling these fears with GPLv3 (separate from whether you agree with v3's changes).

Ingo posted exactly once in this thread (so far), and his points were (a) misreading my post to claim that I was not taking the phrase "worst fears" in the context of this permission, (b) making unfounded and irrelevant ad hominem attacks.

And I note that your post made not a single substantive point about the license language. Why are people so intent on changing the subject?

every other major copyleft forces you to allow later license versions

Posted Oct 2, 2006 17:03 UTC (Mon) by mrfredsmoothie (guest, #3100) [Link] (7 responses)

Alice, on the other hand, can _not_ merge modifications from both sources - result will not be legally distributable at all.

Right. Alice will have to (gasp!) talk to Carol and ask her to grant permission to license her changes under "v2 or later" terms.

Seriously, there's a lot of hyper-ventilating going on here. I admit that for *very* large projects with hundreds or more contributors, this *might* turn out to be a real problem, but it might end up being Son of Y2K, too.

every other major copyleft forces you to allow later license versions

Posted Oct 3, 2006 5:34 UTC (Tue) by himi (subscriber, #340) [Link] (6 responses)

What are the actual use-case scenarios for this?

Alice can pull the code in herself, in which case there's always going to be a potential licensing issue - without knowing what license the modifications are released under this is legally dodgy regardless of the history of the code, and Alice is an idiot if she doesn't ask for clarification/relicensing.

Alternatively, Carol can submit her code to Alice for inclusion, at which point /Carol/ is making the decision, and is either explicitly or implicitly granting a license to use her modifications.

Either way, it's something that sensible precautions will deal with, and certainly not a cause for the kind of FUD that's been floating around.

himi

every other major copyleft forces you to allow later license versions

Posted Oct 4, 2006 1:53 UTC (Wed) by viro (subscriber, #7872) [Link] (5 responses)

Three words: Objective C Compiler. Aka. "when FSF went after authors
of modified gcc and forced them to release their modifications for
for merge". And that was very definitely "forced", not "sweet-talked".
GPL allows you to do that; if authors of modification try to make
them legally unmergable for you, they lose the right to distribute
the entire thing themselves. That is, except for "or later" loophole.
That one allows parasitic forks that can pull from original codebase
without permitting to merge back. _And_ it allows for GPLv2-only
forks, to serious displeasure of FSF.

BTW, if you have "v2 or later" project, no extra restrictions of
GPLv3 have desired effect until you get GPLv3 (or "v3 or later")
fork and manage to kill development of the original. As long as
the project remains under "v2 or later", anti-DRM, etc. clauses
are trivial to bypass by saying "I'm distributing under GPLv2, as
allowed by project license". It's not about conspiracy theories,
etc. - that's simply how "or later" part of license is written.

So there are two possibilities: pressure authors of the original
to relicense under v3/v3-or-later *OR* fork, relicense the fork
that way yourself and try to make the original branch wither.

Now, put yourself in position of people who do not want to drop
v2. They are going to realize that v3 fork is coming. Moreover,
that fork will be able to pick their improvements, but not the
other way round. About the only response other than "give up" is
"curse, accept that v2-or-later is not sustainable anymore and
start protecting new code with v2-only". And that's exactly what
we are starting to see. And will see more as more people see
the writing on the wall and decide to do something about that.

BTW, to address LGPL -> GPL strawman: AFAIK nobody ever tried to
pull that off with anywhere near that level of intensity. And
"make as much as possible GPLv3-only" is pretty much the stated
goal - without that extra restrictions can't work. Forks to v3
are still not there (obviously - v3 needs to be finalized to put
something under it ;-). But pressure to drop v2 is already starting
to build up - see any number of whining on assorted maillists along
the lines of "you all must switch to v3 when it comes"...

every other major copyleft forces you to allow later license versions

Posted Oct 4, 2006 8:40 UTC (Wed) by himi (subscriber, #340) [Link] (2 responses)

That is, except for "or later" loophole. That one allows parasitic forks that can pull from original codebase without permitting to merge back. _And_ it allows for GPLv2-only forks, to serious displeasure of FSF.

BTW, if you have "v2 or later" project, no extra restrictions of GPLv3 have desired effect until you get GPLv3 (or "v3 or later") fork and manage to kill development of the original. As long as the project remains under "v2 or later", anti-DRM, etc. clauses are trivial to bypass by saying "I'm distributing under GPLv2, as allowed by project license". It's not about conspiracy theories, etc. - that's simply how "or later" part of license is written.

I'm not sure I follow this argument - unless you're somehow postulating that the people doing your v2 only fork can relicense the code, I'd get it under the "v2 or later" clause, too, which means that they can apply their DRM, but when they distribute it to me I can request the source and appropriate keys under the anti-DRM clauses of the GPLv3.

So there are two possibilities: pressure authors of the original to relicense under v3/v3-or-later *OR* fork, relicense the fork that way yourself and try to make the original branch wither.

Now, put yourself in position of people who do not want to drop v2. They are going to realize that v3 fork is coming. Moreover, that fork will be able to pick their improvements, but not the other way round. About the only response other than "give up" is "curse, accept that v2-or-later is not sustainable anymore and start protecting new code with v2-only". And that's exactly what we are starting to see. And will see more as more people see the writing on the wall and decide to do something about that.

You're making an awful lot of noise about relicensing code left right and center, but you're ignoring something quite important: only the owner of the copyright on a piece of code can change the license on that code. That means that some random person coming along and creating a fork of a project under the "GPLv2 or later" license has to stick to that license on every line of code in that tree, except the stuff they write themselves. And if a person or a group is able to relicense a body of code, they own that code, and they have every right to do whatever they want with it, including taking it closed source, proprietary, and charging people millions of dollars a seat. They can put the code they write themselves under whatever license they want, whether it's a patch to some GPLv2, v3, or v20 code, but they can't simply change the terms of the original license grant from "GPLv2 or later" to "GPLv2 only" or GPLv3 only", and without that license change the only issue is the license on their modifications.

If a project starts to accept major changes under a GPLv3 only license then your horror story of a v3 only fork may be possible, but only if that fork either convinces other contributors to release their code to it under a v3 only license, or if they replace the code that's still 'tainted' with the v2 grant; likewise for a v2 only fork. But frankly, that's the project lead's own stupid fault for not taking sensible precautions about license compatibility, and it's not something to make such a big song and dance about

himi

every other major copyleft forces you to allow later license versions

Posted Oct 4, 2006 11:22 UTC (Wed) by viro (subscriber, #7872) [Link] (1 responses)

Read GPL. "you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation". In other words, to distribute a work under
"v2 or later" it is enough to comply with GPLv2 alone. So if
recepients demand something you would have to provide under v3
but not under v2 and you refuse, there's nothing they can legally
do. Please, read section 9 and understand it. BTW, ask stevenj
to explain it - perhaps he'll do that better. He does understand
what it means, judging by his postings in this thread.

The rest of your points is based on that misunderstanding of how
"v2 or later" works, AFAICS...

every other major copyleft forces you to allow later license versions

Posted Oct 5, 2006 4:01 UTC (Thu) by himi (subscriber, #340) [Link]

Okay, I see the line of reasoning there, and if it's legally valid (which I'd like to hear from a lawyer) then it's a rather ridiculous loophole in the license which could probably only be fixed with a /forced/ upgrade clause.

However, it doesn't affect any of my other arguments - the /recipient/ of the code is still receiving it under the "any later version" language in clause 9, and hence /they/ can choose to act under either v2 or v3; they also /must/ pass the same rights along to any future recipients of the code. So, without actual relicensing happening v2-only or v3-only forks aren't possible except as I outlined - when /new code/ is written under either license exclusively. And that's within the rights of the authors, both legally /and/ morally, isn't it?

himi

every other major copyleft forces you to allow later license versions

Posted Oct 4, 2006 11:56 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (1 responses)

So for any pool of code under GPLv2-or-later, we now have the possibility of two forms of parasitic forking :
- GPLv2 only
- GPLv3 only

GPLv2-or-later is a no-go now for DRM proponents because of the GPLv3 forking potential, and it's a no go for DRM oponents because of the impossibility to enforce GPLv3 terms. Both camps agree on killing it.

The first fork option is offensive to people who have contributed believing in the FSF ideals, and expecting a GPLv3 someday should the GPLv2 prove insufficient to enforce them. The second one is offensive to those who have contributed based on a careful analysis of GPLv2 terms, and how they could workaround FSF ideals while complying with the GPLv2. Both forks can be taken as a betrayal.

So we have a polarization. We have hostile forks. It's easy to blame the FSF and the GPL v3 process for it.

The root cause however is the people who managed to dissocate the GPLv2 wording from the GPLv2 original intent by building "clever" business models. They knew perfectly well then they were sitting on the wishes of some GPLv2 contributors. Their actions were divisive, and their natural result (GPL update and pressure to drop the GPLv2) should have been obvious to everyone.

The free software community will have to choose sides now. Including all the people who didn't care one way or another. But make no mistake, GPLv2-only is not the neutral choice. It ceased being so once people mixed software patents and DRM in the software distribution process. That's when the community consensus was broken.

Baldrick, have you no idea what irony is?

Posted Oct 10, 2006 16:35 UTC (Tue) by robilad (guest, #27163) [Link]

"Yeah! Its like goldy and bronzy, only its made of iron."

I think it's very funny to hear Linux kernel devs calling GPLd forks of existing code bases 'parasitic', when the Linux kernel itself contains a not so insignificant amount of BSD licensed code.

I guess one man's 'parasite' is the same man's 'liberator of too liberally licensed code', depending on which end of the leaching^W merging chain he stands.

Busy busy busybox

Posted Oct 2, 2006 1:49 UTC (Mon) by sepreece (guest, #19270) [Link] (7 responses)

"BusyBox will be GPLv2 only starting with the next release. It is generally accepted that stripping out the "or any later version" is legally defensible, and that the merging of other GPLv2-only code will force that issue in any case."

I'm curious about exactly what this means. My assumption has been that you can't alter the language of the license provided in a file by the copyright owner, but you can choose the license that applies to "the work" as a whole.

That is, you could ADD a statement at the beginning of each file saying that it is released under GPLv2 only, but you couldn't remove the notice further down in the file that says it's under "GPLv2 or later". Doesn't "keep intact all notices" mean they have to remain unaltered?

Is that what is proposed here, or is there an argument for allowing removal of the original terms? Could somebody point at it?

Busy busy busybox

Posted Oct 2, 2006 4:05 UTC (Mon) by bug1 (guest, #7097) [Link] (2 responses)

In Rob's post he states that the SFLC advised that "... a strict reading of the GPLv2 apparently requires preserving old license notices even when they don't apply ..."

I believe that if a file is currently is GPLv2 or later, for example.

And you add a GPLv2 only patch you would have to make it

Its the same with BSD, if you use GPL compatable BSD code you still need to mention the BSD licence and copyright.

For a file to be distributable it has to comply with all licences, its not dual licenced where you can pick any one of them.

I never understood what the big deal was about mentioning both, if the new project leader goes down the same path as Rob then i suspect the problems that lead him to resign will not have been adressed.

Disclaimer: IANAL and was involved in this mess, i had emailed SFLC about this myself (CC'ed Rob and Bruce) and recieved no response from SFLC.

Busy busy busybox

Posted Oct 2, 2006 19:38 UTC (Mon) by landley (guest, #6789) [Link] (1 responses)

The problem that led me to resign was simply that it was no fun anymore.
The licensing debate was already over (and Denis is continuing the GPLv2
only policy for the next release). I saw that through, and it's done.
The wording of the notices is a silly technicality that has no real
impact: new releases (and the individual files in them) are GPLv2. If
you want to use code under GPLv3, you can grab any of the old releases.

Partly I was exhausted. Partly I was disgusted at Bruce taking credit
for my work. But mostly? It just stopped being fun.

Rob

Busy busy busybox

Posted Oct 4, 2006 8:17 UTC (Wed) by BrucePerens (guest, #2510) [Link]

Well, I'm sorry that you decided to walk off of the project, but having walked off of projects myself, I understand and hope you get a rest.

I was distressed that you wrote about "seeing my laughing face when you looked at the code". I am not laughing at you. I didn't think of this dispute as a personal thing, just proper license procedure and the future potential of the program.

You also wrote that I did not invent the multi-call binary technique. I didn't claim to. But it doesn't come from gzip. I started working with C and Unix in 1981 at the NYIT Computer Graphics Lab, and the technique was in use at that time. My original work on Busybox was to provide 35 commands, mostly written by me, working from the Debian man pages.

Bruce

Busy busy busybox

Posted Oct 2, 2006 18:44 UTC (Mon) by tjc (guest, #137) [Link] (3 responses)

Beyond the licensing issue, I'm not clear on how one could accurately identify and seperate code that 's been contributed and "assimilated" into the codebase. Most code eventually gets refactored, and after this has been done, what then? There are two possible senarios:

1) After code has been refactored, then it's no longer part of the original contribution, and the contributors copyright claims are no longer valid.

2) The contributors copyright remains valid after the code has been refactored, and the codebase is forever tainted, since the original contribution can no longer be accurately identified and extracted.

Most license infractions that are settled in court involve code that's been blatantly copied over from one program to another and remains largely unchanged. It's unsettling to think of what might happen if a court takes up the job of deciding what to do about code that's been refactored.

Busy busy busybox

Posted Oct 2, 2006 19:51 UTC (Mon) by landley (guest, #6789) [Link] (2 responses)

3) You use a legal-grade tool like comparator that strips out whitespace
and brackets when checking for similarity, and is not confused by code
reordering.

4) You manually inspect every line of the code to discern refactoring
from actual rewriting, with an eye towards "scenes a faire" and the
smallest copyrightable expression not to fall under fair use within your
jurisdiction (yeah, copyright is federal, but which circuit court?).
Note that book titles are explicitly not copyrightable, and the smallest
legally recognized copyrightable expression in poetry seems to be haiku,
something which Apple has taken advantage of in its protocols:
http://sree.kotay.com/2006/02/legal-security-ocp-and-appl...

Comparator also defaults to "3 lines" as its smallest actionable hit, and
there's a reason for this.

Anyway, by-hand comparison is much easier when you have a single known
source of contamination that you can compare against, and if it isn't in
that source it isn't what you're looking for. So you don't have to
actually track multiple upstream sources, just eliminate _one_. Plus, a
lot of familiarity with the codebase helps (this file was rewritten from
scratch in this svn checkin, so no earlier claims can apply).

Hence four-stage forensic analysis, which may have been overkill but
should definitely have been _sufficient_. Unfortunately, Bruce was
trying to make moral arguments, not legal ones.

Rob

Busy busy busybox

Posted Oct 2, 2006 20:20 UTC (Mon) by tjc (guest, #137) [Link]

I read your rational page on forensic analysis, and the comparator man page, and I think I understand your methodology. But I'm still not sure about the larger legal implications of refactoring code.

My working premise is this: if code is refactored (into "chunks" of whatever size is required by law), then what started out as "expression of concept" has to been reduced to the concept itself, and as such is no longer bound by copyright law, but is instead the subject of patent law.

So assuming that I have this right, then in this particular case -- if Bruce's code was correctly identified and sufficiently refactored -- then his copyright claims would no longer be valid. This still leaves open the possibility of patent claims for the underlying concepts, but that does not seem to be an issue in this case.

Yes? No? Maybe...?

Busy busy busybox

Posted Oct 4, 2006 19:45 UTC (Wed) by tjc (guest, #137) [Link]

4) You manually inspect every line of the code to discern refactoring from actual rewriting, [snip]

What is the difference between refactoring and rewriting?

why did RMS decide not to honor his commitment to "do no harm?

Posted Oct 2, 2006 4:33 UTC (Mon) by shieldsd (guest, #20198) [Link] (16 responses)

This BusyBox business is just one more sign of the abyss we are facing. We all know Linus was heavily tied to GPL2. And RMS promised to "do no harm" per section 1.3 of the process document; so the proper approach would have been for RMS and Linus to work together in a series of license "patches" to avoid the possibility of forking; that is, refine the license in the same way as the code is developed. This would have allowed full community participation at every step.

Yet RMS decided to pull ahead on his own and added the DRM provisions. This made forking almost inevitable, which means we are going to see more projects forking. Each such fork will divert developer resources needlessly, thus slowing the rate at which the kernel and associated software packages can grow.

It's a shame, and it could have been avoided.

I've some more thoughts on this at my blog: http://daveshields.wordpress.com
thanks

Who is doing harm here?

Posted Oct 2, 2006 5:05 UTC (Mon) by atai (subscriber, #10977) [Link] (14 responses)

The GPL v3 process is open (and open to all). Linus has his avenue of commenting, like anyone else. Instead all these "mine" not accommodated, not at "my" convenience, not letting "me" seeing the first draft first, etc. (where me, mine, my is Torvalds) Who is really doing harm here?

There is an year for making comments. Yet Torvalds just sit there without adding his comments. And he said others know his email address. Is it hard for him to add some text to a web form? Instead he flames with PJ and makes silly statements to the press. Making a whole paragraph belittling the FSF over a simple clarification. He shows no willingness of direct communication and it is either Linus' way or the highway.

The FSF has shown more maturity in the process than Linus show. Linus is, honestly, behaving childishly.

Who is doing harm here?

Posted Oct 2, 2006 6:05 UTC (Mon) by jzb (editor, #7867) [Link] (7 responses)

I have to disagree here. I belive Linus' point, or at least one of them, is "who wanted the GPLv3 in
the first place?" Participating in the GPLv3 process is essentially saying "ok, I've decided to let the
FSF set the terms of the debate and the new license, and will simply be content to quibble over the
particulars of the framework that has been handed down by RMS." I am not at all surprised that
Linus, and other interested parties, have opted to sit out the GPLv3 process when it was never
established that these people wanted the license revised in the first place.

Who is doing harm here?

Posted Oct 2, 2006 7:09 UTC (Mon) by khim (subscriber, #9252) [Link]

They were involved in discussion from the moment when Linus said I think it's insane to require people to make their private signing keys available. But it was just some internal discussion so it's Ok. While kernel guys sat out and just ignored GPLv3 - I was content. It's their right.

But when they are starting to play politics - they are clearly involved and then the question arises: why have you ignored everything when you were asked but when process is nearing finish you are raising tempest ? Sorry guys - if you want to discuss do it in the proper way. If you want patch to be included in linux kernel - you sent it on LKML, not publish it on corporate website and then complain that "this @%#!@^&*#!#@ Linus just refuses to grab our wonderfull creation - and he knows where our web site it".

Who is doing harm here?

Posted Oct 2, 2006 7:46 UTC (Mon) by atai (subscriber, #10977) [Link] (5 responses)

OK, if Linus never wants v3, then fine. Just say Linux is GPL v2 forever and be done with it.

There are people who want GPL v3. There are people who want the DRM threat addressed. There are people who want the ASP loophole closed. There are people who want better license compatibility. The kernel developers may think GPL v2 is fine for them, but they do not consider the needs of the people caring about the ASP scenario, for example.

Linus is now attacking the GPL v3 beyond what he wants to do with the kernel (staying with v2). He can just ignore the GPL v3, but the recent open letter from the kernel developers and Linus's statements make you wonder if he is trying to derail the use of GPL v3 outside his project in general. And he seems happy playing this role (due to his personal hatred toward RMS?)

Who is doing harm here?

Posted Oct 2, 2006 8:34 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

you want greater license compatability by creating a license that's incompatable with all the existing GPLv2 code???!!?!?!?

you are asuuming that all the people who licensed code as GPLv2 or later are going to be willing to change that to GPLv3 or later.

if they want to stick to the GPLv2 or later then they have to live with the license compatability limitations of GPLv2

as documented elsewhere in this thread, this opens the possibility of a three way fork of a project

fork 1
GPLv2 only
fork 2
GPLv3 either only, or 'or later'
fork 3
GPLv2 or later

with these three forks the only code 'shareing' that could be done is that fork 2 could get code from fork3. any other shareing would involve the author needing to authorize a license change.

yes fork2 can also take code from projects with more licenses, but those other projects can't take code back from the GPLv3 project without changeing the license of their own code (and if they wanted to do that they could anyway, without needing this 'compatable GPLv3 license' simply by relicensing their code

so exactly how is this 'improved license compatability' supposed to improve code shareing between projects? everything looks one-way to me.

Who is doing harm here?

Posted Oct 2, 2006 20:44 UTC (Mon) by stevenj (guest, #421) [Link]

you want greater license compatability by creating a license that's incompatable with all the existing GPLv2 code???!!?!?!?

The poster was obviously referring to section 7 of the GPLv3, which makes the new GPL compatible with more licenses than the old GPL, most notably the new Apache license.

Anyone who made their code "v2 only" knew that they would be incompatible with future GPL versions, just as GPLv2 was incompatible with GPLv1. I fail to see how you can criticize the FSF for something that was impossible to avoid without freezing the GPL forever at v2.

And the history of free software is rife with FUD about forking that hasn't lived up to reality (even with licenses like LGPL that theoretically allow legally incompatible forks). Malign forking doesn't happen (in the FLOSS world at least) unless the project already has serious problems unrelated to licensing.

Who is doing harm here?

Posted Oct 2, 2006 21:09 UTC (Mon) by stevenj (guest, #421) [Link]

with these three forks the only code 'shareing' that could be done is that fork 2 could get code from fork3. any other shareing would involve the author needing to authorize a license change.

By the way, your conclusion is false on the facts. The only code that could not be legally combined in your hypothetical example is that fork 1 ("v2 only") could not share code with fork 2 ("v3 or later"). It would be perfectly legal to combine code from fork 1 ("v2 only") and fork 3 ("v2 or later") or from fork 2 ("v3 or later") and fork 3 ("v2 or later"). There might be social obstacles, but there are no legal obstacles (no legal authorization from the authors is required).

Any any hypothetical project whose developers are so divided that they undergo a triple fork has more problems than just licensing.

Who is doing harm here?

Posted Oct 2, 2006 11:36 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

>say Linux is GPL v2 forever and be done with it.

If "done" were possible.
Above the specific food fight about DRM is a higher level issue: the right of dissenting opinions to exist.
Historically, a big part of the genius of RMS has been his unwillingness to compromise.
When the conversation was pure software, this refusal to compromise got FOSS where it is today. No way of telling whether *BSDs, on their own, would have achieved sufficient mass to get past the novelty stage. The Linux kernel has propelled an ecosystem.
Now that the conversation crosses the hardware/software line, it is less clear whether the uncompromising approach is a feature or a bug.
Given the stakes, I'm glad that the debate is as spirited as we've seen. Not sure if the uncompromising approach is best here, but I can tell you one corner rejoicing at the dissent is that of Redmond.

Who is doing harm here?

Posted Oct 2, 2006 19:57 UTC (Mon) by landley (guest, #6789) [Link]

> OK, if Linus never wants v3, then fine. Just say Linux is GPL v2
> forever and be done with it.

Friday, September 8, 2000 was six years ago:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0009.1/0096...

That predates the entire GPLv3 debate by a lot, and it isn't Linus who's
refusing to accept that as "done with it".

Who is doing harm here?

Posted Oct 2, 2006 7:15 UTC (Mon) by error27 (guest, #8346) [Link] (5 responses)

PJ is a nice person, but she's also wrong. GPLv3 sucks.

I don't see how the FSF can keep claiming that Linus hasn't explained his objections clearly. He may not have gone through all the formal process, but they must be vegitative to claim he isn't communicating his thoughts. You seem to be implying that the FSF has no one on staff who can access the internet and read.

Personally, I don't like the optional web clauses in the GPLv3. The Gnu FDL has the same optional stuff where you never know what you're getting. It caused real problems for Debian.

There may be other things that suck with the GPLv3. I'm not very familiar with it yet. How do busy box rules affect Tivo DRM, for example? TiVO DRM is at a lower level so it shouldn't matter.

Who is doing harm here?

Posted Oct 2, 2006 8:34 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

They must be vegitative to claim he isn't communicating his thoughts.

Sorry, but he's not. First Linus claims that GPLv3 restricts the "use". FSF explains that it's not so: you are free to use (== compile and run) GPLv3 code. Linus says that it's not "use" normal people are talking about - it's "use in other projects" he's concerned with. FSF retorts that GPLv1 and GPLv2 always restricted such "use" and this is what Linus itself praising in GPLv2 ! Linus then start to talk gibbegish and claim that semantic is not important and intent is important.

Thus no, Linus never explained what he does not like about GPLv3 clearly - he finds new and new ways to change his position over time...

At least this text is readable - but it's hardly acceptable: it still does not explain why the "freedom to take everything, add extenstions and sell binary blobs" (aka "BSD license") is bad while "freedom to sell binary blobs with corresponding code which is useless without the hardware to run in on" is essential. Or why they think "while we may argue forcefully for our political opinions, we may not suborn or coerce others to go along with them" - this is what linux developers are doing, after all (if you listen to SCO then you'll know that "tit for tat" enforced by GPLv2 is also "political opinion").

GPLv3 does not forbid DRM. It does not even force to stop using GPLv3 code in system with DRM (after all DRM scheme can be implemented in seperate domain - and it's actually the only way to make it work). Additional restrictions is no better and no worse then LGPL - and LGPL is important license to have. Patents... Patents are discussed with IBM (the biggest paten holder of them all!) and if IBM will be satisfied (big if, but at least IBM is working on that and not starting political campaign), then how kernel developers can claim that it's a problem ?

In short: it looks like Linus and kernel developers are intentionally choose the ways of communication which can be used to "poke" FSF and then go away thus avoiding any constructive discussion. Was it because they don't have time to defend their position or have they no arguments to actually defent it ? We'll see...

Who is doing harm here?

Posted Oct 2, 2006 11:51 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link]

>Linus and kernel developers are intentionally choose the ways of communication which can be used to "poke" FSF and then go away thus avoiding any constructive discussion.

Yes, the Discussion Rights Management is every bit as contentious as the DRM of the GPLv3.
<weasel word warning>
The various LKML threads seem to imply that the substantial decisions about the GPLv3 may have been made before the public discussion period on the style of the document ever started.
</weasel word warning>
If the LKML community doesn't trust the FSF, then why is it a surprise that the kernel devs would express themselves on friendly territory?

Who is doing harm here?

Posted Oct 3, 2006 22:50 UTC (Tue) by man_ls (guest, #15091) [Link] (2 responses)

In short: it looks like Linus and kernel developers are intentionally choose the ways of communication which can be used to "poke" FSF and then go away thus avoiding any constructive discussion.

Indeed. Just as they complained that the FSF had already decided the contents of GPLv3 before starting the public consultation, it seems that kernel devs had already decided their opposition before seeing the first draft. It is not surprising, since they were already sticking to GPLv2 since the beginning. It almost seems like they want to retroactively be right: first they said: "I want to stick to GPLv2", now they are saying: "see? We was right to stick to v2, GPLv3 sucks".

Meanwhile Linus was playing the prima donna complaining that

"Eben [Moglen] said he was willing to go over the draft point-for-point after it was published, but not apparently willing to let me read it in the comfort of my own home and send comments back. So, the GPLv3 process couldn't apparently accommodate me, or I couldn't accommodate them."

Why did he need to go first? Linus could certainly read the draft in the comfort of his own home after it was published; we all did. Of course we are not the leader of (arguably) the most important libre software project out there, but then he was talking to the lawyer of the guy who has (and I quote Ingo Molnar freely) "unprecedented legal power over 350 million lines of code" (conservatively estimated). I would expect a bit of humbleness from him. Well, what do I know.

Was it because they don't have time to defend their position or have they no arguments to actually defent it ? We'll see...

Ingo Molnar is displaying a lot of patience, and also spending a lot of time defending the position of the most prominent kernel devs'. He also has a lot of arguments, but so far they are not very convincing, not for me at least. They shift too much.

Who is doing harm here?

Posted Oct 5, 2006 12:58 UTC (Thu) by wookey (guest, #5501) [Link] (1 responses)

Indeed. I would like to commend Ingo and stevenj for their contributions to this thread, which have clarified a number of things for me at least. The whole thing has been pretty civil as these things go. I do now at least understand a bit of why the kernel devs are so grumpy.

But I do not find myself convinced by their arguments, and agree with stevenj that the fears of forking, 'legal strongarming', and 'acting with legal but not moral authority' are overblown.

Nevertheless, Jon Corbet put it well (as ever) in the original article. This debate _is_ causing strife, and there is thus quite a lot to be said for a v3 that only has the uncontentious stuff in it. That would be a pity - the FSF are the ones who are being consistent and 'in the spirit of', and the kernel devs who are being awkward (IMHO), but it is quite finely balanced as to which course would be better in the long term.

We certainly won't be able to say that the issues have not been discussed fully at the end of it all, whatever happens - and that of course, is a good thing - tiresome as it might seem right now.

So, to re-iterate. Thank you for those making an effort to dicuss the substnative issues (which is nearly everyone here). It is appreciated.

Who is doing harm here?

Posted Oct 9, 2006 17:01 UTC (Mon) by malor (guest, #2973) [Link]

In my opinion, the difference is that the FSF is thinking about freedom in a multi-generational timeframe, and the kernel devs want success/market dominance *right now*. And they appear willing to trade off freedom to get it.

If you think about it from the perspective of tens or hundreds of years, Linux is not that important; it's essentially the early scaffolding for a great cathedral of code. But, unlike the real multi-hundred-year cathedral projects, I don't think these scaffold builders are even aware that a cathedral will ever exist.

The FSF is right not to bend on this issue; if we want truly free computers, it's incredibly important. Eventually, GPLv3 code will be such an overwhelming presence that it would be insane to try to compete with it in any but the smallest niches.

If, however, the foundation is flawed, the cathedral may collapse. The architect has identified flaws in the design, and is redrawing the blueprints. The scaffold builders are upset about this. Either the cathedral won't look quite how they thought, or they think their project IS the cathedral.

The most popular free kernel, a hundred years from now, may even be called Linux, but it will be related to today's kernel only in the sense that modern man is related to the chimpanzee. But the GPLv3 may very well still be in force. Law, especially good law, lasts a LOT longer than code.

why did RMS decide not to honor his commitment to "do no harm?

Posted Oct 2, 2006 5:24 UTC (Mon) by khim (subscriber, #9252) [Link]

It's a shame, and it could have been avoided if "patch" will only be included when all interested parties agree.

Sorry, but this will never happen. "All interested parties" will never agree because any change will bring objections from someone.

And that's not how Linux kernel development works and you know it: what Linus said goes. If we have two USB stacks but Linus does not like them both - then USB stack written by Linus is included in kernel. No consensus. And the result is that some projects (especially embedded ones) are using 2.4 kernel still - because they disagree with changes introduced in 2.6 process. Sounds familiar ? Yup. Because it is.

Yet RMS decided to pull ahead on his own and added the DRM provisions.

...just like Linux wrote his own version of USB stack when he was unsatisfied by existion ones. Yup. RMS took a look on TiVo and found out that a user who needs changes in the system is no longer free to make them himself, or hire any available programmer or company to make them for him and since it was the deal from the very start he decided to fix it. Linus claims that this crusage is not important and we shuld keep "tit-for-tat" principle embedded in GPLv2. The problem is: GPLv2 was never about "tit-for-tat" (Google, IBM or even "evil empire" Microsoft got to keep changes private as long as they keep binaries private). And the FSF was never about "tit-for-tat" - they clearly explained what the goal is many years ago.

Busy busy busybox

Posted Oct 2, 2006 10:01 UTC (Mon) by drag (guest, #31333) [Link] (11 responses)

As for the trustfullness of FSF and such..

Simon Phipps (Chief Open Source Officer at Sun Microsystems of CDDL fame) has http://blogs.sun.com/webmink/date/20060924 on the GPLv3 licensing review process.
Apparently his viewpoint contradicts the viewpoints of some certain internet celebraties' comments on the GPLv3 and FSF we've been hearing about lately.

I've been following the GPL v3 process since it started, and despite a certain amount of initial scepticism I'm pretty impressed. Eben Moglen in particular has shown himself to be a statesman and a scholar and the GPL v3 review process is no hollow plebiscite. The FSF team has engaged, listened and responded to all the comments they have received, and the draft 2 text shows great improvement over the draft 1 text, especially concerning the stance on DRM.

I have a growing confidence that what will appear from the process after another 3 drafts could well form the basis of a unification of the Free and Open Source software communities. The compatibility mechanism created by section 7 is brilliant, and what was initially cold-war-era posturing on patents and DRM is evolving well into balanced approaches to handling both issues. There's certainly more progress needed - the patent language is still too imbalanced against large portfolio holders, for example. But the track record to date shows that the goal is reachable if everyone engages positively.

Which of course raises the question: if I can see that, if others like Luis, Dalibor and Mark can see it, why can't the kernel developers see it?

Thought it was interesting. Food for thought.

Busy busy busybox

Posted Oct 2, 2006 11:29 UTC (Mon) by bertdouglas (guest, #29228) [Link] (1 responses)

The interests of Sun are surely not aligned with those of individual software developers.

Busy busy busybox

Posted Oct 2, 2006 18:36 UTC (Mon) by drag (guest, #31333) [Link]

"The interests of Sun are surely not aligned with those of individual software developers."

Neither are the Linux developer's. The principal reason behind the hate for the DRM restrictions in the GPLv3 is because of the impact it may have on businesses that wish to use Linux code in 'user proof' devices.

Personally I would prefer developers to be alinged with the needs of their individual end users. ;-)

Busy busy busybox

Posted Oct 2, 2006 18:37 UTC (Mon) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (8 responses)

So you are expecting Sun to relicense Solaris 10 under GPLv3?

Paul E. McKenney (my opinions, not necessarily those of my employer -- though given that this is a simple question, this disclaimer seems a bit redundant)

Sun, OpenSolaris and GPLv3

Posted Oct 2, 2006 20:14 UTC (Mon) by GreyWizard (guest, #1026) [Link] (1 responses)

http://blogs.sun.com/jonathan/entry/hp_and_sun_partnering...

"We also recognize that diversity and choice are important - which is why we've begun looking at the possibility of releasing Solaris (and potentially the entire Solaris Enterprise System), under dual open source licenses. CDDL (which allows customer IP to safely comingle with Solaris source code) and under the Free Software Foundation's GPL3."

This doesn't mean they will but they are clearly considering that.

Sun, OpenSolaris and GPLv3

Posted Oct 2, 2006 21:32 UTC (Mon) by PaulMcKenney (✭ supporter ✭, #9624) [Link]

Thank you for the pointer! I had missed this.

Busy busy busybox

Posted Oct 2, 2006 20:38 UTC (Mon) by drag (guest, #31333) [Link]

No, not realy.

Sun doesn't have a problem with people using their code in binaries. For instance: kernel drivers. That is something that wouldn't work out to well under the GPL. Same thing with Java stuff.

They may do a permissive version of the GPLv3 so it operates in a similar fasion to the LGPL, but I still think that is unlikely. Just less unlikely.

What I am curious about right now, personally, is what remaining compatability issues would be between the CDDL and the current GPLv3 draft.

For instance one of the big reasons for the CDDL is the patent language. Sun wanted to make sure that when people used CDDL code that they would be protected from persecution by Sun for their hefty patent portfolio in regards to the code itself. So in a way the GPLv3's patent language is actually very _business_friendly_. (keeping in mind that the vast majority of businesses are small or medium sized and lack the resources to gather patent portfolios of their own).

This was a big deal between GPLv2 and CDDL license compatability.

Now I am curious about the compatability between the GPLv3 draft and the CDDL patent language, and any other incompatabilities.

I think that if the GPLv3 works out and if there are remaining compatability issues that Sun will actually want to make a CDDLv2 so that the GPLv3 will be compatable.

That way they don't have to worry about their 'IP' being sucked back into 'Linux kernel' (since GPLv3 is not going to be GPLv2 compatable) and it would encourage all those 'GPLv2 and newer' folks (which the majority of them are) to think very strongly about supporting Solaris as a primary target.

Then on the "Free software" side of things they gain indemification against a large number of patents by way of incorporating CDDL code in snippets back into projects and they gain extra encouragement for adoption of GPLv3. (If Sun likes it, then what would be the objection?)

Seeing how Ubuntu is alinged with Sun and Sun's willingness to discuss legal issues with Debian face to face... It would be interesting to see what sort of impact it would make in the 'linux community' if Debian was to release 'GNU/Solaris Debian' as a official port.

So you get this all of a sudden:
A kernel with no legal issues concerning binary drivers
Native Dtrace support
Stable internal ABI which would pretty much eliminate kernel update headaches.
ZFS support.
Compatable with propriatory Linux applications.

In a 100% GPLv3 compatable package.

Personally I feel that propriatory drivers are bad (Linux devs should be a bit more pro-active in this manner), but stable ABI is good (for the sake of end user's sanity rather then for technical reasons). As for ZFS and Dtrace, I don't care about ZFS, but Dtrace is nice. I like the Linux kernel and have no experiance with Solaris.

But for other people I think this move would garner a large amount of attention and support for Sun and for Solaris.

Busy busy busybox

Posted Oct 2, 2006 21:17 UTC (Mon) by landley (guest, #6789) [Link] (4 responses)

Everybody's expecting Sun to relicense Solaris under GPLv3. They
desperately want a license that's incompatible with the Linux kernel, but
otherwise widely used. They invented CDDL for this purpose but nobody
else bit. GPLv3 is tailor-made for their purposes.

Busy busy busybox

Posted Oct 2, 2006 21:29 UTC (Mon) by alexbk (subscriber, #37839) [Link] (3 responses)

Wouldn't Linux kernel then be... a little less relevant, with Solaris-based Ubuntu and Debian, for a
start?

Busy busy busybox

Posted Oct 2, 2006 22:37 UTC (Mon) by drag (guest, #31333) [Link] (2 responses)

It can ultimately be very good or very bad for Linux kernel. Solaris kernel makes a nice counterpoint or foil against Linux development.

The Linux devs (not all of them, obviously) argue things like:
Having a stable kernel release is not important.
Maintaining driver compatability is not important.
Having internal trace'ng and performance evaluation for production kernels are not important (thinking of dtrace)
having a volitile kernel development model is important for rapid technical progression of your operating system.

Meanwhile you have a whole group of people saying how wrong the kernel developers are.

IF (big if) the CDDL ends up compatable with GPLv3, or Sun dual licenses it or whatever then with Solaris they (the Linux kernel naysayers) automaticly get all the stuff that they've been bitching about being missing. Hopefully then they'll leave the Linux developers alone! Then in a couple years it will be obvious on weither or not the Linux developers are realy realy right in their stances on these sort of kernel-related issues.

If the Linux kernel developers are right on these technical issues and all these hippy 'GNU/OpenSolaris' users will find that Linux-based systems will far outstrip them in capabilities, usability, and performance. The Linux devs are then heralded as technical wondermen that they are and will garner a lot more support. (Linus powns joo)

If the Linux kernel developers are wrong then it will be obvious that 'The Emperor has no clothes!' and they will loose a huge amount of credibility and support. But it would be termporary, they would release the Linux 3.0 kernel and address the technical and developmental limitations of 2.6 and life would go on. It would just be another mistake like Linus trying to fight smp support or Linux adopting bitkeeper as the versioning software of choice.

Either way it's win-win in the long term.

That is until... HURD TAKES THE WORLD BY STORM IN 2025!!!! YOU ALL WILL BE ASSIMILATED. RESTIANCE IS FUTILE! SURRENDER ALL COPYRIGHTS TO THE FSF!!! HAHAHAHAHAHAHAHA

Busy busy busybox

Posted Oct 3, 2006 0:47 UTC (Tue) by bojan (subscriber, #14302) [Link]

> HURD TAKES THE WORLD BY STORM IN 2025!!!!

You have a typo there. The year should be 2325. Sorry, it was too good to resist ;-)

Busy busy busybox

Posted Oct 7, 2006 4:50 UTC (Sat) by vonbrand (guest, #4458) [Link]

If the Linux kernel developers are right on these technical issues and all these hippy 'GNU/OpenSolaris' users will find that Linux-based systems will far outstrip them in capabilities, usability, and performance. The Linux devs are then heralded as technical wondermen that they are and will garner a lot more support.

No need. Linux had outstripped Solaris by Linux 2.2 or thereabouts. I know, we ran boxen with Solaris (they crawled along), and migrating over to Red Hat got them to fly.

Busy busy busybox

Posted Oct 2, 2006 14:29 UTC (Mon) by Sombrio (guest, #26942) [Link] (11 responses)

I think the GPLv3 is an awesome business opportunity. When the GPLv3 is finalized and put in to place, I plan to fork all current projects and keep them GPLv2. All of this code will then become the only code that business enterprises use, because there is absolutely no way a business is going to use GPLv3 code. Since the vast majority of open source code is now maintained and enhanced by paid coders, the GPLv3 code, and the FSF will fade into oblivion, and my forks of all the GPLv2 code will make me the new king of the hill. Excellent!!

I am, of course, just kidding. The real point is that Richard Stallman and the FSF have placed themselves on a path of self destruction. They are committing suicide, and can't be talked out of it, which makes them irrelevant. The community should just ignore them and go about our GPLv2 business. Once GPLv3 is finalized we just fork and move on. The FSF, and their social terrorism, is just a minor blip in software history, just like many fanatics before them.

Busy busy busybox

Posted Oct 2, 2006 15:40 UTC (Mon) by nix (subscriber, #2304) [Link] (10 responses)

People said that when the GPL came out, too.

They were wrong then, and you're wrong now.

Busy busy busybox

Posted Oct 2, 2006 17:07 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] (2 responses)

What you're missing is how much work that FSF has been doing to please corporate lawyers, as well as how much work they are doing to make GPLv3 work under legal systems other than the Anglo-American one.

Linus has one real objection: DRM. Everything else about GPLv3 is going to wind up as an improvement, particularly the patent language and the compatibility language. Many of the objections I've seen to GPLv3 other than to the DRM section are based on the fact that GPLv3 states clearly things that were already implied in GPLv2 (e.g. when you distribute a GPL program you are giving the recipients a license to use, modify, and distribute that program even if you have a patent that it infringes).

Perhaps the DRM dispute will be unbridgeable, but I think everything else can be solved.

Busy busy busybox

Posted Oct 2, 2006 18:42 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

No he doesn't just hate the DRM.

He hates the Patent language also.

He hates the increased license compatability. In fact if you make a diff between GPLv2 an GPLv3, then you'll see just about everything he hates about the GPLv3.

As you can see with the Bitkeeper debacle he has no problem putting restrictions on other kernel developers and has nothing against propriatory software, even if it's required to do kernel developer. "Best tools for the jobs" and that sort of tiing.

As far as he is concerned there is on point behind GPLv3 besides FSF/RMS 'attempting to hijack other people's code for their political ends' type things.

Busy busy busybox

Posted Oct 2, 2006 22:34 UTC (Mon) by cventers (guest, #31465) [Link]

> As far as he is concerned there is on point behind GPLv3 besides
> FSF/RMS 'attempting to hijack other people's code for their political
> ends' type things.

I wish to simply quote and emphasize this point because of how ridiculous
it is in light of the fact that the action FSF and RMS are taking that
Linus feels is a hijacking attempt is to update the Copyleft Free
Software license that _RMS invented_ and _Linus used_. He thinks that
since Linux is a big and important project using the GPL that RMS
shouldn't change his own license. But wouldn't that be an example of
Linux 'hijacking' the GPL?

Busy busy busybox

Posted Oct 2, 2006 19:04 UTC (Mon) by Sombrio (guest, #26942) [Link] (6 responses)

I certainly could be wrong, when I think about it I have to admit I am wrong quite a bit. I try to be right 10% of the time.

However, my gut feeling is that the GPLv3 is dangerous. Society has a way of weeding out fanatics. It is feasible that what we are actually witnessing right now is the end of the Open Source movement. In actual fact, you could be the one who is wrong. Some of the things RMS and Eben Moglen say these days make me cringe, and I am pretty mainstream, so I have to imagine that many are cringing with me.

I agree that history shows that the GPLv2 was brilliant and worked wonders. This fact has no bearing on the future. The acceptance of the GPL did have some chance to it. What if Linus had decided on some other license? The world today would be a different place.

It isn't infeasible that businesses return to proprietary closed source solutions in order to retain stability. Commercial interests are currently responsible for the majority of open source development today. If business loses interest in Open Source, then it will become irrelevant.

Trying to bring about social change with software is an interesting experiment. Nonetheless, it is an experiment, which means the outcome is unknown. We may not like what we learn from this experiment.

Busy busy busybox

Posted Oct 2, 2006 21:13 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

You seem to believe that Linus wrote the entirety of what you see on a
Linux desktop.

Not only isn't that true, but the kernel is comparatively `sterile'; it
has odd requirements because it runs in kernel space and must be
self-contained, so its code isn't particularly reusable in other projects.

If you want the kings of reuse, look at BSD stuff: if you want the
projects and organizations that have spawned most other projects, look to
the FSF and the GNU Project.

If Linus had decided to use some other license, we'd be using a different
kernel. Big deal. The GPL would *still* be massively widely used.

If business loses interest in Open Source, then, well, we go back to the
status quo pre-1999: development slows to some extent, but certainly
doesn't stop, and the concatenation of work on earlier work continues.

I think your choice of terminology is instructive. Business is not
important to free software. It may be important to the vaguely-defined
pragmatic `Open Source', but it is not to free software. The business
world largely ignored free software while its toolchain climbed to
pre-eminence in portability, and while its Ada tools (in particular)
annihilated most competitors without even trying especially hard (and yes,
I know that ACT is a business, but once upon a time they were just some
hackers at NYU, and if need be they could go back to that, although it
would be annoying). The business world largely ignored free software until
the userspaces of most Unixes looked so outdated in comparison that they
were laughable. Even now, KDE (for instance) gets comparatively little
commercial backing (SuSE and Trolltech are the only major commercial
backers), yet it's powering ahead.

Take your business-world goggles off. They're blinding you.

Busy busy busybox

Posted Oct 2, 2006 23:39 UTC (Mon) by Sombrio (guest, #26942) [Link]

Take your desktop goggles off, they are blinding you. Linux is irrelevant on the desktop where Windows is king and will be for quite some time yet.

Linux is king in embedded. That is where commercial interests are making big contributions and investments. Interestingly, that is also the domain RMS and the FSF are trying to tie down. Tivo is an embedded application. Embedded is also the domain that will abandon Linux if the fanatics have their way.

You are quite right that Linux will live on. It will just be a curiosity as opposed to a revolution.

I seem to have offended you and I apologize for that. This is not a religious issue for me. I am just an embedded developer who writes code to support my family. I have adjusted to Linux, and will adjust to whatever else comes along if Linux becomes unfriendly to the embedded device manufacturers. I am just standing on the sidelines, trying to keep up with the latest fads in embedded so that I can keep my job. Like 99% of the world, I don't give a damn what Tivo does as long as their box records Monday Night Football for me. I also don't believe in any DRM conspiracy theories. Having a great day with my kids, that is what is important. DRM concerns are just fluff.

Busy busy busybox

Posted Oct 2, 2006 23:59 UTC (Mon) by Sombrio (guest, #26942) [Link] (2 responses)

I am quite aware that Linux is just the kernel and that 90% of the code on a desktop is GNU. This is just another thing that bothers me about the fanatics. We have to call it GNU/Linux. Well, excuse me, but typing all of this on my phone is hard enough without having to call it GNU/Linux. I am sure you know how hard capital letters are on phone keyboards. Anyway, if you could do me the favor of assuming I mean GNU/Linux when I say Linux that would be a great help.

Busy busy busybox

Posted Oct 3, 2006 9:17 UTC (Tue) by ayeomans (guest, #1848) [Link] (1 responses)

I doubt 90% of any desktop code is GNU. David Wheeler's counts for Red Hat 7 showed around 65% as having GPL or LGPL licences. Not that this is all GNU code either - since the kernel, web browser, X, KDE are not GNU. For embedded systems using BusyBox, even binutils may not be present - I would expect glibc to be the only significant sized GNU code, and that's 1/4 the size of the kernel.

Busy busy busybox

Posted Oct 5, 2006 9:36 UTC (Thu) by nix (subscriber, #2304) [Link]

I'd expect embedded systems to be using uClibc, actually.

There's not much FSF-owned code on such systems (which makes the screaming from embedded devs even more peculiar).

Busy busy busybox

Posted Oct 2, 2006 21:31 UTC (Mon) by drag (guest, #31333) [Link]

You are assuming that the GPLv3 is more 'business unfriendly' then GPLv2.

I don't think that it is.
For instance the GPLv3:

* Patent liability protection. As a business you know you can use GPLv3 code and not risk being sued by people that contributed to that code. With the GPLv2 a corporation such as (evil, boo!) SCO could of snuck patent encrusted code into a GPL'd project. IBM won't hate it because it will help reasure their customers and it won't affect their ability to go after propriatory software vendors for patent infringment. Oracle and Microsoft will still have to be scared from IBM's patents.

* Increased compatability with licenses. You will have more opportunity to benifit from the diversity offered by the world of 'open source' by having a wider selection of software code to choose from then what is possible with the GPLv2.

As for the DRM provisions that is largly irrelevent to the vast majority of software and hardware vendors that support Linux systems. It is only going to affect people that want to use Linux systems and DRM encrusted hardware to make 'user proof' devices. And this is not going to realy affect them much anyways as the Linux kernel will almost never likely be ever to be GPLv3. For userland stuff it will still be legal to link DRM encrusted propriatory software with LGPL'd libs. And the Linux kernel be used to ensure that their 'protections' on these propriatory programs remain in place.

Bruce following ESR

Posted Oct 2, 2006 17:56 UTC (Mon) by bronson (subscriber, #4806) [Link] (3 responses)

Then entire open source community plonked ESR a few years ago. Let's see how long it takes Bruce to cause himself the same fate. :)

Bruce following ESR

Posted Oct 2, 2006 18:22 UTC (Mon) by landley (guest, #6789) [Link] (2 responses)

The difference is Eric's still coding.

http://www.catb.org/~esr/software.html

That page is actually out of date (for example he handed off fetchmail to
new maintainers years ago), but I know he's still actively working on
GPSD. In the past five years he's launched a half-dozen new projects, and
either handed them off to new maintainers (for example bogofilter) or
completed them (for example comparator, which was used in the SCO trial).
Plus he's written another New York Times bestseller (The Art of Unix
Programming). This isn't exactly resting on his laurels. (You don't hear
so much about him anymore because he doesn't travel as much anymore; he
got sick of it and went back to his computer to get some work done.)

Eric may be darn annoying at times, and lots of things he says may need to
be taken with a grain of salt, but he does still actually contribute new
and interesting things. And I'm unaware of him going back to any project
he worked on ten years ago (such as the infrastructure of what is now
ibiblio, or the emacs lisp library) and chewing them out for doing it
wrong without being willing to actually contribute anything new.

Bruce following ESR

Posted Oct 2, 2006 22:59 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

I use GPSD and enjoy the design of it.

Bruce Perens already followed ESR a while ago with his Desktop linux stuff being based on the 'next' Debian stable release... and being screwed over as the stable Debian release never materialized in a sane time frame.

The trouble with ESR is that his 'leaps of logic' aren't very logical. Bruce Perens is much more coherent.

Bruce following ESR

Posted Oct 7, 2006 15:01 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

Bruce claimed that Userlinux was ready to ship the moment Debian did. It turned out that this wasn't actually true - even if Debian had released six months or a year earlier, there's no evidence to suggest that Userlinux would actually have appeared anyway. Ubuntu ended up being many of the things that Userlinux was intended to be, and had successfully generated a technical community even before releasing the first version of their software. If you go back and look at the Userlinux mailing list archives, it's pretty clear that that wasn't happening for them.

Busy busy busybox

Posted Oct 2, 2006 18:00 UTC (Mon) by landley (guest, #6789) [Link] (1 responses)

No, the FSF wants to obtain copyrights to the projects it manages so it
has standing when it pursues enforcement actions. If the FSF is not a
copyright holder in a project, they don't have standing to sue somebody
for violating that project's copyrights. The ability to relicense is a
fringe benefit, and if they were willing to rely on it they wouldn't have
bothered with the "or later" language in their suggested permission grant
in the first place.

The SFLC just has some prominent copyright holders sign documents giving
them authority to represent them in license enforcement actions. This
means the SFLC has to take an extra step to establish standing in court,
but it's no big deal.

The main downside of the FSF policy is it's an incredible pain to get a
patch into something like gcc, because all first time contributors have to
sign a physical piece of paper for the FSF to keep on file. (You can't
actually transfer copyrights in the US without a written instrument of
conveyance, and in places like germany with author's rights, you can't
really transfer them at all.)

I don't buy that argument

Posted Oct 2, 2006 21:57 UTC (Mon) by dlang (guest, #313) [Link]

as soon as the FSF owns copyright on a portion of the project they can sue anyone who steals the project.

now if someone only steals a few lines of code and they don't have copyright on those lines they can't, that's true.

however, I've never heard of anyone sueing based on the GPL in such a case. every case I've heard about the offenders took the entire GPL program and used it. In this case you don't have to have copyright on every line to sue (the very sucessful gpl-violations team have been demonstrating this with the linux kernel and it's lack of copyright assignment)

all the FSF would have to do to be able to sue is to stay involved with the project so that as the project changes over time they would still be involved.

the only reason to require the copyright of every line of code is to have the legal right to change the license of that code.

Remember the other side

Posted Oct 2, 2006 19:19 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link] (4 responses)

There is a lot of discussion here about:
developers who agreed to the 'or later' clause being (potentially) angry about an (alleged) abuse of 'similar in spirit'.

No-one has mentioned the alternate case: the developers who didn't explicitly include 'or later', but are perfectly happy for the FSF to make the changes it has.

Stallman has a tendency to be right - and I am quite happy to release my own code under GPL v.3. In fact, I'd prefer an even stronger anti-DRM, anti-patent, anti-binary-module position.

There is one moral though: if you accept contributions from many people, you must either log in detail who contributed what, or they must assign copyright to you.

Remember the other side

Posted Oct 3, 2006 3:01 UTC (Tue) by alfille (subscriber, #1631) [Link] (3 responses)

Whether a developer likes the DRM provisions or what ever isn't truly the point.

We were told that the "or later" wording was to protect us in case there were legal problems with the current GPL v2 license. Fundemental changes may be covered, but they are a breach of trust.

An analogy: I sign a blank credit card receipt when I rent a car to cover damage/theft. Technically any charges made would be legal, but certainly not our tacit understanding.

The real problem is that we should have authorized GPL v2.x, not GPL v3

Paul Alfille

Remember the other side

Posted Oct 3, 2006 6:30 UTC (Tue) by walken (subscriber, #7089) [Link] (2 responses)

> We were told that the "or later" wording was to protect us in case there were legal problems with the current GPL v2 license.

But I think that *is* the case: if you agree with the idea that end users should be free to modify the software or hire someone to do so, which was the goal as documented in the gnu manifesto, then the locked-down tivo scenario IS a legal problem. The license is being updated to close that loophole, I dont think this is out of line with what the FSF said about the "or later" wording.

Remember the other side

Posted Oct 3, 2006 13:47 UTC (Tue) by alfille (subscriber, #1631) [Link] (1 responses)

Anti-DRM may be a logical extension of FSF ideals, but it isn't part of GPL v2.

As a developer, I'm more interested in seeing my code used, and seeing what new ideas and directions others take it in. GPL v2 covers that perfectly.

I had hoped that the "or later" really would just cover fixing language and tuning to current law, not extending philosophy.

Paul Alfille

Remember the other side

Posted Oct 4, 2006 9:02 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

If you want to criticise the FSF, write they are stubborn fools, not that they "breached trust". They've been nothing but consistent over the years, repeating again and again what their aims were and that the GPL was their tool to achieve them.

You may disagree with the FSF aims, but claiming surprise now is a bit rich.

Fact :
1. the FSF had announced the possibility of a GPL v2+ for years (that's why the "or later" clause is there after all)
2. the FSF aims and intent have always been well known (if anything RMS and the FSF have taken flack over the years for hammering them at every possible occasion)
3. you don't need to be a genius to understand an GPL v2+ could only harden the licensing terms, as a loosening would have been a lot of work for no win
4. in the last years Linus made a lot of noise (relayed and amplified in many media) about the "or later" implications
5. the GPLv3 review process has been going on for some time, so "discovering" the GPLv3 now is a bit rich (hell I've seen a PHB-oriented GPLv3 presentation months ago by people which had nothing to do with the FSF)

I can understand grumblings about the inconvenience of the FSF writing a GPLv3 now, but all the "how dare they write a GPLv3" really fly off the mark. One thing you can't accuse RMS and the FSF of is not being clear on their intent.

What people could legitimatelly complain at is the GPLv3 wording, and there is still room to amend/simplify it. Unfortunately it seems the fiercest GPLv3 bashers didn't even spend the time to analyse the GPLv3 text or propose alternatives, preferring to go into deep denial, and refering to third-party distorted accounts of the GPLv3 text.

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 1:53 UTC (Tue) by bojan (subscriber, #14302) [Link] (11 responses)

The GPLv3 v. GPLv2 debate is really shaping up to be a major "mind" fork in the FOSS community in a while. As I'm typing this, there have been 147 comments to this story, with hundreds more on similar topics in the last few weeks (and that's just LWN). And it's not just nobody's like myself commenting, but also important FOSS developers and people associated with FSF. WOW!

Both sides present some compelling arguments in relation to the DRM provisions of GPLv3. Patent issues appear to be more related to the unfortunate wording and appear fixable, but DRM stuff is likely to remain the forking point, as least for a while.

IMHO, it seems inevitable that DRM will find its way into devices playing whatever "content industry" makes. They are so bent on having this that no amount of convincing is likely to work. Too much new revenue at stake.

The most interesting questions (to me) remain these:

1. Can GPLv3 really stop DRM in numbers that matter?

2. Would staying with GPLv2 accelerate DRM adoption or not?

3. Are we about to witness a huge FOSS licensing split?

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 5:13 UTC (Tue) by svkelley (guest, #37299) [Link]

4. Will Gplv3 kill commercial embedded linux development? Windows CE definitely stands to benefit.

Sean V. Kelley

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 5:57 UTC (Tue) by eru (subscriber, #2753) [Link] (1 responses)

1. Can GPLv3 really stop DRM in numbers that matter?

Easy one. The answer is No. If GPL'ed software had a Microsoft-like market share, then it might have some effect, but as things now stand, those that want to create systems with DRM capabilities will simply base their designs on non-GPL3 software, of which there is no lack of.

2. Would staying with GPLv2 accelerate DRM adoption or not?

It would have no effect. I think the only thing that really can stop DRM is consumer reaction against it. As long as there is demand for DRM technology, there is no shortage of software writers willing to help provide it.

3. Are we about to witness a huge FOSS licensing split?

I hope there is still time to find common ground, otherwise this will be the biggest setback to F/OSS to ever happen.

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 15:33 UTC (Tue) by mingo (subscriber, #31122) [Link]

3. Are we about to witness a huge FOSS licensing split?

I hope there is still time to find common ground, otherwise this will be the biggest setback to F/OSS to ever happen.

I agree, and i hope so too. For example the patent language looks quite OK to me - patents are the "source code of ideas", so an extension of the Quid Pro Quo to that space looks obviously correct and are within the spirit of the GPLv2.

One problem spot is the DRM provisions which depart from the spirit of the GPLv2 by trying to control certain works created independently from our codebase - for example certain types of hardware. This "controlling of other works" is achieved by the GPLv3 by adding certain types of "keys" to the definition of "Source Code" - and hence forcing the release of them [or the ceasing of distribution] via the distribution clauses. (with tons of qualifications and exceptions all around to avoid known collateral damage. It's a real mess, and by far my biggest problem with the GPLv3 - and also the main worry of other kernel developers who have expressed negative opinion. See other posts in this thread for more details and for a rather lively discussion of this topic.)

The other problem spot is the 'extra permissions and restrictions' language. It is purportedly there to allow the integration of code with different license structures, but this integration is not done on an equal basis: "pure GPLv3" code is treated in an assymetrically beneficial way, which some people fear will lead to the assimilation of "non-pure" GPLv3 code. It also departs from the fundamental contribution symmetry spirit promised by the GPLv2: "code others take from you and modify you can take back and put into your project". With the currently proposed GPLv3, taking "pure GPLv3" code (that was taken from your project and modified) and putting those modifications into your "GPLv3 + permissions" project might silently "upgrade" your project's licensing status to "pure GPLv3" - at which point, if your licensing difference from the GPLv3 was on moral or religious grounds it's not "your project" anymore. So my suggestion would be to not "silence" critics with the promise of extra permissions allowed, but with the addressing of the worries of the critics.

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 15:39 UTC (Tue) by Sombrio (guest, #26942) [Link] (6 responses)

3. Are we about to witness a huge FOSS licensing split?

It is inevitable. This has actually been coming for a long time, ever since the term Open Source was coined. Open Source was invented to make the Free software movement attractive to the business world and draw investments. It worked, and today there is a very significant and large investment by commercial interests in Open Source Software. However, the Free software leaders have always been uneasy with the term Open Source and never really supported it. They don't see the value that business brings to the table and they have a deep and entrenched distust of people of influence or people of wealth.

Unfortunately the keepers of the GPL and the leaders of the current changes have become a liability for the business interests. They have clearly shown that they have nothing but disrespect for the political and business leaders of our society. The notion that congress is evil or that business is only out to screw the public, is quite frankly, delusionary. Those who espouse such concepts are in fact creating a culture of hate, and they need medication and counseling before they get violent. While the leaders of Free software were once visionary and creating positive change, their anger has overcome them, and they are no longer people that I, nor many others are willing to follow. I simply can not support the kinds of divisive, hateful, and acidic things that I hear from the Free side of the F/OSS leaders.

Business has invested too much in open source to walk away now. Business is not evil, congress is not evil, DRM does mean Digital Rights Managament and has nothing to do with Digital Restrictions Managment. Many in the world believe that people starving to death in the Sudan is an issue worth getting worked up about, whereas hacking in to a Tivo box may be fun, it is not an issue that has any real bearing on mankind. Thus, a giant fork between those of us who are mainstream and earn a living from Open Source and those of us who are fringe and want to impose their views of society through Free software is inevitable.

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 22:16 UTC (Tue) by svkelley (guest, #37299) [Link] (1 responses)

>Thus, a giant fork between those of us who are mainstream and earn a living >from Open Source and those of us who are fringe and want to impose their >views of society through Free software is inevitable.

I completely agree. I make a living developing embedded devices. I don't spend my time hacking Tivo nor do I want anyone hacking my commercial products. Let the market decide. People see value in the product, they will buy it.

WOW! Community soap opera - and then some!

Posted Oct 5, 2006 14:15 UTC (Thu) by wookey (guest, #5501) [Link]

I make a living from embedded device/software development too, but I'm afraid I can't agree with your or Sombrio's characterisation of the situation. Once I understood the difference I found that I was a 'Free Software' person and not an 'Open Source' person. So there are embedded developers on both side of this argument.

I don't believe the entire embedded industry will stop using Linux even if it can't 'tivoise'. Hackability (aka user feedback, improvements and involvement) is a benefit as well as a potential cost. We live in interesting times, certainly, but calling the FSF names as Sombiro does above and claiming that they are looney zealots and he is the mainstream is certainly simplistic, and probably wrong. There probably _are_ now more 'Open Source' developers than 'Free Software' ones - but it is not a static division, indeed most of the time it is not a division at all. I suppose if GPLv3 retains the anti-DRM clauses then perhaps it will become clearer just how the numbers stack up.

And saying that DRM has 'nothing to do with Digital Restrictions Management' is just bollocks. It _is_ enforcement of restrictions. That's how it's implemented, that's how it works. I'm reasonably confident that it will lose out to free/open content in the long term, but it's going to be an ugly fight. I agree that manufacturers have the right to make DRM-enabled devices, but I don't agree that they can use GPLed code in such a way that end users lose the freedom to modify that code. I'm happy if GPLv3 makes that clearer.

WOW! Community soap opera - and then some!

Posted Oct 3, 2006 22:58 UTC (Tue) by liljencrantz (guest, #28458) [Link]

Thus, a giant fork between those of us who are mainstream and earn a living from Open Source and those of us who are fringe and want to impose their views of society through Free software is inevitable.

That would be very unfortunate. One of the biggest philosophical strengths of open source, in my opinion, is how it can be supported by arguments from almost any political view. If you happen to be a communist, the 'no one owns it' part will sell you the idea. If you are a socialist, the collaborative development model will win your heart. If you are a conservative, the low price will attract you. If you are a free market libertarian, then the economic arguments mage by ESR in 'The cathedral ...' should be convincing.

That new licenses will occasionally be created, and that projects that consider switching licenses will lead to considerable pain is nothing new, and this will doubtlessly happen again in the future. But splitting the entire FOSS movement into two mutually hostile camps would probably lead to them implementing two separate systems, which would be a major blow to the entire movement. We do not need BSD style fork of the entire GNU/Linux system.

I feel that this is just another disagreement over what rights a user should be granted in an open source license. I hope that in the end, the kernel people will use the license they like the most, and the FSF the one they like the most, but that all the little communists, socialists, neocons and libertarians can still get together, pretend they don't hate each other and make a rocking operating system.

WOW! Community soap opera - and then some!

Posted Oct 5, 2006 0:34 UTC (Thu) by njs (subscriber, #40338) [Link]

They don't see the value that business brings to the table and they have a deep and entrenched distust of people of influence or people of wealth. ... The notion that congress is evil or that business is only out to screw the public, is quite frankly, delusionary. Those who espouse such concepts are in fact creating a culture of hate, and they need medication and counseling before they get violent. While the leaders of Free software were once visionary and creating positive change, their anger has overcome them, and they are no longer people that I, nor many others are willing to follow.

I call troll.

RMS and the FSF have very clearly stated reasons for what they do, and these reasons have nothing to do with hatred and everything to do with freedom. There is plenty of room to disagree with their goals, their methods, and their definitions, but let's all respect each other, eh? Can you even give _one_ example of a "divisive, hateful, acidic thing [...] from the Free side of the F/OSS leaders"? (Ironically, the other way around is quite easy, thanks to ESR; but, of course, ESR saying nutty things doesn't invalidate the Open ideology either.)

You might also ask just how much code is produced by people in your "mainstream" versus "fringe". I think you'll find that almost every project's contributors are a good mix, and some of the most significant contributors _are_, somehow, simultaneously on the "fringe"...

WOW! Community soap opera - and then some!

Posted Oct 12, 2006 23:06 UTC (Thu) by Zack (guest, #37335) [Link] (1 responses)

>>They don't see the value that business brings to the table and they have a deep and entrenched distust of people of influence or people of wealth.

They invited major "shareholders" of Free Software to the table for discussing the upcoming GPLv3. So far none of them has left with slamming doors.

The FSF has always seen the importance of commercial endeavours regarding Free Software. In the spirit of the four software freedoms, it is the task of the FSF to safeguard "the right to make a profit" against "the right to make a profit by trampling users rights"

The large shareholders who hold considerable economic assets regarding Free Software are expecting the FSF to listen to their concerns that none of their competitors gains an unfair advantage by unifying on a common ground. In return the FSF wants to define a level playing field where denying users rights cannot be used as leverage.

Basically what you mean by "They don't see the value that business" is "They refuse to cater to the advantage the business I am in gains by supressing the four software freedoms."

>>Business has invested too much in open source to walk away now. Business is not evil,

No, evil business is evil. Good business is good.

>>Many in the world believe that people starving to death in the Sudan is an issue worth getting worked up about, whereas hacking in to a Tivo box may be fun, it is not an issue that has any real bearing on mankind.

Most people aren't in a position to charter a flight and drop food packages over a starving population. However, some are in a position to close the digital divide and create a low-treshold perspective for people wanting to improve their lives.
Countries suffering from hunger are not in a position to take advantage of such technologies yet. But should they reach that stage the opportunity to succeed on technical merit guaranteed by the four software freedoms should be available to them.

Software (and software freedom) has a real bearing on mankind, and this will only increase as time goes by.

>>Thus, a giant fork between those of us who are mainstream and earn a living from Open Source and those of us who are fringe and want to impose their views of society through Free software is inevitable.

This is disingenuous at best; to label those who support Free Software as "fringe" and imply they do not earn their living with it.

WOW! Community soap opera - and then some!

Posted Oct 13, 2006 2:25 UTC (Fri) by sepreece (guest, #19270) [Link]

"Not leaving with slamming doors" doesn't necessarily imply "comfortable", "satisfied", or "believing they have been listened to". Nor are the interests of all businesses necessarily aligned.

It could be that some are continuing to participate because they believe they can get small improvements (removing ambiguities in the license is a benefit even if the unambiguous answer is not the one you would have preferred) and don't want to burn their bridges.

It could be that some are continuing to participate because they favor non-free software options and want to make it harder for others to benefit from using free software.

Community soap opera reruns

Posted Oct 3, 2006 23:07 UTC (Tue) by man_ls (guest, #15091) [Link]

3. Are we about to witness a huge FOSS licensing split?

It has happened in the past, it will happen again. First it was the BSD license, the X license, the Apache license, etc. Then people got fed up to see their code being used by unscrupulous companies to make a cheap dollar and create needless incompatibilities in the process. So developers switched en masse to GPLv2, which preserved their intent of having free code. Meanwhile some corporations pushing weaker licenses for obscure ideological reasons, with little effect.

Now many developers don't like the motivations behind the GPLv3, so (being a bit blind like we all are sometimes) they will stick to GPLv2. Eric Raymond et al will take advantage of the disagreement to push people to softer licenses. In a few years we will be fed up of seeing our code used in "see but don't touch" embedded devices, where its freedom serves no one but its new masters. So devs will try to contribute to projects where the original freedoms are preserved and not abused; some GPLv3 kernel will be there waiting for them, hopefully written in C++.

There is a second, more benign scenario: DRM will be a huge failure in the market and nobody will use it anymore, as predicted by some. In this case the anti-DRM clauses will have no effect, so just for the anti-patent clauses the GPLv3 would have some benefits. A third possibility: DRM could also become mandatory, in which case we are done for anyway; "see but don't touch" freedom would be of no use. I wouldn't bet for any of these two alternatives.

Busy busy busybox

Posted Oct 18, 2006 11:44 UTC (Wed) by ras (subscriber, #33059) [Link]

corbet said:
> the attempt to address this problem in GPLv3 carries a high
> risk of splitting the development community.

After reading the 400 or so responses to the two GPLv3 articles, you would have to say: "QED". That makes the article unique (for me at least) in one way: the response to it proved its point.

The responses also gave me an insight I didn't have before. I didn't understand why the division was so ferocious. Now I do.

One side is about sharing the end result. Eg, "You can't use my software in anything and that can't be modified like my software can". Tivo, with its DRM restrictions preventing them from changing it by modifying software they wrote and own, is an anathema to them. GPLv2 was always intended to enforce their rights over their code, and the fact that it has been circumvented now by, of all things technology, is a bug - a betrayal by the very thing they were trying to share. The whole point of the "or any later version" clause was to fix bugs like this, and that is exactly what they are going to do.

The other side is only interested in protecting the software. It is all about the software. Its about writing it, but more importantly its about having lots of useful software others have written available for them to use. The GPL created this huge software commons that just gets more valuable to them over time. Whether the software can run on device X or not doesn't effect the benefit they get from it overly - the code written by Tivo is still available, and will still work on other boxes. What is important is that it becomes ubiquitous, so that no-one can economically write software without using the commons and thus will be forced to contribute back to it. The GPLv3 will eliminate an entire class of software that can be contributed back. For better or for worse, its looking increasingly likely that content the public expects to access with their computers can only be viewed with the software that is going to be eliminated. So in one foul swoop the GPLv3 may remove the bulk of the users of the software commons the public, thereby reducing its value considerably. To rub salt into the wound, the "or any later version" means that their code, code that they put their own blood and tears into, will be hi-jacked by this miss-guided enterprise.

Two view points. Both valid. Both protecting something almost sacred to their holders. Yet diametrically opposed.