GPLv2 can't be used as the basis for upstream GCC features and losing the runtime library exception makes them generally unusable for userspace.
It's not necessarily a problem if the goal is simply having plugins that are forever downstream and only usable for the Linux kernel.
Conversation
All we are discussing here is plugins for the Linux kernel. Nobody is saying ones intended for userland can be GPLv2.
1
Personally, I would not care if the plugins did need to be GPLv3 -- I'm not anti-v3 and wouldn't have any problem with relicensing under it. But they don't for the kernel, and nobody who matters (i.e. those actually holding relevant copyrights) have said otherwise in a decade.
1
What we won't do, however, is be bullied by disingenuous freeloaders not associated with the projects involved, who own no copyright, just because they think they deserve our work (even unpublished work!) for free.
1
1
I don't have a problem with your approach. I'm not sure the upstream kernel developers realize the implications of using GPLv2 for the plugins though. They used GPL2 for the one they wrote themselves. I don't think they really intended to make it partially incompatible with GCC.
3
If I recall correctly, some of your (PaX and grsecurity) plugins were GPLv2 only from the start and others were GPLv2/GPLv3 but then changed to GPLv2.
My understanding was it became an intentional choice to try to get sustainable funding through licensing it for userspace use.
1
Even if it were true (SIZE_OVERFLOW does appear to have been changed from v2 or newer to v2-only in 2016, others that started v2 or newer like sancov_plugin or cyc_complexity_plugin remain so), so what?
2
Everyone seems to be starting from the assumption that something bad is happening, and grasping at anything possible, including far beyond even the spirit of the license, to reaffirm that assumption. It's tiring.
1
I don't think something bad is happening. You were trying to find a way to get funding and make the software sustainable. It seems to be at least partially working and publishing everything for free wasn't doing that for you. I don't have a problem with the approach.
2
3
If following the gpl isn't working for a company then producing derivative works of gpl'd software is not the right line of business for them.
2
They give their customers the source code. If they want to publish it they're legally allowed to do it. It's not as helpful as it seems to get a leaked copy of a massive patch, especially when most upstream work is based on Clang and the most interesting pieces are GCC plugins.
Rich is mad people made fun of his libc years ago for having 1992AD heap exploitation properties, and this is his childish way of getting revenge.
1
You could give upstream the latest release of RAP but it wouldn't mean they would understand it and be able to maintain it. It can't simply be merged with no one developing / maintaining it. That is essentially what they did with a few plugins but they're much smaller/simpler.
2
RAP was publicly available including the deterministic hash-based forward and backward edge protection. It doesn't really seem like anyone else learned anything from it. The state of the art elsewhere is the much slower Clang CFI which leaves backward edge CFI to something else.
1
Show replies