Update about html's.

[boaks]

Introduce license-maven-plugin.
Rename license of netty to include netty in the name.

Signed-off-by: Achim Kraus achim.kraus@bosch-si.com

[sbernard31]

If I well understand with this PR, "default build" will now generate a list of license dependencies for each project ?
Why do we need to do that ?

I tried to run the build on my side and I get those warning :

[WARNING] The assembly descriptor contains a filesystem-root relative reference, which is not cross platform compatible /licenses
[WARNING] POM for dependency org.apache.httpcomponents:httpasyncclient has an invalid license URL: LICENSE.txt
[WARNING] Unable to retrieve license for dependency: com.upokecenter:cbor
[WARNING] http://www.creativecommons.org/publicdomain/zero/1.0/
[WARNING] Server returned HTTP response code: 403 for URL: http://www.creativecommons.org/publicdomain/zero/1.0/
[WARNING] Unable to retrieve license for dependency: com.github.peteroupc:numbers
[WARNING] http://www.creativecommons.org/publicdomain/zero/1.0/
[WARNING] Server returned HTTP response code: 403 for URL: http://www.creativecommons.org/publicdomain/zero/1.0/

(Curiosity question : Why do we embed LICENSE-2.0-netty.txt too ?)

[sbernard31]

Why adding the slf4j licence ?

[boaks]

The main idea of the PR was to clean up the referred licenses, because some components (e.g. serial execution) has changed. The idea to use the plugin was to verify, that we have the correct list.

[boaks]

I stick to the pattern I found in the "abouts" and available license files,
I'm not sure, what the best practice is.

[sbernard31]

So we generate a list of license and check manually, if information in "abouts" are OK ?

[boaks]

That was my idea. The list is short, I just want to ensure, that we don't miss too much ...

[sbernard31]

Ok so we don't need to generate this at each build, but just when we need to check it ?

[boaks]

Yes, that would be a good improvement.

[sbernard31]

I create a branch based on this PR with only 2 commits.

One commit to remove the license of project dependencies.
Another one to remove the "license download" by default.

When we need to get license of project dependencies to update "abouts" manually we can use :

mvn license:download-licenses 

Just cherry-picks (and squash in this PR), commits which makes sense to you.

[boaks]

Thanks! I will have a look on that, if other tasks are finished :-).

[boaks]

I moved the optional "download-licenses" into a profile. Using mvn license:download-licenses seems to ignore the configuration, which excludes test and californium-own licenses. As profile, the excludes works.

[boaks]

I think, using 3rd-party stuff comes mostly with a licenses, which instructs you to copy the licenses, if you use it. Therefore, I think keeping the MIT and APACHE licenses should be the right way. Now the about mentions precise, which 3rd-party component uses which license, so the 3rd-party-component name in the licenses (introduced prior to me) seems to be obsolete. Therefore I removed the name from the license files.

[boaks]

I would like to keep the

		<fileSet>
			<directory>${project.build.directory}/generated-resources</directory>
			<outputDirectory>/licenses</outputDirectory>
			<useDefaultExcludes>false</useDefaultExcludes>
			<!--includes/>
			<excludes/-->
		</fileSet>

may be in the future "some apps" can use that dowloaded licenses to display them.
If the download-licenses is not active, nothing is included in the jar, so it doesn't harm.

[boaks]

Would it be possible, to copy the from the modules "resources" also from a parents "resources"? Then only one copy of the about.html, edl-v10.html, epl-v10.html, and notice.html would be required and only on "about.html" need to be maintained.

[sbernard31]

My feeling on this below but feel free to do as you prefer.

I think, using 3rd-party stuff comes mostly with a licenses, which instructs you to copy the licenses, if you use it.

AFAIK, including license is generally not about using it but more about redistribution or modification. Here I'm not sure we should consider we redistribute it. We just depend on it.

Another point, Eclipse Foundation is pretty meticulous with license and since years I work with them, I never get a remark about this point (I mean including license of dependencies).

