Please clarify license for the published artifacts

[vlsi]

native-platform project publishes a lot of jar files, however they do not mention which license is in place.

1. Please add Bundle-License: Apache-2.0 manifest entry (where Apache-2.0 is SPDX identifier, see https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license )
   Well, current pom.xml tags are quite obvious (even though you might want to replace <licence><name> with SPDX id of Apache-2.0), however adding explicit Bundle-License would simplify automatic analysis.

2. Please add LICENSE file to the produced jar files.
   The suggested file locations is META-INF/LICENSE

3. You might want to mention the license in pom.xml via <license> tag, however it is not that required.

[sschuberth]

however adding explicit Bundle-License would simplify automatic analysis.

Isn't Bundle-License only for OSGi bundles, not for regular JARs? Anyway, automated license analysis is an interesting topic. You might want to check out the OSS Review Toolkit I'm working on.

The suggested file locations is META-INF/LICENSE.

Would you have any reference that suggests META-INF/LICENSE over a LICENSE file at the root of the JAR?

You might want to mention the license in pom.xml via tag, however it is not that required.

Actually in my opinion that's the first and minimum you should do 😀 Plus ideally an <scm> tag for automated source retrieval.

[vlsi]

Actually in my opinion that's the first and minimum you should do 😀 Plus ideally an tag for automated source retrieval.

It does not work that way.
People often have a jar file, and they have absolutely no clue where is the relevant pom.xml..
For instance, if the jar file is embedded (re-distributed), then no pom file exists.

Would you have any reference that suggests META-INF/LICENSE over a LICENSE file at the root of the JAR?

For instance, Apache Software Foundation has 20+ year history, and the rule there is

http://www.apache.org/legal/release-policy.html#licensing-documentation
MUST be located in the distribution format's customary location for licensing materials, such as the META-INF directory of Java "jar" files

As you might guess, lots of Apache Maven plugins would follow that requirement by default.

Isn't Bundle-License only for OSGi bundles, not for regular JARs?

Does it matter? That is a standard manifest name with a well-defined machine-readable value.

[vlsi]

You might want to check out the OSS Review Toolkit I'm working on

Thank you. I've evaluated it as prepared build scripts for Apache JMeter, however, OSS Review Toolkit was hard to bend to produce the desired result. So I went with implementing license-gather-plugin for Gradle

[sschuberth]

For instance, if the jar file is embedded (re-distributed), then no pom file exists.

Correct. But that should be the rather uncommon case. At least it is in my experience.

For instance, Apache Software Foundation has 20+ year history, and the rule there is

Thanks for the reference.

Does it matter? That is a standard manifest name with a well-defined machine-readable value.

It does matter if you want to convince people to use that standard, and esp. you need to convince people about the benefit of adding the SPDX license ID there instead of just in the POM's <license> tag. You did so now by saying that your use-case is re-distributed JARs without POMs, but that was completely not obvious (to me) in the beginning.

I've evaluated it as prepared build scripts for Apache JMeter, however, OSS Review Toolkit was hard to bend to produce the desired result.

Feel free to file an issue about your experiences in the ORT project.

[vlsi]

You did so now by saying that your use-case is re-distributed JARs without POMs,

I'm afraid I fail to recognize now what was the motivation of the issue.
It was probably driven by myself trying to gather licensing information for Gradle itself, but I don't quite remember.

Apparently, JMeter does not re-distribute native-platform yet.

[ljacomet]

Sorry for the late reply!

This is a valid issue. The latest released JARs still do not have an embedded license which would confirm that this project is Apache 2.0 licensed.

This is a topic on which we could accept PRs.