top | item 28474344

(no title)

Aengeuad | 4 years ago

I get that the point here is that perf could relicence to GPLv2+ to resolve this issue (although this works both ways, libbfd could dual licence as GPLv2+/GPLv3+) and it could be left at just that, but I have to nitpick this:

>The blame is pretty clearly on the people who editted the license text to be GPL2 only.

They edited the licence, yes, but the FSF explicitly wants you to do this to make your intention clear(1). When you licence software under the GPLv2 (or 3, etc) you have a choice of 'GPLv2 only' or 'GPLv2, or any later version', however since the licence text only states 'Version 2' with the old short labels being just 'GPL-2.0' there's some ambiguity on whether you mean GPL-2.0-only or GPL-2.0-or-later.

The default assumption should always be v2-only, however as (at the time) the FSF were still recommending the short label of GPL-2.0 and the issue of using v2-only or v2-or-later wasn't really an issue you had a lot of v2 licenced software and patches using the default unedited licence with the FSF short label of GPL-2.0 and this is purely the fault of the FSF. It wasn't until the GPLv3 came around which some people didn't like (notably the Linux kernel, which is probably why perf is v2-only) that you got people editing their licences to make the intention clear, although for many projects they had no choice in the matter as changing to v2-or-later would require permission from every copyright holder that had contributed code to that project, again this is partially the fault of the FSF for not having enough foresight or making the choice of -only or -or-later more explicit and clear.

P.S. if you already know the history and context here this post probably seems a little patronising and I apologise for that.

(1) https://www.gnu.org/licenses/identify-licenses-clearly.html

discuss

order

No comments yet.