So, personally I would not to integrate it.

may be in the future "some apps" can use that dowloaded licenses to display them.

Personally, I would wait those "apps" exist before to integrate modification for them.

Would it be possible, to copy the from the modules "resources" also from a parents "resources"?

I'm not sure if I get the point correctly but I suppose you could add resources which references files or folders in parent directory ?

1. Put your license files in a parent/licences directory, then add this folder to resources of child project like this :

<build>
  <resources>
    <!-- re-add the defaul directory if you need it, or just in case someone expects it was configured as usual -->
    <resource>
	<directory>src/main/resources</directory>
    </resource>
    <resource>
      <directory>../licenses</directory>
    </resource>
  </resources>
  <plugins>
   ... ...

2. another solution, more verbose but without creating a licences folder using includes instead of directory

<build>
  <resources>
    <!-- it seems to me you need to put again the default resource directory -->
    <resource>
	<directory>src/main/resources</directory>
    </resource>
    <resource>
      <directory>..</directory>
        <includes>
             <include>yourlicensefile.html</include>
       	     <include>anotherlicensefile.html</include></includes>
        </resource>
    </resource>
  </resources>
  <plugins>
  ... ...

But here also I feel this a bit overkill.
Having :

• license file at the source code root folder.
• for binary jar we deliver, generally there is a MANIFEST.MF which is generated and contains :

Bundle-License: http://www.eclipse.org/org/documents/epl-v10.php, http
 ://www.eclipse.org/org/documents/edl-v10.php

(Eventually you can add header to the pom.xml which contains the license too)

<!--
Copyright (c) 201? Institute for Pervasive Computing, ETH Zurich and others.

All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License v1.0
and Eclipse Distribution License v1.0 which accompany this distribution.

The Eclipse Public License is available at
   http://www.eclipse.org/legal/epl-v10.html
and the Eclipse Distribution License is available at
   http://www.eclipse.org/org/documents/edl-v10.html.
-->

• for source jar we deliver, almost all files have the copyright/license hearder.

That sounds enough for me.

[sophokles73]

In Hono we use a separate module legal which contains the about, licenses etc. in a central place. In the other modules we use the maven dependency plugin to copy the content of the legal module to the local build folder. This way we maintain all of the relevant legal docs in one place only.

BTW Simon is right in that the obligation to include license and other notice files only affects dependencies that we re-distribute. This includes all third party dependencies that are required during runtime and their transitive deps. We do not need to include dependencies that are used during build and test only.

[sbernard31]

Using a legal module which will be unpack by maven-dependency-plugin sounds a good idea too. (maybe better than adding a simple resource)

About having a list of licenses, I discover recently maven-project-info-reports-plugin plug-in which generates reports.
E.g. : Just run : mvn project-info-reports:dependencies
And look at : target/site/dependencies.html

This includes all third party dependencies that are required during runtime and their transitive deps.

It's hard to find clear information about that but as I understand "dependency" does not mean "distribution". For me there is distribution only if we provide an archive which contain the third party code.

So for example, californium-core depends on org.slf4j but does not include it in it jar => so no need to add the MIT licence in this jar.
For project where we include it like demo-apps, here license should be include. Generally this should be done automatically as all jars are merged in one and so all licenses should be added (except if there is a file name conflict).

(Here some source about that : https://www.apache.org/dev/licensing-howto.html)

[boaks]

So:

• build a legal module with the update about.html, the eclipse, apache and mit license files and notice.html.
• keep the license downloader optional, so that the verification is a little easier.
• for the demos I didn't check the license right now, but I will do that to complete this PR.

FMPOV, I would prefer to include the licenses in all jars. It's for me not only about the "letters in the license", it's also about appreciate the used work of others. And with a common legal module and the license downloader to required time seem to be fair for me.

[boaks]

OK, I'm done.

• the about.html is update
• the legal module is added
• other modules depend on that and their legal is removed.