no support for licence with "or (at your option) any later version"

[carandraug]

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+.

[xtaran]

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.)

[Leont]

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.

[carandraug]

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.

[xtaran]

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 | [email protected] (Mail) X See http://www.nonhtmlmail.org/campaign.html | [email protected] (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

[carandraug]

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?

[Leont]

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:

1. Writing these subclasses.
2. 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 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.

[carandraug]

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?

[Leont]

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

[xtaran]

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](http://grep.cpan.me/?q=license%5Cs*%3D%5Cs*.%3FGPL+file%3Adist%5C.ini)

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

[Leont]

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…

[dod38fr]

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

[xtaran]

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 using `new_from_short_name` from `Software::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 accept `GPL-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 a `or_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 in `dpkg/copyright` files.

I assume you meant debian/copyright files. Kind regards, Axel

[Leont]

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.

[dod38fr]

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 files

I assume you meant debian/copyright files.

Duh, yes. cme dpkg implementation details have leaked in this issue 😕

[xtaran]

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

[carandraug]

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?

[xtaran]

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](http://grep.cpan.me/?q=license%5Cs*%3D%5Cs*.%3FGPL+file%3Adist%5C.ini)

[...]

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 a `or_later` option similar to the `aggregation_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

[Leont]

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.

[xtaran]

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?

[dod38fr]

@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

[xtaran]

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!

[Leont]

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