add copyright to pom.xml

[tobi5775]

Add copyright information to pom.xml.

For a customer project an OpenSource report has to be generated. Therefore a scanner was created to extract the copyright and licence information from our dependencies. This scanner can extract all informaton from pom.xml. Therefore it would be great to have the copyright in the pom.xml like other libraries do.

[scordio]

There is a license section defined by Maven, something we already use.

Which are the other libraries that are doing such practice? For example, I don't see it done in either Spring Boot or JUnit.

My current feeling is this is not necessary. The scanner should look at the standard place for such information.

[scordio]

@tobi5775 I reject this change but am happy to re-evaluate it if it turns out we don't follow standard Maven practices.

[tobi5775]

Hi @scordio,
the scanner is already looking at the standard section for the license information. But our lawyers also want the copyright information. The copyright is not available at the standard license section.

Other libraries doing this practice are for example:

• Json-Schema-Validator
• JJWT
• Apache Commons-Cli
• Apache Commons-Codec

[scordio]

The copyright information is in the text at the target URL:

<url>https://www.apache.org/licenses/LICENSE-2.0.txt</url>

What is the advantage of repeating it in each POM?

It sounds like a tooling gap as we are compliant with Maven guidelines. I am not very keen on introducing clutter in the POMs to please a scanning tool.

Is there any other alternative that would help the scanner to detect the license content we already publish to several places (e.g., LICENSE.txt in the repository root, Java comment on all source files)?

[vlsi]

@scordio , suppose someone wants to borrow code from pom.xml file itself. In that case, the license header would help the consumers to understand the license for a particular file.

In other words, you do have headers for .java files for exactly the same reasons: consumers would be able to understand the license of the file even in case the file is somehow separated from the source release package.

[vlsi]

See https://lists.apache.org/thread/bg8w2pl5yvn61ftr8d3vl0ntocldgql7

[scordio]

@scordio , suppose someone wants to borrow code from pom.xml file itself. In that case, the license header would help the consumers to understand the license for a particular file.

How is a license header in a POM different from the license tag in the same file?

[vlsi]

How is a license header in a POM different from the license tag in the same file?

The link above is an answer by Justin Mclean, Assistant V.P., Legal Affairs, see https://www.apache.org/foundation/#officers.
So there are reasons why the ASF recommends all the ASF source code to put license headers everywhere, including pom.xml.
Of course, assertj is not under ASF, so you are free to choose whatever rules you like, however, reusing known solutions from well-established parties sounds like a good plan.

How is a license header in a POM different from the license tag in the same file?

A slightly different answer would be: <license> tag does not have a well-defined meaning, and most often <license> tag in pom.xml designates the license under which the artifact (e.g. jar file) can be used rather than the license under which pom.xml itself can be used.

At the same time, files like assertj-core/pom.xml have neither license header nor <license> tag: https://github.com/assertj/assertj/blob/26f335ca22ed27f86cd6f450f7e19beebb8c87de/assertj-core/pom.xml
Of course, assertj-core/pom.xml refers to assertj-parent which includes license, however, that is all too hairy. It would be way easier of the headers were just present everywhere, including pom files.

[robertschubert]

Hi @scordio,

I also have an additional aspect to one of your last comments:

The copyright information is in the text at the target URL:

https://www.apache.org/licenses/LICENSE-2.0.txt
What is the advantage of repeating it in each POM?

