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

LGPL-2.1 is a deprecated SPDX license #1209

Open
chenrui333 opened this issue May 10, 2021 · 8 comments
Open

LGPL-2.1 is a deprecated SPDX license #1209

chenrui333 opened this issue May 10, 2021 · 8 comments

Comments

@chenrui333
Copy link
Contributor

LGPL-2.1 is deprecated by SPDX, please consider using LGPL-2.1-only or LGPL-2.1-or-later. Thanks!

relates to Homebrew/homebrew-core#76926

@chenrui333
Copy link
Contributor Author

also relates to Homebrew/homebrew-core#84708

@chenrui333
Copy link
Contributor Author

cc @linas

@linas
Copy link
Member

linas commented Sep 8, 2021

Possibly commit a613961 fixes the install path issue in Homebrew/homebrew-core#84708

@linas
Copy link
Member

linas commented Sep 8, 2021

I have no clue what Homebrew/homebrew-core#76926 means, or what I can do to fix it. There's no SPDX anywhere in the source that I know of.

@chenrui333
Copy link
Contributor Author

@linas 👋 I think what you need to do is to specify the header part in either the README or in the license part of each file (if they got licensed differently), let me know if that makes sense.

@chenrui333
Copy link
Contributor Author

Or you can probably the man page to include license field and specify the license identifier.

@ryandesign
Copy link
Contributor

Since this issue is still open almost three years later, I'll add this comment as a reminder to do something about it.

SPDX license identifiers are becoming the customary way in which license information is communicated, and Homebrew evidently uses these labels on its packages. SPDX used to define an identifier LGPL-2.1 but it is deprecated because it could be unclear whether this meant that a project was licensed under LGPL version 2.1 only and no other version, or under LGPL version 2.1 or any later version at the user's option. New identifiers LGPL-2.1-only and LGPL-2.1-or-later were introduced to resolve the ambiguity.

The ambiguity might remain in this project, however: is link-grammar licensed "under the LGPL 2.1 only" or "under the LGPL 2.1 or any later version"?

The web site says LGPL 2.1 but does not say "only" or "or any later version" so this might be unclear:

https://github.com/opencog/link-grammar-website/blob/a177a3766f65e6f2450e81bac5541c47f73944b2/index.html#L687-L691

Source code headers say to look at the LICENSE file:

/* Use of the link grammar parsing system is subject to the terms of the */
/* license set forth in the LICENSE file included with this software. */

The LICENSE file is just the generic LGPL 2.1 file which in particular says:

link-grammar/LICENSE

Lines 419 to 425 in 3a26127

Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.

The third option, not mentioned in the above paragraph but implied, is that if a project indicates a license version number but does not specifically mention allowing "any later version", then only that version would apply. So I guess that is the answer for link-grammer: it is licensed LGPL 2.1 only. But you could make that clearer by saying so explicitly in the README, web site, etc.

I also recommend adjusting your code headers. Simply pointing to the LICENSE file is ambiguous since the LICENSE file would be the same whether you have chosen to license the project "LGPL 2.1 only" or "LGPL 2.1 or later". A recent practice is to use SPDX license identifiers in the header of every file.

Incidentally, source code headers also say "All rights reserved" which has been obsolete for decades:

/* All rights reserved */

@linas
Copy link
Member

linas commented Apr 25, 2024

The -or-later variant works for me. I'll merge any pull request that fixes everything to say all the right things in all the right ways.

@linas linas pinned this issue Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants