Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can the license field better describe the licenses? #7355

Open
voxik opened this issue Jan 4, 2024 · 1 comment
Open

Can the license field better describe the licenses? #7355

voxik opened this issue Jan 4, 2024 · 1 comment
Labels

Comments

@voxik
Copy link
Contributor

voxik commented Jan 4, 2024

A while ago, I have submitted this PR trying to clarify the project license. Part of the PR was this line:

spec.license = "MIT AND (BSD-2-Clause OR GPL-2.0-or-later)"

And now it was pointed out to me that this is not according to the documentation and of course RubyGems complains:

WARNING:  license value 'MIT AND (BSD-2-Clause OR GPL-2.0-or-later)' is invalid.  Use a license identifier from
http://spdx.org/licenses or 'Nonstandard' for a nonstandard license.
Did you mean 'AGPL-1.0-or-later', 'AGPL-3.0-or-later', 'BSD-2-Clause-Patent', 'GPL-2.0-or-later', 'LGPL-2.0-or-later'?

The root issue is that I have not realized that the licenses field is an array of identifiers. The following could satisfy the RubyGems license validation:

spec.licenses = ["MIT", "BSD-2-Clause", "GPL-2.0-or-later"]

nevertheless, there is IMHO a lot of information lost. So I though I'll check here what is RubyGems view on this problem. I understand that trying to be more precise in this are would cost a lot of effort, therefore I'm fine if this was rejected. Or maybe the the documentation could be improved to better describe that this is only list of identifiers without capturing anything more complex. Not sure

@rubyFeedback
Copy link

rubyFeedback commented Jan 17, 2024

That change was indeed a bit annoying. Rubygems warns me about just about all my projects now.

I can change my projects, but it is still tedious - every project that has e. g. "GPL-2.0" or something like
that is now "invalid". It would have been better to keep an internal list of aliases, really; that way we
could still use our own descriptions and internally it would match towards the "official" licence as-is.
And, conversely, voxik's example above could be valid, rather than require, in tedious micro-management,
to specify an Array of licences. The problem is not confined to more verbose handling, such as
the example shown via "MIT AND (BSD-2-Clause OR GPL-2.0-or-later)". I always have to look up the
"true" name now, and often it's just changing a few characters (e. g. for my GPL 2.0 projects I now
have to add "-only" to all of them). Not a great change really ...

Could you upstream devs perhaps consider the impact of those changes more in the future? The
real gains here are very, very marginal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
@voxik @rubyFeedback and others