perf is licensed under GPL v2 only and libbfd is a GNU tool that is licensed GPL v3 and higher.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815
Really wish the Linux kernel would start mandating new patches to be GPL v2 and higher and get buy in from the largest contributors. A decade later new code would like replace the smaller contributors code and we could consider the software GPL v3 compatible.
Since, realistically, neither Linux nor GNU will budge, maybe the practical solution would be to look into integrating with the equivalent library in the LLVM ecosystem (assuming it exists).
The GPL 3 is a pretty benign improvement on the GPL 2 (though I know Linus objects to the Tivo clause). I don't think anyone who was happy with their software being used under the terms of GPL 2 would be unhappy with it being used under the terms of the GPL 3 additionally, rather than exclusively.
But let's imagine the next version of GPL 4 was "Additionally the authors may at their discretion use it under the terms of the CC-BY-SA license". Nothing wrong with it as a license, but that's a bigger leap in terms of license changes.
It's not hypothetical that they could exercise that kind of power - they _did_ with the GFDL with the "wikipedia can relicense as CC-BY-SA" clause in GFDL 1.3.
I think most people would agree that that was a responsible use of that power. but I can understand those that don't want to extend the trust that all future uses will be responsible.
It says "the recipient can use this under GPL v2 or any later version as published by the FSF", which means if they recipient is happy with the rights they got under GPL v2 they can keep using it under that version for as long as they like.
The only person agreeing to future license changes is the publisher of the code, and they're the ones that chose to publish it under "GPLv2+" or whatever.
If the FSF goes rogue and changes the GPL to be incredibly restrictive (i.e., allowing proprietary redistribution, and I realise this can be considered permissive..) it might be possible to get it to be ruled invalid defaulting to the more permissive licence, especially if you have deep pockets, or if the FSF change the licence to be ridiculously permissive like 0BSD then it's not going to be legal in countries like Germany, either way any major change is likely to result in an international enforcement nightmare.
The scenario where FSF goes "rogue" would be if gplv4 became more permissive, e.g. if it stopped being a copyleft licence.
“You can do A, B, and C with the software I wrote, or whatever X may at some future date decide you can do with it” isn’t something everybody is happy with. It certainly requires some long-term trust in what X will or will not do.
>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
It doesn't make sense to assign blame on those who bug-fixed the backdoor in the license that clearly would allow a third party to change licensing terms. Even(!) if that third party was rms.
GPLv3 wasn't just an update, it was a major change from GPLv2. Importantly, it limited developers own rights to use code of projects they contribute to how they want (including in devices that are locked or secured in various ways).
Plenty of people even outside of Linux are not going to be going to GPLv3.
The GPLv3 split also damaged the more copyleft side of things as I think some kernel devs predicted.
I think the momentum is currently more MIT / Apache - not sure if that could be where folks could be encouraged to release under to keep at least the open source part alive even if the copyleft part kind of goes away.
Anyone doing any stats on this? The more true open source players are going MIT / Apache style, the proprietary relicense folks are doing the (A)GPLv3 thing to drive licensing revenue given the risk aversion to GPLv3 that is out there. A lot of the GPLv3 codebases require contributor agreements so they can license outside of GPLv3 so they tend not to be true multi-contributor / multi-copyright holder codebases.
This is FUD.
- The developer's own rights to their own code are never limited. What is limited is the rights they get to other people's code.
- GPL does not limit use in any way, it limits distribution.
The limit placed by the GPL on distribution is that the recipient must also be given source code and the same legal rights to the code. The GPL-3 fixes a technical loophole where the recipient is given rights to the code but prevented by technical means of using their modifications to that code on the device it is intended for. And yes, tivoization is absolutely a loophole in the GPL2, i.e. against the spirit of the license - the FSF has always been about empowering users to modify their software.
If so, great, the claim is FUD.
Reality is GPLv3 folks have lied about almost everything - Ubuntu had to get special private communication from FSF to be able to ship a GPLv3 bootloader etc.
And no, the license is pretty darn clear to most of us, even if you are a major contributor to a project, you CANNOT use that project code how you would like. This is not FUD, this is part of the license design. That is a major change from GPLv2 which is what we are discussing.
A reminder that developers, not users, pick the license of code. That is also fundamental to copyright law. You can write a license that makes developers pay users $1,000. Users might like that. Developers may not choose it. That is what is happening here in many cases. Developers are choosing to avoid GPL for other options.
Again - this conversation would be helped if someone had some data. Anecdotally I'm seeing lots more MIT / Apache stuff than GPLv3 stuff these days.
Is this really necessary? The GPL allows you to read and study the software. Is it really copyright infringement if you take your understanding and make your own program? Are people really forced to come up with convoluted new ways to solve the same problem just to avoid any similarity to existing work?
- Striking similarity, or what most of us think of as infringement, where there's literal copies of someone else's code in your own. This is what things like content ID systems try to detect.
- Access plus substantial similarity. This is where you've looked at someone else's code (source or disassembled, doesn't really matter); and then produced something that looks a lot like that code if you squint a little.
Substantial similarity does not have a hard-and-fast rule associated with it, it's usually something that juries or judges decide. It's basically the "yeah just change it a little so the teacher doesn't notice" meme, but in legal form. If you were to read another program's code, and then make another program that looked an awful lot like the first, then you'd be infringing. But this is bounded by other exceptions to and rules of copyright - notably, functionality itself can't be copyrighted, and copyright over interfaces is largely prescribed by various fair use decisions (so emulation and re-implementation is largely still OK even under this standard).
If you read GCC, and then write LLVM, that's not substantial similarity. That's a different, legally distinct compiler design. The FSF could sue the pants off Apple if merely reading GCC source meant any compiler you wrote was infringing.
If you read GCC, and then write a compiler with the same internal representation as GCC; a parser that's structured the same way as GCC; and optimization passes that are organized the same way as GCC's; then you're closer to infringing.
Your responsibility isn't to create an entirely novel program by any means necessary. It's just to avoid doing the software equivalent of tracing over someone else's drawing.
GPLv3 says 'To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.'
If you read and study a work, and then write something new that does the same thing, that may be considered adapting or copying from (parts of) the original work.
I don't have much of an understanding of copyright when it comes to cases like those, but my worry is that declaring that your open-source codebase is merely inspired by codebase X with this specific code in the case of these specific data structures would still count as infringement in a court of law. However, I don't intend to infringe on the licenses of the original, and do not intend to directly copy any code.
Rather than thinking about how to re-implement a thing that doesn't exist, I think about how to implement the tool I actually need. What I end up with may be less general, but it's actual functionality is often simpler and easier for me to grok/remember.
Or maybe rather, what does "use" mean here?
"Use" in this case means to have some feature that's implemented by those libraries reimplemented in an open-source project (MIT-licensed).
I'm past believing that I'm smart enough to always be able to come up with/reimplement a competent enough solution for all my needs by myself every time. But copyright still has to be respected.
When I'm forced into that situation from licensing issues, it really makes me feel like my skillset primarily revolves around gluing together other people's well-designed code, and being left to my own devices exposes my weakness in implementing something from scratch.