--list-config license enhancement

[jmcc0nn3ll]

migrated from Bugzilla #483677
status NEW severity enhancement in component start for 9.3.x
Reported in version 9.3.6 on platform PC
Assigned to: Joakim Erdfelt

On 2015-12-04 09:22:49 -0500, Jesse McConnell wrote:

would be a nice feature to be able to indicate the license for each jar listed in the --list-config command

[joakime]

@gregw this sounds like a good task for lachlan, wdyt?

[gregw]

@joakime I think the start code is probably a bit confusing as it's had so many maintainers... but we will see

[stale]

This issue has been automatically marked as stale because it has been a full year without activit. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.

[strogiyotec]

@joakime @gregw @sbordet I made a PR
#9964
Could you take a look please

[sbordet]

@strogiyotec thanks for the PR.
Looking at your implementation, you could use JarFile.getManifest().

However, I think it's opening a can of worms, as looking up Bundle-License from the manifest works only for OSGi...
@strogiyotec has designed for other means to lookup the license, but what if there are multiple licenses?
We risk presenting EPL 2, when can also be AL 2, etc.

I feel we won't be able to be precise, and at that point better to not present anything.

@joakime what do you think?

[gregw]

I feel we won't be able to be precise, and at that point better to not present anything.

We actually have an obligation to present our licenses correctly, as our attempt at doing so is the NOTICE.txt file. It would be nice if we could generate the contents of that through something like this, rather than have it be manually maintained.

For our own jars, there is no excuse for the manifest not to be accurate with regards to licenses. For our dependencies, we can raise issues to get them to correct any issues.

Ultimately you care about the the things you measure. If we don't report on the license listings in the manifest, then they will still be in-precise/wrong... we just wont notice it. Is that any better?

[sbordet]

@gregw from the PR output I was surprised that slf4j-api.jar 2.0.5 does not have a license and indeed does not have neither Bundle-License nor a LICENSE.txt file.

Turns out in 2.0.7 there is META-INF/LICENSE.txt, but it is the MIT one, which would be incredibly difficult to recognize and parse. Fortunately it also has Bundle-License.

Perhaps we can just rely on Bundle-License and say unknown otherwise.
The idea being that we do the minimum work to figure it out, not the maximal effort.

[github-actions]

This issue has been automatically marked as stale because it has been a
full year without activity. It will be closed if no further activity occurs.
Thank you for your contributions.