Re: GPL versions mismatch.
Anthony W. Youngman wrote:
> In message <[🔎] firstname.lastname@example.org>, Raúl Sánchez Siles
> <email@example.com> writes
>> This is how licences are currently arranged in KVIrc:
>> · Project license: GPLv2 adding openssl exception.
>> · Source files in project: almost all GPLv2+, plus a small leftout
>>with miscellaneous licenses.
>> Maybe I'm just misleaded but I think it's somewhat confusing having a
>>project license different to each of the project source. Ideally I would
>>use GPLv2+ for everything, i.e., project and source files. The point is
>>is IMHO perfectly valid for those source files, but not for the project
>>fact that it links against OpenSSL. Even if upstream would be willing to
>>relicense project under GPLv3, they wouldn't be able due to OpenSSL
> Then relicence under "v2 OR v3". In a way, that's better, anyway (take
> note that if upstream *does* have any v2-only code, they'll need to deal
> with it before they can actually relicence to include v3).
No GPLv2 code at sight.
> The other thing is (I don't know OpenSSL) is that the GPL is
> incompatible with OpenSSL (which is likely) or is OpenSSL incompatible
> with the GPL?
> If it's the GPL which won't let you link to OpenSSL, then add an OpenSSL
> exemption to v3.
As far as I know, this is not possible, in other words, incompatible. This
is discussed here:
>> What do you think about this situation? what do you think would be the
>>or simplest solution?
> You have to bear in mind that the source file licences are whatever the
> authors say they are. NOBODY ELSE can change the licence - the GPL does
> not authorise relicencing.
> The project maintainers have presumably said "v2 compatibility is
> required for all submissions, therefore the project licence is v2-only".
> They haven't (THEY CAN'T) impose a v2-only licence, all they've said is
> that the only licence guaranteed to work "as a whole" is v2-only.
> Once you've got your head round the fact that only the code AUTHORS (or
> rather, owners) can change the licences, and that the project licence is
> simply the largest proper subset of the individual licences, then your
> way forward will be logically apparent. Whether you like that way or not
> is neither here nor there.
I assume that the idea was probably that GPLv2 was the best fit framework
for the project. It would clarify some things for me. I also think that it
may have stopped being the best framework for the project, because please
correct me if I'm wrong, it would prevent accepting GPLv3 contributions.
This would clash with the need of GPLv2 for the openssl issue. There could
be other points which I fail to see and which I appreciate hearing.
Besides I'm not sure I understand your latter paragraph, specially the
part: "then your way forward will be logically apparent". Although I
understand that only code authors can change license and the "best fit
I'd like to stress that my intention is simplifying the amount of licenses
present in the project, if possible, this is to say, eventually simplify
Thank you very much for this answer and your point of view.
Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098