how v3 is much much simpler

Posted Jul 29, 2009 20:51 UTC (Wed) by bronson (subscriber, #4806)
In reply to: how v3 is much much simpler by coriordan
Parent article: A new GCC runtime library license snag?

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