Even though it is an improvement, I would suggest a couple of more items:

1. Please include Bundle-License manifest attribute to the published jars (see https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license )

2. You might want to remove top-level readme.html and/or about.html. Top-level files like that make it complicated to create uberjars (e.g. if different jars have about.html file, then it is complicated to "merge").
   It would simplify the life of consumers if you put license information inside META-INF/LICENSE file (that is put both JaCoCo and the embedded licenses)

@vlsi As our license is EPL we follow the Eclipse best practices, which is (or was, haven't checked) about.html in the root directory. I would like to do structural changes in a separate PR.

ASM license looks up to date.
I wonder however how would you enforce the license is always up to date (ASM might change years or other bits of copyright notice over time).

EPL we follow the Eclipse best practices, which is (or was, haven't checked)

It would be great if you could find a link though.

@vlsi Do you have a proposal to keep included 3rd party licenses up to date? I don't think ASM includes their licenses in their maven artifacts.

Do you have a proposal to keep included 3rd party licenses up to date?

My proposal is everybody should include license as META-INF/LICENSE file. Then the ones who bundle third-party software can properly take those licenses and build a combined one.

That is why I ask ASM developers to include "up-to-date" license into the distributed jar files: https://gitlab.ow2.org/asm/asm/issues/317881

Otherwise everybody else have to constantly monitor if ASM upgrade requires updating of the license texts. It is way simpler to automate if jar file declares Bundle-License attribute and a copy of the license is included as META-INF/LICENSE.

As you can see in the ASM issue, almost everybody gets "bundling ASM" wrong. It is really sad that ASM devs decline inclusion of the license into asm.jar files.

The point of me raising #916 was twofold:

1. Make JaCoCo compliant with ASM license
2. Talking JaCoCo developers into convincing ASM devs to publish license in the binary jars :)

Do you have a proposal to keep included 3rd party licenses up to date?

@marchof I see you have the similar issue with args4j: jacoco-0.8.4.zip bundles args4j, however you do not reproduce the relevant copyright notice.

I see you have the similar issue with args4j: jacoco-0.8.4.zip bundles args4j, however you do not reproduce the relevant copyright notice.

@vlsi It is at the very bottom of ./doc/license.html

It is at the very bottom of ./doc/license.html

@marchof , I'm afraid either the file is stale or something else.
I have unzipped jacoco-0.8.4.zip, and I fail to see even a single entry for Kawaguchi

Here's what I see in license.html

args4j

args4j is subject to the terms and conditions of the MIT license..

Here's a copyright notice from args4j license:

Copyright (c) 2013 Kohsuke Kawaguchi and other contributors

Not a single file from jacoco reproduces that notice => args4j license terms are violated.

@vlsi Grrr, fixed. Thanks for double-checking! I clearly see why you thinks licenses should be pulled-in automatically.

@Godin Can you please have a look?

@Godin Regarding Google Code Prettify. I wonder whether we need to add everything from the COPYING file after Line 177? Or how exactly are you proposing to add it?

@marchof I'm proposing to add only

Copyright 2011 Mike Samuel et al

followed by full text of license.

@Godin Fixed missing Google Code Prettify licenses.

our license is EPL we follow the Eclipse best practices, which is (or was, haven't checked) about.html in the root directory

It would be great if you could find a link though

@vlsi I think that @marchof had in mind https://www.eclipse.org/legal/epl/about.php

And this page contains several interesting points:

About files are generally only applicable for content that that is delivered as Eclipse Platform Plug-ins and Fragments

IMO we are not delivering Eclipse Plug-ins, nor Fragments, also JaCoCo arrives into Eclipse via repackaging in Orbit that makes its own about.html files. Nevertheless I'm neutral regarding files themselves, but usage of term "plug-in" was already bothering me earlier - IMO we can simply use term "distribution" everywhere.

Name of first package including version number

I tend to agree that important to have version number, because different versions can be released under different licenses. I wouldn't try to automate insertion of version, because in the absence of automatic checks anyway one need to check licenses during updates of versions, and fortunately, we do not have many dependencies, and they are not so often updated.

@marchof also regarding latest commit in this PR

remove 3 leading blanks in license text to left align license block like in other licenses

I would prefer to not do any modifications of license text including any re-formatting, because IMO with original formatting it is easier for others to verify that file literally contains text of license in terms of strings/chars and license is not modified - for example one can simply do

curl https://www.apache.org/licenses/LICENSE-2.0.txt --output Apache-2.0.txt
diff org.jacoco.cli/about.html Apache-2.0.txt

and otherwise need to use diff --ignore-space-change.

To sum-up here is what I would like to propose to do:

1. add versions
2. add following comment in front of

   jacoco/org.jacoco.build/pom.xml

   Line 141 in 9a91884

   <asm.version>7.1</asm.version>

<!--
do not forget to update versions in about.html files
and check licenses when updating versions of
third-party dependencies
-->
<asm.version>7.1</asm.version>

3. use original formatting of Apache-2.0 license
4. replace term plug-in on distribution

@marchof as an excuse about pickiness and addition of more comments after initial review - IMO all of the above will allow to close long-standing #539 😉

@Godin I restored the original white spaces of the Apache license and propose to not invest more time in this (merge it as is or close it).

Instead I would like to pick-up @vlsi idea and check how we can include the licenses in a more machine processable format in ´META-INF/´ and also partly automate this in our build instead of manually maintain redundant license information all over the place.

@Godin I think I now addressed all your review comments. Can you please re-review?

I just noticed that we have more license issues in test modules. But I would prefer to discuss/fix them separately.

I just noticed that we have more license issues in test modules. But I would prefer to discuss/fix them separately.

Not sure to understand what do you mean, because we don't distribute JARs of test modules 😉 so I'm fine with postponing discussion about them.

I think I now addressed all your review comments.

Seems so 👍 I'll merge in few minutes.

Are you ok to close #539 together with this?

Are you ok to close #539 together with this?

Sure!