The given url in your pom.xml (in the license-tag) links us to the original license text hosted by www.apache.org. So this is only the license text without your copyright (which is there in the java source code:

Copyright 2012-2023 the original author or authors.

@tobi5775 's change would address this and I also support @vlsi 's opinion.

[scordio]

The given url in your pom.xml (in the license-tag) links us to the original license text hosted by www.apache.org. So this is only the license text without your copyright (which is there in the java source code:

Fair point, @robertschubert.

@tobi5775 you proposed the manual addition of headers in this PR but you also opened PRs in other Maven projects with different strategies for the same purpose, e.g., adding META-INF/LICENSE files.

Would such a file be sufficient for your purpose?

[vlsi]

META-INF/LICENSE file, Bundle-License attribute in manifest, <license> tag in pom, and the license headers are all different, and it would be better to have all of them

[vlsi]

See gradle/native-platform#40

[tobi5775]

@scordio Yes I've also created other PRs in other Maven Projects with different Strategies. In case of a MIT license I only added the LICENSE file to the jar, because the copyright is already included there.

Alternatively I can create a COPYRIGHT file and add it to the jar under META-INF/COPYRIGHT (see this PR springdoc/springdoc-openapi#2055). It would be fine for us. But as @vlsi mentioned, having all this would be best.

[tobi5775]

See also this PR google/gson#2307 as example

[robertschubert]

I totally aggree with @vlsi
Additionally I regard the pom.xml as a part of the sources, because it sets the base for the whole project. So in my opinion adding the license header containing the copyright notice would be the correct approach in the case the pom.xml is present.
@scordio thanks for being so open for the discussion.

[vlsi]

Alternatively I can create a COPYRIGHT file and add it to the

For Apache License, the copyright is typically included into NOTICE file:

https://www.apache.org/licenses/LICENSE-2.0
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file,

[beckerjohannes]

A slightly different answer would be: tag does not have a well-defined meaning, and most often tag in pom.xml designates the license under which the artifact (e.g. jar file) can be used rather than the license under which pom.xml itself can be used.

I don't think this argument by @vlsi is valid in the context. Yes, each source code file should have a license header in case somebody copies the source file itself. However, the original request by @tobi5775 is exactly to have license for a dependency, not a specific file:

For a customer project an OpenSource report has to be generated. Therefore a scanner was created to extract the copyright and licence information from our dependencies. This scanner can extract all informaton from pom.xml. Therefore it would be great to have the copyright in the pom.xml like other libraries do.

Which is exactly the prupose of the license section in the pom.xml. There are also existing tools which handle the process of 3rd Party Licenses just fine (commercial and OSS). For example the: https://www.mojohaus.org/license-maven-plugin/plugin-info.html can create such a report and can download all the associated license texts. It even has fallback possibilities if the linked license file of a library in the pom is rubbish.

So, if the assertj pom.xml would just point to https://raw.githubusercontent.com/assertj/assertj/main/LICENSE.txt , which should be a project personlized version of the standard apache license at least the original PR would be fine.

Just my two cents.

[vlsi]

I don't think this argument by @vlsi is valid in the context
... However, the original request by @tobi5775 is exactly to have license for a dependency, not a specific file:

@beckerjohannes , I responded to an exact question of scordio regarding "license header in a POM different from the license tag".
I wonder why you think my argument is not valid.

So, if the assertj pom.xml would just point to https://raw.githubusercontent.com/assertj/assertj/main/LICENSE.txt , which should be a project personlized version of the standard apache license at least the original PR would be fine.

Please, no. That would have the following issues:
a) The contents of the file at main branch might change over time, so it would be impossible to tell what is the exact license for the past releases

b) The link might disappear altogether. For instance, suppose one day GitHub bans assertj account and wipes it completely.

Here's a sample of a wildly used dependency (the last release was in 2007) that has a custom link for the license: https://repo1.maven.org/maven2/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.pom
Good luck with finding the license text.

<license>
    <name>Indiana University Extreme! Lab Software License, vesion 1.1.1</name>
    <url>http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt</url>

c) Redistribution section of Apache 2.0 license requires the one who distributes to include the copy of the license:

 (a) You must give any other recipients of the Work or
     Derivative Works a copy of this License; and

Of course, it is silly to include the copy of the license into pom.xml, however, it is more than reasonable to include the copy into assertj-core.jar

d) The use of custom license links requires manual inspection since it might be a customized variation of the license. If the URL references a canonical link, then it is much better for both scanners and human verifiers to tell if the license is well-known or not

e) The point of Apache 2.0 license is that there will be no project-personalized version of such a license. Every Apache 2.0 license text should be identical, and the copyright is tracked via NOTICE file that is intentionally extracted to a separate file. That is why Apache 2.0 license is way better than MIT or BSD. Both MIT and BSD incorporate copyright into the license text, so the result is that every MIT license is different since they all have different copyright sections, which makes license verification harder (you have to double-check that the rest of the license still looks like the typical MIT)

[beckerjohannes]

@vlsi not valid in the context of the context of the original request. For having a license header in the pom.xml is not helpful for having a license for the artifact. The point with having the possiblity to point to a individual license was adressing the points raised by @robertschubert. As always it is hard to keep track in a linear discussion where multiple respond to various different other comments and it is not clear which responds to which.

I think you right in all points.

My main point was, that:

Therefore a scanner was created

is core of the OPs issue and could be totaly avoided by using available oss infrastructure. Leaves your point c) to be resolved.

[joel-costigliola]

thanks all for your comments, can someone summarizes what changes we would like to see in AssertJ then? sorry it's a bit hard to follow 😉

[scordio]

Thanks a lot for all your valuable input, @tobi5775 @vlsi @robertschubert @beckerjohannes.

We discussed it with the team and we would prefer to take this in steps. As a start, we will make sure that ScanCode will properly detect license and copyright information for AssertJ so that we cover what @tobi5775 requires. We will analyze it in #2944.

After that, we are open to further enhancing this aspect but ideally against concrete use cases/scan tooling that users can bring up.