Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

[Julian S. <jse...@gm...>]

Sorry to reply so late to this.

I currently don't have much of an opinion about GPL 2(+) vs 3(+); from looking
at the Wikipedia page it sounds like GPL 3 does fix some problems in GPL 2.

I'm unclear about whether it's possible to change the license without every
contributor's agreement.  I had the impression that it would indeed require
the consent of all authors.  If that is true I would think it would be a
significant difficulty, since there are literally dozens, if not more, of
authors.

Also, some of the code for the kernel interface is derived from Linux kernel
sources (see comment at include/vki/vki-linux.h:29), which would seem to mean
that changing it away from GPL 2 isn't possible.

J

On 16/06/2025 18:52, Mark Wielaard wrote:
> Hi all,
> 
> Updating the subject to be explicit about the goal.
> 
> On Thu, 2025-06-12 at 15:21 +0200, Andreas Arnez wrote:
>> On Mon, Jun 02 2025, Mark Wielaard wrote:
>>> On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
>>>> On 6/1/25 15:22, Mark Wielaard wrote:
>>>>> I think an upgrade to GPLv3+ for valgrind is a good idea. It would
>>>>> also allow us to upgrade some gdbserver parts (various files under
>>>>> coregrind/m_gdbserver). Note that the new vgstack utility is already
>>>>> derived from GPLv3+ code.
>>>>>
>>>>> We could make that a goal for 3.26.0 (or maybe that deserves finally
>>>>> going to 4.0?) for our October release. I can contact the FSF legal
>>>>> team to ask if they want to help with or see any issues with such an
>>>>> upgrade if we want to incorporate more GPLv3+ code from the core
>>>>> toolchain projects.
>>>>
>>>> Licence-wise, I don't have much of an opinion. It would be nice to be
>>>> able to integrate code more easily.
>>>>
>>>> There are two kinds of projects that might get impacted. Third-party
>>>> ports, I guess they will just accept moving to GPL3+.
>>>
>>> Yes. Or they keep on 3.25.x. But I hope the long term goal of any
>>> third-party port would be to eventually get included upstream. Although
>>> I admit we have at times been really slow incorporating new ports.
>>>
>>>>   Then there is VEX.
>>>> The main project that I know of is PyVEX https://github.com/angr/pyvex
>>>> which seems to be under a BSD licence. That looks wrong to me to start with.
>>>
>>> I think that is not deliberately wrong, just slightly confused. They
>>> should probably mention top-level that they are (re)distributing
>>> various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
>>> which properly carry GPL notices). Which means the project as a whole
>>> also is distributed GPL, even if parts of the source code could also be
>>> reused under the BSD license as long as it isn't derived from the GPL
>>> parts.
>>
>> Sounds like everyone is OK with this in principle, right?
>>
>> FWIW, I'd like that too.  For s390x it would certainly simplify things
>> quite a bit.
> 
> Yes, it sounds like we have concensus. I'll contact the FSF legal team
> to ask if they have any comments/advise and then update the headers
> based on their feedback.
> 
> Thanks,
> 
> Mark