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.
Conversation
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.
2
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.
The backward edge protection is SafeStack, which has issues. There's ways around SafeStack and it's in an incomplete state. It doesn't protect shared objects, only application code.
I've done some work in hbsd to get shared object support working, but my priorities keep shifting
1
The shared object support needs tight integration with both the RTLD and libc, in somewhat similar fashion as SSP, but a bit more complex.
If I remember correctly, setjmp/longjmp is still an issue with SafeStack.
1
Show replies