I want Minix's size but Linux's functionality....

Posted Jul 28, 2009 3:39 UTC (Tue) by coriordan (guest, #7544)
In reply to: A new GCC runtime library license snag? by sbergman27
Parent article: A new GCC runtime library license snag?

What would you do differently in the licences?

I want Minix's size but Linux's functionality....

Posted Jul 28, 2009 8:45 UTC (Tue) by rsidd (subscriber, #2582) [Link] (21 responses)

Stick to the GPL v2? Or even the BSD/MIT licences. Free code that was written using those licences in the 1980s is alive and well, and free, today. Proprietary forks have mostly perished (Apple is the only major exception, I think, and even they have not really "taken code proprietary" so much as added proprietary layers on top of it). The copyleft was originally a clever idea, but it's not obvious that it was more useful than plain old BSD/MIT. Increasingly, the FSF's licences smack of control-freakery -- and nobody likes that, really. And if you can't even convince Debian (witness also the kerfuffle over GFDL some time ago) who can you convince?

I predict that rather than accept forced licence changes, people will fork the project (as happened to XFree86) or move on to other alternatives like LLVM.

I want Minix's size but Linux's functionality....

Posted Jul 28, 2009 18:50 UTC (Tue) by coriordan (guest, #7544) [Link] (20 responses)

What part of GPLv3 is bad?

I want Minix's size but Linux's functionality....

Posted Jul 28, 2009 20:06 UTC (Tue) by sbergman27 (guest, #10767) [Link] (5 responses)

I'll go with "stick to GPLv2". The FSF itself decries license proliferation... except when they are the ones doing the proliferating.

GPLv2 still encompasses too much complexity. But the level of complexity is at least arguably worth it. GPLv3 adds far complexity just to add some "refinements". ("Refinements" which the long and bitter debate made clear that *many* do not even like or agree with.)

But in general, when the FSF, after excruciatingly drawn out deliberation, can't seem to keep their own new license clauses from conflicting with their other licenses... that's a pretty strong indication of a problem. It's the same kind of situation as when your spaghetti code, which seemed like such a good idea when you were writing it, starts catching up with you and your programming life turns into a living nightmare.

That perfect GPLv2

Posted Jul 28, 2009 21:32 UTC (Tue) by coriordan (guest, #7544) [Link] (4 responses)

The GPLv3 comment system required people to attach their comment to a specific lump of text. The people who wanted a nice, shorter licence made practically no suggestions.

Now the previously too-long GPLv2 has become "just right" and GPLv3 is the target of "make it shorter!" - I too wish that we could have it on the back of a beermat, but which unnecessary sentences should be removed?

That perfect GPLv2

Posted Jul 28, 2009 22:19 UTC (Tue) by sbergman27 (guest, #10767) [Link] (1 responses)

"""
Now the previously too-long GPLv2 has become "just right"...
"""

GPLv2 is still too long. But its length is, at least, defensible.

"""
but which unnecessary sentences should be removed?
"""

Honestly? This should do:

diff -u GPLv3.txt GPLv2.txt

(Make sure you have enough RAM + swap.)

The result is well tested, relatively bug free, and has a feature set which most people were reasonably happy with. Do we really have to wreck everything just to get back at Tivo?

That perfect GPLv2

Posted Jul 29, 2009 0:55 UTC (Wed) by jordanb (guest, #45668) [Link]

> diff -u GPLv3.txt GPLv2.txt

Clearly the solution for the FSF is to produce a GPLv4, thus rendering the GPLv3 "too long but defensible."

That perfect GPLv2

Posted Jul 29, 2009 0:47 UTC (Wed) by bronson (subscriber, #4806) [Link]

Oh, there were lots of suggestions. The FSF just didn't like them.

Ciaran, You and I had some back-and-forths right here on LWN back in the day. I was practically begging the FSF to remove the Tivoization language because, in my opinion, it was contorting the GPLv3 into a monster that only professional lawyers could understand. Ah, those were good times.

(I think I also mentioned on how painful it was to try to hold a conversation on the GPLv3's automated comment system. This explains my lack of feedback there anyway... Ii was like trying to critique a painting using a web form that only allows comments on individual colors.)

Ah well, water under the bridge. I still totally support the FSF. I do avoid the GPLv3 when I can, though, since I still don't completely understand it. If you'd like to discuss reducing the size of the GPLv3 by reducing its scope, rather than by shortening individual sentences, I'd be overjoyed to reopen that discussion.

That perfect GPLv2

Posted Jul 29, 2009 12:05 UTC (Wed) by DonDiego (guest, #24141) [Link]

> Now the previously too-long GPLv2 has become "just right" and GPLv3 is the
> target of "make it shorter!"

No, both should be shorter, version 3 just makes the problem worse.

GPL version 3 problems

Posted Jul 29, 2009 12:01 UTC (Wed) by DonDiego (guest, #24141) [Link] (13 responses)

> What part of GPLv3 is bad?

Have you read and understood it? I think I can confidently claim that I understand version 2 quite well, but version 3 gives me headaches.

I still don't get the difference between "conveying" and "propagating" after reading those paragraphs about a dozen times. Version 2 is hard enough to understand for laymen, but version 3 is a readability and complexity disaster, sorry.

Read GPL version 1, 2 and 3 one after the other. The bloat^wcomplexity keeps increasing and version 3 finally does not appear to have programmers, but legal experts as its core audience. This is sad. The same effect could have been achieved with less words and much clearer language.

how v3 is much much simpler

Posted Jul 29, 2009 18:44 UTC (Wed) by coriordan (guest, #7544) [Link] (12 responses)

GPLv2 used words like "distribute". I like seeing that word because I think I know what it means.

When a company places an internet-connected, sealed box, which continues to belong to them, in your house for a fixed period of time, and that box contains a computer running GNU/Linux, did the company "distribute"? That's the problem. While I do have a general idea, I don't know what exact meaning that word has in Ireland, the UK, USA, Australia, New Zealand, Canada... And when you translate it, all bets are off.

That makes uncertainty because that company can say they're not "distributing", so I'm worried about going to court, and worse, if I do go to court, the judge might even agree that, by the legal definition of that country, they're indeed not "distributing".

GPLv3 makes things simpler because I no longer have to know or guess the meaning of "distribute" in every country. "Propagate" and "convey" were chosen specifically because they have no existing meanings with regard to software. This means that the licence can explain the intended meaning. So I just read the licence. The licence *text* itself is more complex, but overall, knowing what the licence really means is much much easier.

how v3 is much much simpler

Posted Jul 29, 2009 20:51 UTC (Wed) by bronson (subscriber, #4806) [Link] (9 responses)

> The licence *text* itself is more complex, but overall, knowing what the licence really means is much much easier.

Well that's a relief! Since figuring out what the GPLv3 really means is so much easier, it must be simple to answer the license snag brought up by this article?

Fatal oversight

Posted Jul 30, 2009 5:21 UTC (Thu) by khim (subscriber, #9252) [Link] (8 responses)

Well that's a relief! Since figuring out what the GPLv3 really means is so much easier, it must be simple to answer the license snag brought up by this article?

Have you even read the article? Yup. Sure. Absolutely. When Git and udev will switch to GPLv3 it'll be easy. But till then we are stuck: the problem discussed is related to the fact that GPLv2 uses unprecise definitions and so it's impossible to fix it wihout changing the GPLv2 text or adding some explanations to it. Since FSF is not a copyright holder of Git/udev/etc it's hard to see what the hell FSF can do here.

Fatal oversight

Posted Jul 30, 2009 12:40 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

> it's hard to see what the hell FSF can do here

Well, there's certainly one obvious and trivially correct thing they could do...
Change the license on libgcc to GPLv2+ :)

Fatal oversight

Posted Jul 31, 2009 8:15 UTC (Fri) by mjthayer (guest, #39183) [Link]

I think that that is the most sensible comment I have seen on this thread so far.

Fatal oversight

Posted Jul 30, 2009 16:03 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

> the problem discussed is related to the fact that GPLv2 uses unprecise definitions

I did read the article so, yep, I know that it brought up more issues than this one. You read the whole thing too, right?

If the problem were truly that the GPLv2 uses imprecise terminology then all the FSF has to do is release a GPL2.1 with language bugfixes, or even just an addendum describing language intent.

> Since FSF is not a copyright holder of Git/udev/etc it's hard to see what the hell FSF can do here.

There are two sides to every integration problem. The most obvious thing the FSF can do is, gosh, simply let the runtime library be usable anywhere. Or, they could roll back to the 2008 license, probably with *minor* changes: http://lwn.net/Articles/316835/ (like foom says)

I'm sure they have other options too.

Fatal oversight

Posted Jul 30, 2009 16:18 UTC (Thu) by jordanb (guest, #45668) [Link]

> If the problem were truly that the GPLv2 uses imprecise terminology then all the FSF has to do is release a GPL2.1 with language bugfixes,

They did release an update to the GPL fixing language ambiguities. The copyright holders in question chose not to move to it, either because they had a belief that it 'overreached' or they had removed the 'or later version' clause and now find it too much bother to do a license change.

Maybe a "2.1" would placate some who feel that GPLv3 "overreached" (I doubt it) but it would do nothing to address the second case. The vast majority of the software that's still under GPLv2 would not move to a newer license even if the changes were minor.

> or even just an addendum describing language intent.

This would not be binding on copyright holders not a party to the 'addendum'. (Which is to say, it would only apply to the FSF, which would make it totally irrelevant because all the FSF code is under GPLv3.)

Here we go again...

Posted Jul 31, 2009 7:25 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

If the problem were truly that the GPLv2 uses imprecise terminology then all the FSF has to do is release a GPL2.1 with language bugfixes

They did so - it's called GPLv3.

even just an addendum describing language intent.

There are no need to do this for FSF-licensed software (GPLv3 serves as such clarification) and "addenum" will not be automatically attached to the text of license used by git/udev/etc.

The most obvious thing the FSF can do is, gosh, simply let the runtime library be usable anywhere.

It is useful anywhere (for free and proprietary programs alike) - where other side does not prohibit it.

Or, they could roll back to the 2008 license, probably with *minor* changes: http://lwn.net/Articles/316835/ (like foom says). I'm sure they have other options too.

I see no such options - except one: return back to the GPLv2. And FSF surely will do no such things. Reasons were explained well in advance. This switch was planned more then two years ago - if people wanted to raise racket the time was back in 2007, not today.

Here we go again...

Posted Aug 6, 2009 10:10 UTC (Thu) by SEMW (guest, #52697) [Link] (2 responses)

> It is useful anywhere (for free and proprietary programs alike) - where other side does not prohibit it.

Of course it's "useful anywhere... where the other side does not prohibit it". But the point is that it is written in such a way that the GPL v2 -- a widely used and free license -- *does* prohibit it (if the runtime library is distributed with the binary). To plead that this is the GPL2's fault is trivially true, but missing the point (in a similar way to Joerg Shilling's defending Sun's use of the GPL-incompatible CDDL on the grounds that it's a completely free license, and if the FSF thinks it's incompatible with the GPL, that's not Sun's problem).

> if people wanted to raise racket the time was back in 2007, not today.

That is bordering on disingenuous. As you know, no-one noticed this problem in 2007, it's only just been pointed out.

This is not GPLv2 fault, sorry...

Posted Aug 9, 2009 11:58 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

But the point is that it is written in such a way that the GPL v2 -- a widely used and free license -- *does* prohibit it (if the runtime library is distributed with the binary).

Nope. It does not prohibit anything if you apply it correctly. Please read GPLv2 - specifically paragraph 9. GPLv3 does the same in paragraph 14. The problems only arise when someone applies GPLv2 in such a way as to create the problems - but then the conventional wisdom says it's not a problem of GPL...

To plead that this is the GPL2's fault is trivially true, but missing the point (in a similar way to Joerg Shilling's defending Sun's use of the GPL-incompatible CDDL on the grounds that it's a completely free license, and if the FSF thinks it's incompatible with the GPL, that's not Sun's problem).

I can't see your point. In both cases copyright owners did what they thought was right. The results are unfortunate: Linux does not include ZFS as the result, Git should be compiled with GCC 4.3.

The situation was somewhat different in these two cases: Sun's decision created problem immediately, Git's developer's decision created problem few years down the road - but it's not like they had no warning: indeed, the warning is embedded in the very text of the license they've used!

This is not GPLv2 fault, sorry...

Posted Aug 12, 2009 12:36 UTC (Wed) by SEMW (guest, #52697) [Link]

> Git's developer's decision created problem few years down the road - but it's not like they had no warning: indeed, the warning is embedded in the very text of the license they've used!

Being there and being apparent are very different things. The current problem is as a result of an interaction between the gcc runtime exception and the GPLv2 that, whilst it was in a trivial sense there all along, no-one had noticed until Kalle Niemitalo pointed it out very recently. (If I am mistaken and it was, in fact, known before, please say so; as I said in the other thread, the story does not give that impression).

You can study ZFC for quite a while without deducing Fermat's last theorem, even though it is a logical consequence of them. And the fact that the two licenses interact in this way might have been there all along, but it was apparently sufficiently non-obvious that, yes, the git developers could certainly be said to have had no warning.

how v3 is much much simpler

Posted Jul 30, 2009 10:17 UTC (Thu) by rsidd (subscriber, #2582) [Link]

Simple answer: don't go to court?

how v3 is much much simpler (after taking a hit from the crack pipe)

Posted Jul 30, 2009 19:07 UTC (Thu) by DonDiego (guest, #24141) [Link]

> GPLv3 makes things simpler because I no longer have to know or guess the
> meaning of "distribute" in every country.

At least I could understand the license in *one* country with v2..

> "Propagate" and "convey" were chosen specifically because they have no
> existing meanings with regard to software. This means that the licence can
> explain the intended meaning.

I wish it did explain the intended meaning. Have you understood the intended meaning and difference between "propagate" and "convey"? I still fail to clearly see a difference and the GPL FAQ obscures the point further.

> So I just read the licence. The licence *text* itself is more complex,
> but overall, knowing what the licence really means is much much easier.

This is a contradiction. A complex text, by its nature, lends itself more to different interpretations than a clear and simple one. How can you now be sure that your interpretation is the intended one? And who guarantees that a judge will not disagree?

But the main problem remains: The target audience seems to have shifted from laypersons to experts in reading legalese. This is very sad and counterproductive. I myself will not release code under v3 for the foreseeable future and will not suggest using v3 to anybody, maybe even recommend to stay away from it when asked for licensing advice. I bet I am far from the only person that thinks so and I do not see people around me rushing to adopt v3, on the contrary. This cannot have been what the authors of v3 had in mind.

I shudder when I think what v4 or v5 might look like...

I want Minix's size but Linux's functionality....

Posted Jul 30, 2009 5:36 UTC (Thu) by grahammm (guest, #773) [Link] (1 responses)

Make the licence for the gcc runtime library very simple. "This (binary) library may be distributed with any binary compiled by the gcc compiler of which it is a part". That is, if a program is compiled with gcc, irrespective of its licence, and it makes calls to the runtime library then the binary gcc runtime library may be distributed with the binary of the program.

I want Minix's size but Linux's functionality....

Posted Aug 1, 2009 0:05 UTC (Sat) by coriordan (guest, #7544) [Link]

That wouldn't work, if I've understood what you mean.

The combination of binary runtime library plus binary git (or any gplv2 application) can be distributed. And the recipient reads the licence of git and sees that she's entitled to a copy of the complete corresponding source code under the terms of the GPLv2... but she can't have the source code to the runtime library (which is part of git after compilation) under GPLv2 because the runtime library's licence is GPLv3, not GPLv2.

It's an interesting path alright, and I'm thinking about other types of clauses that could go into the runtime library exception along the same lines....