Fix #265 list licenses #11993
Fix #265 list licenses #11993
Conversation
List licenses in --list-classpath
| private static boolean isLicenseFile(JarEntry entry) | ||
| { | ||
| String name = entry.getName(); | ||
| return name.matches("(?i)^(META-INF/)?LICENSE.*") || name.matches("(?i)^LICENSE.*"); |
There was a problem hiding this comment.
Need "license" and "licence" (both are found in the wild)
There was a problem hiding this comment.
Note: /about.html is also a place to look for licenses.
Take the above ecj-3.37.0.jar as an example.
There was a problem hiding this comment.
The /META-INF/maven/<groupId>/<artifactId>/pom.xml can contain the license in two different ways.
As a formal <licenses> element in the XML (might be in the parent pom, but that's too much work to fish for), and also as a comment in the pom.xml itself.
Take animal-sniffer-annotations-1.23.jar as an example of the latter (as an XML comment)
There was a problem hiding this comment.
I hear you about about.html and the pom elements.... but worried that might get a bit too complex.
There was a problem hiding this comment.
The nature of LICENSE is rather complex.
Listing just the URLs is, to me, a no-go, as it doesn't convey the LICENSE details properly.
Example:
- In the case of more than one license, is the choice "License-A AND License-B" or "License-A OR License-B" ?
- In the case of GPL and LGPL, is the text referencing the license mentioning "only" or "or later", this distinction is present in the SPDX ids, but not if you just use the URLs. (see the "GNU General Public License" and "GNU Lesser General Public License" and "GNU Library General Public License" entries in the SPDX list - https://spdx.org/licenses/)
- And many of the other things that Apache JMeter brought up with the SPDX folks 4 years ago - https://lists.spdx.org/g/Spdx-tech/message/3866
I think we shouldn't be interpreting the licenses, if a SPDX exists, we use it, anything else is left blank.
That would also simplify this implementation, dropping the entire SPDX url list class this PR has.
There was a problem hiding this comment.
@joakime I don't understand what the problem with URIs is? There is no semantic difference really between Apache-2.0 and https://www.apache.org/licenses/LICENSE-2.0.txt, except the later is a little bit more convenient if you are looking.
The issue with multiple jars is not about how they are referenced, but how they are combined. The bundle plugin has chosen to us a comma rather than "or" in the bundle-license field... but is that really a problem? Are there any examples of AND for multiple licenses? If so, what does that even mean?
Anyway, for our jars, I have added to this PR that we set the SPDX to EPL-2.0 OR Apache-2.0 in the manifest of all our jars, so that overrides the comma confusion of the bundle-license (which is still there).
But if a jar does have an SPDX, but does have a bundle-license with commas, then I see no reason not to list that, even as a URL, because that is what that jar is telling us the license is. Others will need to look closer if they wish to interpret. Hiding information doesn't change that.
Ditto for URIs found in LICENSE files. They may be wrong or miss directions, but this list is only a convenience and nothing legal. So better to tell the info we have found and if it is not clear then others can look deeper.
That doesn't look right. It shows only the copyright declaration, not the license. The But the <licenses>
<license>
<name>BSD 2-Clause "Simplified" License</name>
<url>https://opensource.org/licenses/BSD-2-Clause</url>
</license>
</licenses>Which is more clear. Opened jetty-project/jetty-quiche-native#111 to address this for that one artifact (since we control it) |
Add SPDX to all our manifests handle License and Licence
|
After latest updates, here is some sample output: |
I don't like it because it is interpreting the declaration of the license by the project, not conveying what the project has declared themselves. There's 2 major examples of issues this creates. 1: More than 1 license.While A single license has it's own quirks (explained below), the case of multiple licenses creates a scenario where we are reinterpreting the license of the project in a unintended and bad ways.
What way is
This nuance is important. We cannot just give a comma delimited list of licenses like that. In the case of logback it would be ... https://github.com/qos-ch/logback/blob/master/LICENSE.txt (which declares an "or" condition in that link) 2: How the license version is to be interpreted by the users of the project.Linking to the LICENSE itself (via the URL) is insufficient to declare how that project is using that license. This is particularly important for projects using GPL or LGPL licenses (but not limited to just those), as the project can decide to let users of the project use the license version "only" vs "or later". In short, the URL to the GPL or LGPL license alone is insufficient to declare their intent, as it does not convey the "only" vs "or later" details that the project is declaring with the license. For SPDX, this is presented as different identifiers to be used on the SPDX line.
In summaryIn summary, the only URLs on the output that would be valid are those that point to the project LICENSE text (or html). SPDX output is totally sane for a programmatic task like this PR is doing, as we are not interpreting the declaration by the project, just conveying it as-is. |
|
It was a mistake to merge this as-is. The URL list is still a problem as we are misrepresenting the license use of the project. |
List licenses in --list-classpath
Example output