LWN.net Logo

Similar in spirit?

Similar in spirit?

Posted Oct 5, 2006 2:02 UTC (Thu) by njs (guest, #40338)
Parent article: Similar in spirit?

While personally I am undecided on the GPLv3 provisions, I find the brouhaha about "similar in spirit" a little curious. A thought experiment for those who it bothers: suppose 5-10 years ago, before DRM was actually on the horizon etc., I had asked you, "What if it was possible to have a computer whose software could only be modified with the permission of the original manufacturer -- do you think RMS and the FSF would consider such a computer to be antithetical to everything they stand for?" If someone had asked me this, I would have said "yes"; the FSF's philosophy seems to make that quite clear. Recall also that while in these discussions we just say "or later version" as a shorthand, the full language we write in our licenses explicitly adds "as published by the Free Software Foundation".

If you agree that the FSF's philosophy is consistent from then to now, and that those of us who used the "or later version" language were explicitly placing our trust in the FSF -- then how can you be surprised when they interpret clause 9 in the same way now as they would have back then? If someone makes you a promise, and also publishes hundreds of pages of positions papers explaining what they meant by it, you can't be surprised when they hold to their version of the promise, rather than what you wished they meant but never said (or explicitly repudiated).

To reiterate, I'm not saying that objections to the current v3 draft are unjustified; just that dragging in clause 9 seems disingenuous.

I also find all the people preemptively removing the "or later version" language from their software strange. Like Ingo points out, this puts a really astonishing amount of power into the FSF's hands, and that's a scary thing. But the scary possibility, the thing that takes an extraordinary leap of faith, is trusting that the FSF will not add _more_ permissions -- in particular, removing things like the "tit-for-tat" that are so fundamental to protecting us. RMS is the only person who could do that. I can't blame people like Linus for deciding to play it safe in this respect.

But, it turns out that all the objections I've heard to the v3 drafts have to do with adding more _restrictions_. For me, there's a fundamental distinction here -- if I found out that my software, that I thought was free, could suddenly be incorporated into proprietary software, that would piss me off. If, OTOH, I found out that someone could suddenly add some patches to my code and the result could only be used on certain machines, then, well... that's annoying, and counter to the GPLv2, but... I would survive just fine. I only object to people forking my code to live in their own little more-restrictive universe if their doing this somehow impacts my own development.

Which is a worry. People (e.g. Ingo) have pointed out that code can go "v2 or later" -> "v3", but not vice-versa, and this gives v3-only forks an advantage that could potentially suck away developer resources. But we're lucky -- most of this stuff is so scary and contentious because the stakes are high and none of us really know how to predict what will happen. In this case, though, we actually have data! _Lots_ of projects have licenses that are "upgradeable" to more restricted ones -- as someone pointed out on the last thread, the LGPL in particular has the property. I'd actually forgotten until it was pointed out. Why had I forgotten? Because it _never_ gets used (except maybe to incorporate some LGPLed code into a pre-existing GPLed project). The same is true of the BSDs... BSD code gets proprietary forks all the time, but have you ever heard of a BSD-licensed project getting forked to GPL? And the fork being successful? Wine is sort of an example of this, except IIUC pretty much everyone switched licenses together -- so it's hard to call it an example of a harmful fork that diluted developer resources.

(See also Don Marti: http://www.linuxworld.com/community/?q=node/182 )

So, since I trust the FSF not to add permissions, and history doesn't support there being non-trivial harmful effects to adding restrictions, I'm leaving the "or later version" language on all my software for now.

I guess finally I'll say something bad about v3 too, since I claimed at the beginning that I hadn't decided but here I am making only arguments for the "pro" side... I am actually, despite the above, really really scared of v3. It isn't the whole debate about whether v3 puts restrictions on use, or separately created hardware, or whatever, that bother me the most. I'd actually call myself a Free Software guy, over the years I've come around to agree with a _lot_ of the FSF's philosophy, but it's this issue of freedom that scares me.

For me (and this matches my reading of the GNU Manifesto), free software means that I can learn from and modify the tools I use, and help my neighbor. And, if the whole world can't be free (since copyright law is not so easy to change), then with tools like the GPL and the GNU project at least we can create a sandbox for ourselves, and so long as we stay inside it, we can stop dealing with obnoxious copyright rules -- we can act as if we're really free.

A not-really-digression: this is what pisses me off about Sun and their CDDL. I'm happy they freed their software, that's very generous of them, woohoo, but they made it GPL incompatible. That's their decision, but it's like the person who says they will only be your friend if you stop hanging out with your other, existing, friend. If you want to come play in our sandbox, great, the more the merrier, but don't try to split the sandbox in two by putting a big wall down the center. The whole point is to never trip over those walls.

This is what worries me about how the v3 process is turning out: if it manages to split the FOSS community, then even if I agree completely with the FSF's goals, I can't shrug that off as just a practical problem, or the regretful but morally necessary outcome of some people deciding that they prefer pragmatics to freedom. It directly, and potentially dramatically, impacts my own ability to act as a free developer. The possiblity terrifies me, viscerally.

I'm starting to wonder if we shouldn't treat the draft v3 DRM provisions like we all treat questionable patches. The legal and technical landscape around DRM is so unsettled right now that no-one seems to be sure if the DRM clauses _are_ in fact necessary to preserve freedom or not, or even if the proposed clauses will actually have any practical effect at all. (Maybe next year it will turn out that the latest preferred way to achieve DRM-like effects doesn't run afoul of the draft language at all.) There's also a worry, just from the difficulty getting the language right so far, that they may have nasty, unforseen negative consequences (i.e., somehow preventing perfectly legitimate and freedom-enhancing projects).

Compare that to a patch adding a new feature to a project. If we can't tell yet whether the feature actually has the right design, the coding style is a little grotty, enough to make us worry it might have bugs in it to make the whole program crash... maybe the feature is actually really, really important to have in the long run. But we already have a bunch of other stuff landed on mainline to go into the next release, and we're not going to delay getting all that to users's hands just so we can get this other new thing right.

So maybe we should push back DRM provisions to GPL v4. The way patches go, half the time it turns out that just by waiting a bit and getting more experience with how the software is used, suddenly the right solution turns out to be obvious to everyone and the debate disappears.

So, to conclude this epic comment:
* rifts in the community are beyond bad news
* "or later version" probably shouldn't scare people who think RMS is a raving zealot, only if you think he's a raving compromiser; and it makes it easier to defer hard decisions and avoid rifts
* maybe DRM clauses should get deferred for now
* we're all in this together...


(Log in to post comments)

Similar in spirit?

Posted Oct 5, 2006 4:09 UTC (Thu) by proski (subscriber, #104) [Link]

So maybe we should push back DRM provisions to GPL v4.
Actually, I haven't heard anyone saying that GPLv3 is better than GPLv2 except the DRM issue. Whoever criticizes changes in GPLv3 compared to GPLv2 criticizes other changes as well.

My prediction is that most code that is under GPLv2 now will stay under GPLv2. But we may see new projects under GPLv3. We may also see some currently non-GPL code relicensed under GPLv3. We may see a new Java implementation under GPLv3. We may see Qt under GPLv3. We may see truly innovative software under GPLv3 due to the fact that it's more explicit with regard to patents.

Making changes to GPL piecemeal would likely increase fragmentation, not avoid it.

Similar in spirit?

Posted Oct 5, 2006 4:38 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

you contradict yourself

you say exisitng code will stay GPLv2, but that there may be a QT under GPLv3

why would they change from GPLv2 to GPLv3?

Similar in spirit?

Posted Oct 5, 2006 8:48 UTC (Thu) by khim (subscriber, #9252) [Link]

Because it's way better Trolltech. Really. Think about it: Qt is used in closed boxes. A lot. But right now you can (in theory) take GPL version and lock it down with DRM. GPLv3 is perfect for dual-licensing scheme!

Community projects rarely change the license (because it's hard). Company-owned projects are toally different kettle of fish. If IBM will "approve" patent changes (who's approval will you trust in regard to patents clause if not IBM?) then I'm pretty sure we'll see a lot of software licensed under GPL, not just Qt.

Similar in spirit?

Posted Oct 5, 2006 14:57 UTC (Thu) by sepreece (subscriber, #19270) [Link]

That's a fascinating observation that I hadn't really thought about before, but it's clearly true: by banning the application of GPLv3 software in protected applications, the FSF is making dual-licensing more attractive, because the alternative licenses do allow such use.

Similar in spirit?

Posted Oct 5, 2006 4:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

the LGPL->GPL conversion isn't the same problem as the GPLv2->GPLv3 conversion for one big reason

there are a lot of people takeing religious stances on the GPLv2/v3 issue who are being extremely adamant about the need to switch to code to v3. there is not a similar body of people determined to eliminate the LGPL

and frankly these people have a point, while I personally prefer the GPLv2, there is no point in having a GPLv3 if all code remains at GPLv2 or later, yes you can use the v3 license, but if it's prohibiting things that v2 allows, anyone wanting to do those things just ignores v3 and acts under the v2 license. Also, the 'license compatability advantage' of GPLv3 is meaningless if a project is trying to maintain GPLv2 compatability.

so there are three outcomes

1. code remains GPLv2 or later and GPLv3 is meaningless as none of it's provisions are every used.

2. code migrates to GPLv3

3. the community splits between the two versions, probably with continual snipeing back and forth.

the FSF is intending for result 2, but unfortunantly I expect result 3 to take place. there are a lot of people who strongly believe both sides of this issue, and if forced to choose, will go different ways.

Similar in spirit?

Posted Oct 5, 2006 8:54 UTC (Thu) by drag (subscriber, #31333) [Link]

Generally speaking it seems that the license choices of the major contributors are respected even if the license can be 'upgraded' to the GPL.

Look at the large number of BSD-licensed software. A major example is PostgreSQL. If there is any peice of software poised for a 'GPL Takover' then that one would be one! But I don't think I've ever heard of anybody trying to 'take over' PostgreSQL with a GPL'd license (although I am sure that it's used in inumerable propriatory products).

There are numerious projects on non-copyleft licenses like zlib and such.

Also don't forget that the GPLv3 is due for a few more revisions before it gets out there. People are all excited right now because it's new and the debates help people figure out what is going on. (I know it helps me a lot)

I think that if the majority of the people in a GPLv2 or later project want it to remain GPLv2 or later then I think that most of them will be fine.

*shrug*

I think the majority of the fights are going to be with people who have "GPLv2 only" style licenses. These people usually had a reason to distrust the FSF/RMS stuff and while the "GPLv2 and later" crowd have little problem integrating with GPLv3 code from other projects (probably all it would take would be a nice email for permission to GPlv2 the code)..

the "GPLv2 only" people will probably end up with huge fights when people try to take them to "GPLv2 or later" for "better compatability" with other programs. The original people that choose the license in the first place will probably perceive it as a underhanded attempt to take their project to GPLv3.. while the other side of the internal project debate will want to see the project gain compatability with GPLv3 code rather then risk going of into irrelevency. (definately not talking about the Linux kernel here, it has it's own special rules)

Eliminate the LGPL?

Posted Oct 5, 2006 23:32 UTC (Thu) by man_ls (subscriber, #15091) [Link]

there is not a similar body of people determined to eliminate the LGPL
What about the own proponent of the license, Richard Stallman?
Also, the 'license compatability advantage' of GPLv3 is meaningless if a project is trying to maintain GPLv2 compatability.
Not if you just take advantage of the "or later" clause; switch to GPLv3 all those things that are GPLv2 "or later" and you can be compatible with Apache code.
the FSF is intending for result 2, but unfortunantly I expect result 3 to take place.
Frankly, we don't need this FUD. Notice how njs in the parent comment says that his biggest fear is not with any GPLv3 clauses, but with the split it might cause. Even our favorite editor seems to think the same way.

That is what many people seem to be trying here on LWN: creating division, crying: "Stop this licensing madness!" I for one am happy that Stallman is not one to change his mind under pressure, even if on other occasions it has worked to the detriment of free software.

Similar in spirit?

Posted Oct 5, 2006 14:58 UTC (Thu) by cventers (subscriber, #31465) [Link]

> This is what worries me about how the v3 process is turning out: if it
> manages to split the FOSS community, then even if I agree completely
> with the FSF's goals, I can't shrug that off as just a practical
> problem, or the regretful but morally necessary outcome of some people
> deciding that they prefer pragmatics to freedom. It directly, and
> potentially dramatically, impacts my own ability to act as a free
> developer. The possiblity terrifies me, viscerally.

That worries me too, but I don't stay up thinking about it at night
because I think things just look that way.

The kernel community is one of the most visible and vocal parties when it
actually has something to say in the public. And while the majority of
the stakeholders in GPLv3 have been relatively quiet, preferring to work
within the Free Software Foundation's open license drafting process, the
kernel developers have limited their response to complaint, telling the
press GPLv3 is wrong, telling the press FSF is wrong, drafting a document
(thankfully some of them at least went this far, but they really ought to
participate officially rather than lob press releases), and further
complaint.

It's no surprise to me that it appears as if we're split right down the
middle. Anyone unhappy about the license is going to scream, but anyone
pleased with it is going to sit back with a smile (think, Tux just got
laid!)

There seem to be a lot of people that are really happy with the way
things are going. We still haven't reached agreement, but that's why
further draft(s) are coming. Sun and Nokia, for example, are encouraged
and predict even further improvement.

The _real_ danger isn't from the GPLv3 license - it's from the GPLv3
license FUD. If you want to make sure we don't get split, focus on
de-fusing emotional tension wherever you encounter it. Discuss the
license but encourage real participation. And make sure that people
realize that preemptive reactions to an unreleased license are absurd,
especially if that stakeholder refuses to officially participate.

Cheers!

Similar in spirit?

Posted Oct 6, 2006 14:37 UTC (Fri) by mingo (subscriber, #31122) [Link]

The kernel community is one of the most visible and vocal parties when it actually has something to say in the public.

The kernel community is the biggest project that is closest to the hardware, so you should not be surprised that we have a direct (and vocal) opinion when it comes to issues of the GPLv3 trying to control hardware. We are dealing with tons of hardware issues today, our work has been DRM-ed by Tivo, and we'll be amongst the first ones suffering the fallout of any negative effect of a bad license change in this area.

Similar in spirit?

Posted Oct 6, 2006 17:22 UTC (Fri) by cventers (subscriber, #31465) [Link]

> The kernel community is the biggest project that is closest to the
> hardware, so you should not be surprised that we have a direct (and
> vocal) opinion when it comes to issues of the GPLv3 trying to control
> hardware.

I claim no surprise. I observe precisely what you've said.

> We are dealing with tons of hardware issues today, our work has been
> DRM-ed by Tivo...

Indeed.

> and we'll be amongst the first ones suffering the fallout of any
> negative effect of a bad license change in this area.

How so? The kernel is under GPLv2 only, and the issue of forming a
consensus among thousands, perhaps tens of thousands of copyright holders
(some of whom might be dead but have living successors-in-interest) seems
to practically wall off the kernel from GPLv3 regardless of what its
terms are.

This is an easy question to answer I'm sure, but please don't forget
about my others scattered throughout this very rich discussion.

And I still haven't gotten a satisfactory answer from anyone as to why
many (most?) of the kernel devs have no desire to officially participate.
So far I've heard of Harald Welte actively participating, alongside
complaints in private from other real process participants that the other
kernel developers never showed or stayed. And Harald himself even asked
the question "Why was I the only kernel developer at three conferences I
attended?"

Why will no one answer my charge?

Similar in spirit?

Posted Oct 13, 2006 10:13 UTC (Fri) by forthy (guest, #1525) [Link]

The kernel is under GPLv2 only

Please read the license, this is not true. Linus redistributes what he has got under GPLv2 only, which is his right. Most of Linux either does not tell anything about the license version (in which case you need to assume that it's GPL any version), or it explicitely tells you that it is GPLv2 or later. Few, if any, files are marked with an explicit "GPLv2 only" by the original author. Linus is not in the position to change the license terms of the original authors, and the GPL clearly states that you get the license from the original author.

Node besides: Linus didn't ask anybody about his GPLv2-only comment in 2.4.0-test-something, so he can remove that whenever he's convinced that GPLv3 is ok for him. Being a loudmouth who makes more than enough errors, and then takes years to recover from that, this is not likely to be soon, but it may happen.

Similar in spirit?

Posted Oct 5, 2006 19:35 UTC (Thu) by pimlott (guest, #1535) [Link]

Maybe next year it will turn out that the latest preferred way to achieve DRM-like effects doesn't run afoul of the draft language at all.
That possibility seems quite real to me. As I posted before:
What if software provider and the service demanding remote attestation are different entities? Eg, the device manufacturer distributes the GPLv3 media player and the media company verifies that it is a "known-good" version (according to their list). This seems a plausible arrangement. So if I hack the media player, the device doesn't "play the same songs", but the manufacturer has no power to change this and the media company has no obligation to the device owner. Who do we go after?

Similar in spirit?

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

The check for the media company signature *is* deployed by the manufacturer in its devices, so the manufacturer can hardly pretend he was not involved one way or another.

Now the interesting part in this scenario is the manufacturer may not have the private key of the media company, so if the GPLv3 latest draft only handles this case, it needs to be tightened up.

Similar in spirit?

Posted Oct 6, 2006 15:34 UTC (Fri) by pimlott (guest, #1535) [Link]

The check for the media company signature *is* deployed by the manufacturer in its devices, so the manufacturer can hardly pretend he was not involved one way or another.

Fair enough, but they can argue that this is simply a standard facility of their (proprietary) operating system, and that they don't control how third parties make use of it.

Or extend the scenario another link: Say entity A distributes the device and operating system which supports trusted remote querying of the running software; entity B distributes a GPLv3 media player; and entity C distributes music to the device only after determining that a good (according to their list) version of the media player is running.

I think that any "tightening up" of the GPLv3 that could block this scenario is reaching too far (if it doesn't reach too far already).

Similar in spirit?

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

The entity wich installs the initial GPLed software version has by definition the means to authorize it.

You can add indirections, cloak it in multilateral agreements, that does not change this basic fact

Similar in spirit?

Posted Oct 6, 2006 16:24 UTC (Fri) by pimlott (guest, #1535) [Link]

The entity wich installs the initial GPLed software version has by definition the means to authorize it.
I believe that's simply not true. In my scenario, the media distributors are merely validating a checksum of the media player binary. This checksum needn't even be provided by the media player company. They could simply distribute a (DRM-enabled) binary, then the media distributors verify that it is sufficiently user-hostily (by inspecting the source code and recompiling with the same toolchain to see that the same binary is produced) and add it to their approved list. Nothing the media player company does can make the media distributors add to their approved list.

Similar in spirit?

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

Your scenario is not credible.

0. Your use of a checksum muddies the water somewhat, because it implies a 1<->1 relationship between authorization and software version. But a fixed checksum list would be of little use, so the list itself must be updateable, and the checksum of the update list is unknown beforehand, which means you have a master key somewhere which can approve any checksum or list, which takes us back to square one.

1. The media player company is not distributing its binary in the hope that, maybe, a media distributor will pick it up, approve it, and it will end up in the device. They have contracts with all these entities if only to get paid. If they take the money without ensuring the licensing obligations are respected, they'll be condemned.

2. Even assuming it does release a binary without any counterpart or contact with the other companies, I believe that by ensuring it can made its way on the device they are participating it its distribution, and have to honor the licensing obligations. Certainly should they approve a binary containing sequences "lifted" from an Hollywood media they wouldn't expect not to be sued.

This is a general weakness of many of the examples provided so far. You all assume that because the GPL "payment" is not monetary, or due to hobbyists, it's somehow optional or weak and you only need to make the situation complex enough before people give up. The law does not work this way.

Before you post any other scenario, take the time to replace "GPLed software" with "Hollywood film" and "GPL licensing obligations" with "Hollywood film licensing obligations". If your house of cards wouldn't protect you when distributing an "Hollywood film", do you actually believe using it for a "GPL software" will work any better before the judge?

Also, do remember that no judge will rule that since you're broke, you didn't have to pay at the shop. He'll rule that since you're broke, you shouldn't have taken what you couldn't afford (and send you to jail). Likewise, being in no position to honour GPL licensing obligations does not give you a free pass at GPLed software. Especially if you've painted yourself in this corner knowingly.

Similar in spirit?

Posted Oct 6, 2006 22:31 UTC (Fri) by pimlott (guest, #1535) [Link]

I agree that the weak point in my scenario lies in the relationships between the parties. If you can show that the media player maker is colluding with the device manufacturer or the media distributors to keep users from exercising their rights, you might be able to use the GPLv3 against them. But I am not as sanguine about this as you: I still fear that courts would not consider my scenario (or some variation) collusion. DRM is still an experiment, and we should keep an open (that is, cynical) mind about all of the imaginitive ways in which the media industry will try to use it.

On your point 0: the checksum list is maintained by the media distributor, so there is no need for a master key.

Also, you seem to have made some interpretation I didn't intend about what's in the media player binary. At least, I don't know what "sequences 'lifted' from an Hollywood media" refers to. What I had in mind is simply that the media player only plays files signed by the media distributor's public key and enforces use restrictions specified in the files. If I offered such a binary (along with its sources) on my web site, having no relationship with any device manufacturer or media distributor, just to be ornery, surely I wouldn't be violating any license.

Similar in spirit?

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

> On your point 0: the checksum list is maintained by the media
> distributor, so there is no need for a master key.

And how do the device knows it can accept a new checksum list? If it can not at all or if it can accept anyone your system is pretty useless

> Also, you seem to have made some interpretation I didn't intend about
> what's in the media player binary. At least, I don't know what "sequences
> 'lifted' from an Hollywood media" refers to.

Let me rephrase it then:

1. Let's say Disney decides to participate in a campaign against evil_of_the_day and makes a great mickey cartoon freely distributable provided it's alway bundled with the latest localised update of education_pamphlet_against_evil_of_the_day

2. one of your nebulous entities authorizes the video for a device sold all over the world, but does not bother with the education_pamphlet_against_evil_of_the_day, or all the localized versions, or ignores updates

3. another of your nebulous entities makes the authorized binary available advertising it can be played in media player

Questions:
A. Do you actually think no one will get sued?
B. Do you actually think no one will be condemned?
C. Do you actually think this scenario is any different legal-wise than yours?

Similar in spirit?

Posted Oct 9, 2006 3:38 UTC (Mon) by pimlott (guest, #1535) [Link]

And how do the device knows it can accept a new checksum list?
The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list.
Let me rephrase it then:
[snip]

I think I understand your scenario, but I truly think the outcome is sensitive (as in my scenario) to the details of the relationships between the entities, and their intentions. If the entity in (3) is advertising the authorized binary for use in many media players, maybe they can say, "hey, it's not our fault that the device in (2) refuses to view the pamphlet--every other device views it".

To repeat, I agree that there may be grounds for finding a GPLv3 violation in some cases like I described; however I don't agree that it is clear-cut for all cases.

Similar in spirit?

Posted Oct 9, 2006 15:33 UTC (Mon) by kleptog (subscriber, #1183) [Link]

The device doesn't need the checksum. The device merely reports the checksum to the media distributor, which validates it against its own (self-maintained) list.

Well, that's obviously not going to work. Then I can simply set the code to return the expected checksum while actually running something else.

For a remote entity to verify you're actually running a particular binary is hard. The act of sending the checksum becomes the weak link, because some upstream router can just change it. So instead, the device has to fetch a list of valid checksums and have some TPM of its own to verify the checksum against the list. It's the verifying of an authentic checksum list that is the crucial part, and where of use of encryption keys comes from.

Similar in spirit?

Posted Oct 9, 2006 16:10 UTC (Mon) by pimlott (guest, #1535) [Link]

Then I can simply set the code to return the expected checksum while actually running something else.
As I said earlier in this thread, the device (with its proprietary operating system) "supports trusted remote querying of the running software". The query protocol naturally ensures the authenticity, integrity, and confidentiality of the communication. You or an upstream router can't tamper with it. The media distributer can be sure that it is talking to the unmodified operating system and getting trustworthy checksums.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds