All we are discussing here is plugins for the Linux kernel. Nobody is saying ones intended for userland can be GPLv2.
Conversation
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.
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.
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
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
Show replies
Exactly this -- it's very frustrating after having done so much for free, and still continuing to assist for free (for things you've heard about, some you haven't, and some you haven't yet) and being told by people not doing anything that we somehow are obligated to do more.
2
1
The freeloaders will not be happy until we are spending all of our time on free things for them (and many complained even when we were doing just that). The complainers will never change, but at least we can educate people on what the actual facts are.
1