Open carandraug opened 7 years ago
I was just about to open the very same bug report against Software::License as I have exactly this issue explaining to Dist::Zilla that my project is GPL_3+
, not just GPL_3
. (And in META.json
and friends, it ended up as even only gpl
.)
Essentially, that's nothing more than creating your own subclass that has the appropriate text. I don't think this requires anything from Software::License's core.
It is a bit annoying though that our metafiles can't express this, but that's a problem for another ticket (and I'm afraid not something we can fix easily). Legally that's not the part that matters though AFAIK, so I guess that's acceptable.
Essentially, that's nothing more than creating your own subclass that has the appropriate text. I don't think this requires anything from Software::License's core.
That is true for all the Software::Licence::*
. My point is that GPL with "any later version" is very common and would make sense to support it in core. I would say that it's even more common than GPL locked to a specific version but I only have anecdotal evidence.
Hi,
On Tue, Jan 31, 2017 at 05:47:08PM -0800, Carnë Draug wrote:
Essentially, that's nothing more than creating your own subclass that has the appropriate text. I don't think this requires anything from Software::License's core.
[…] My point is that GPL with "any later version" is very common and would make sense to support it in core. I would say that it's even more common than GPL locked to a specific version
Exactly.
but I only have anecdotal evidence.
It's actually the default when you follow the FSF's guidelines: https://www.gnu.org/licenses/gpl-howto.html
Only few projects, like e.g. the Linux kernel, choose to drop the "any later version" phrase and stick to an explicit version of the GPL. (Dito for LPGL, AGPL, etc. btw.)
So please add this notion to Software::License core as at least GPL_1+, GPL_2+ and GPL_3+.
Thanks in advance!
Kind regards, Axel
-- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe@deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)
It's actually the default when you follow the FSF's guidelines: https://www.gnu.org/licenses/gpl-howto.html
Only few projects, like e.g. the Linux kernel, choose to drop the "any later version" phrase and stick to an explicit version of the GPL. (Dito for LPGL, AGPL, etc. btw.)
I certainly have been using GPL_3 when I meant GPL-3+ and only caught on to this because Debian asked me to clarify the licence. So should those classes have the "any later version" there by default and a new GPL_N_only, etc classes be added instead?
My point is that GPL with "any later version" is very common and would make sense to support it in core.
There are two different things here:
Given how thinly stretched the maintainers of this dist are, they're unlikely to do number 1 for you anytime soon. But if you can make step 2 as little work as pressing "accept merge request", your odds are remarkably higher.
I would say that it's even more common than GPL locked to a specific version but I only have anecdotal evidence.
On CPAN neither is particularly common, but that's only because Perl-license (Artistic | GPL1+) is the norm.
There are two different things here:
- Writing these subclasses.
- Merging them into S::L itself, as opposed to separate CPAN distributions.
Given how thinly stretched the maintainers of this dist are, they're unlikely to do number 1 for you anytime soon. But if you can make step 2 as little work as pressing "accept merge request", your odds are remarkably higher.
I have no problem doing 1. I just want to make sure that 2 can happen too so I can do this right. So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?
So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?
I think such a change of the existing classes would require a broader discussion, including existing authors using the {A,L,}GPL subclasses
Hi,
On Wed, Feb 01, 2017 at 12:33:26PM -0800, Leon Timmermans wrote:
So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?
I think such a change of the existing classes would require a broader discussion, including existing authors using the {,A,L}GPL subclasses
I agree with Leon that we should stay backwards compatible. If possible just adding a plus sign to the current identifiers would be nice.
If that's not possible because the identifier needs to be able to be a Perl Module name, I suggest appending the string "_or_later".
Kind regards, Axel
I agree with Leon that we should stay backwards compatible.
I think that's the only realistic option at this stage.
If possible just adding a plus sign to the current identifiers would be nice. If that's not possible because the identifier needs to be able to be a Perl Module name, I suggest appending the string "_or_later".
It has to be a valid class name…
An alternative solution is to create a Software::License
class using new_from_short_name
from Software::LicenseUtils
class.
Debian version of Software::License
has been patched to accept GPL-3+
as a valid version.
This set of patches also enable all Software::License::L?GPL.*
classes to accept a or_later
parameter to handle the or_later clause. This is used by cme with dpkg model to provide the correct license text when dealing with L?GPL-\d\+
clause in dpkg/copyright
files.
All the best
Hi Dominique,
On Wed, Feb 01, 2017 at 10:55:39PM -0800, Dominique Dumont wrote:
An alternative solution is to create a
Software::License
class usingnew_from_short_name
fromSoftware::LicenseUtils
class.
This doesn't seem to suffice for dzil's usage of Software::License:
Debian version of
Software::License
has been patched (https://anonscm.debian.org/cgit/pkg-perl/packages/libsoftware-license-perl.git/tree/debian/patches) to acceptGPL-3+
as a valid version.
If I use "GPL-3+" as license in a dist.ini on Debian Unstable, dzil bails out as follows:
`Software::License::GPL-3+' is not a module name
This set of patches also enable all
Software::License::L?GPL.*
classes to accept aor_later
parameter to handle the or_later clause.
Neither does "license = GPL_3 or_later" work inside dist.ini files:
`Software::License::GPL_3 or_later' is not a module name
This is used by cme with dpkg model (https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme) to provide the correct license text when dealing with
L?GPL-\d\+
clause indpkg/copyright
files.
I assume you meant debian/copyright files.
Kind regards, Axel
Neither does "license = GPL_3 or_later" work inside dist.ini files:
`Software::License::GPL_3 or_later' is not a module name
You're using a space where you should use an underscore.
This doesn't seem to suffice for dzil's usage of Software::License:
You're right.
If I use "GPL-3+" as license in a dist.ini on Debian Unstable, dzil bails out as follows:
May be dzil should be fixed to use new_from_short_name
instead of
plain new
. This would make license entry in dist.ini
more tolerant. I.e. GPL-1
could be accepted as well as GPL_1
clause in
dpkg/copyright
filesI assume you meant debian/copyright files.
Duh, yes. cme dpkg
implementation details have leaked in this issue :confused:
Hi,
On Sat, Feb 04, 2017 at 12:14:52AM -0800, Leon Timmermans wrote:
Neither does "license = GPL_3 or_later" work inside dist.ini files:
`Software::License::GPL_3 or_later' is not a module name
You're using a space where you should use an underscore.
On purpose. The patch at https://anonscm.debian.org/cgit/pkg-perl/packages/libsoftware-license-perl.git/tree/debian/patches/add_or_later_clause says "add or_later license parameter". Note the word "parameter".
But using GPL_3_or_later doesn't work either:
[DZ] could not load class Software::License::GPL_3_or_later for license GPL_3_or_later
See Dominique's comments for what would need to be changed. (But that's probably a Dist::Zilla issue, not a Software::License one.)
Kind regards, Axel
Carnë: So can I make the GPL licences (and LPGL, AGPL, etc. as mentioned above) have the "at your option" clause by default? And add new classes with "_only" on the name?
Leont: I think such a change of the existing classes would require a broader discussion, including existing authors using the {,A,L}GPL subclasses
xtaran: I agree with Leon that we should stay backwards compatible.
Leont: I think that's the only realistic option at this stage.
I don't know. Looking at the actual modules in the first few
distributions of that search, GPL_3 is listed on dist.ini
but the
actual code is often under Perl_5. It would be backwards incompatible
but if GPL_3 changed to be the same as Perl_5, it might fiz a lot of
those issues.
Anyway, should the new classes be named *_or_later
or would you
prefer another naming convention for this? Alternatively, there could
be a or_later
option similar to the aggregation_clause
option on
the Artistic_1_0 class?
Hi,
On Sat, Feb 04, 2017 at 05:26:31AM -0800, Carnë Draug wrote:
I think such a change of the existing classes would require a broader discussion, including existing authors using the {,A,L}GPL subclasses [...] I don't know. Looking at the actual modules in the first few distributions of that search, GPL_3 is listed on
dist.ini
but the actual code is often under Perl_5.
Then this is probably a severe bug in these distributions.
It would be backwards incompatible but if GPL_3 changed to be the same as Perl_5, it might fiz a lot of those issues.
No, it would cause a lot of confusion and probably also some legal issues.
Anyway, should the new classes be named
*_or_later
or would you prefer another naming convention for this? Alternatively, there could be aor_later
option similar to theaggregation_clause
option on the Artistic_1_0 class?
I'd prefer if Dominique's patch would be applied and dzil (or at whatever level between dzil and Software::License new() is used) would be changed to use Software::LicenseUtils' new_from_short_name() instead of just new(), as this sounds like a very sane solution to me which makes dist.ini files much more flexible and easier to use with regards to selecting the correct (i.e. wanted) license.
Kind regards, Axel
Debian version of Software::License has been patched to accept GPL-3+ as a valid version.
I rather like this solution.
May be dzil should be fixed to use new_from_short_name instead of plain new. This would make license entry in dist.ini more tolerant. I.e. GPL-1 could be accepted as well as GPL_1
That is just a PR away too.
Hmmm, I just stumbled upon https://metacpan.org/release/Software-License-OrLaterPack which seems older than this issue, but seems to solve it by providing an according add-on to Software::License. Or am I wrong here?
@dod38fr: Would packaging that module for Debian clash with Debian's patch to solve this issue?
Any other drawbacks like addtional build-dependencies to be added depending on the license?
@xtaran Debian patches were removed from Debian version of Software::License. The functionality required to accept GPL-x+ as valid version was moved to Software::LicenseMoreUtils (although I failed to document this feature :-( )
Software-License-OrLaterPack does not conflict with Software::LicenseMoreUtils. AFAIK, the latter is used only by cme
The functionality required to accept GPL-x+ as valid version was moved to Software::LicenseMoreUtils
Ah, I think I vaguely remember having seen that. But I seem to have forgotten this. I had a note in some years old stashed code about this issue here and wanted to check if I can in the meanwhile use that stashed code. Seems as Software::LicenseMoreUtils
is the way to go for me at that point.
So thanks for that pointer!
Note that nowadays Software::License has SPDX support, which means that we can actually express this sort of thing in a machine readable way now
GPL licences often come with the "or (at your option) any later version" clause. For example, GPL-2 and GPL-2+ are two different licenses, and so are GPL-3 and GPL-3+. Would be nice if this would be handled since it is confusing for packagers to see GPL_3 (which infers GPL version 3 only) on the metadata files while the licence on the individual files claims to be GPL 3+.