LICENSE for third-party software

[Vladimir Sitnikov <si...@gmail.com>]

Hi,

As you might know, bundled dependencies often require an entry in LICENSE
file.
Gradle-based build would generate LICENSE file automatically, and i wonder
if there are preferences for the file format.

There are at least two ways to deal with that.
As of now, JMeter is using "approach B" (==subfolder for third-party
licenses), however I find "singlefile" approach is viable as well (and it
might even be better).

Does anybody have a preference / justification for one approach or another?
It is really sad, yet I have no strong preference, however I might miss
some use-cases.

A) Bundle all the licenses to a single LICENSE file.
For instance: (1MiB file ahead)
https://github.com/microsoft/vscode-python/blob/master/ThirdPartyNotices-Distribution.txt
Pros: single file contains all the licensing info
Pros: LICENSE file is position-independent (it does not reference other
paths)
Cons: it complicates the license review (e.g. 1MiB file on a mobile do not
work well)

B) Put just references to a root LICENSE file, and include third-party
license files to a subfolder.
Pros: it is probably easier to review individual licenses
Cons: It is harder to compare across different artifacts (e.g. diff for
1MiB file just works, and subfolders complicate that)
Cons: "root" LICENSE becomes position-dependent (for instance, subfolder
with third-party licenses needs to be baked into the root LICENSE)

Vladimir

Re: LICENSE for third-party software

[sebb <se...@gmail.com>]

On Wed, 17 Jul 2019 at 18:55, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Hi,
>
> sebb>if version B has and additional dependency compared with version
> sebb>A, the single file version will differ by both the additional
> sebb>dependency details and potentially the full license text
>
> "combined" LICENSE file could have the following format:
> block1) AL-2.0 text
> block2) short summary for third-party licenses
> block3) full license/notice texts for third-party
>
> Then even the very basic diff tool would properly compare "short summary",
> so it would be very easy to tell when dependency is added/removed or
> changes license.

Understood, however the diff would still be harder to read than if the
full licenses were in separate files.

> Vladimir>"subfolders" Cons: "root" LICENSE becomes position-dependent
> sebb>Not sure I follow why this is considered a problem; it's not something
> sebb>that needs to change often, if at all.
>
> For instance, jar files typically include LICENSE as  /META-INF/LICENSE.
> What should be the location for third-party license files?
> It could be /META-INF/licenses/asm-7.1/LICENSE
> How that location should be referenced from the summary?

You did not make clear that you were talking about the Maven jars
rather than the binary archive.

> Should it be <<License texts can be found in /META-INF/licenses folder>>?
> Should it be <<License texts can be found in /licenses folder>>?

Neither:

<<Additional License files can be found in the 'licenses' folder
located in the same directory as the LICENSE file (i.e. this file)>>

The relative directory can work both for the source/bin archives and
the Maven jars.

> sebb>; it's not something
> sebb>that needs to change often, if at all.
>
> When the software is bundled people might have different opinions on the
> folder names.
> If folder name is written explicitly in the license file, it complicates
> bundling of that software.
>
> You are right we don't expect to change JMeter layout often, however the
> ones who bundle JMeter might
> have their own preferences for "licenses" folder name.
>
> They need to reproduce all licenses (including transitive), so they have to
> treat "LICENSE file + licenses" folder as a single
> unit, and I don't think that happens often.

That's not our problem, so long as it is clear where the licenses are.

> Vladimir

Re: LICENSE for third-party software

[Vladimir Sitnikov <si...@gmail.com>]

Hi,

sebb>if version B has and additional dependency compared with version
sebb>A, the single file version will differ by both the additional
sebb>dependency details and potentially the full license text

"combined" LICENSE file could have the following format:
block1) AL-2.0 text
block2) short summary for third-party licenses
block3) full license/notice texts for third-party

Then even the very basic diff tool would properly compare "short summary",
so it would be very easy to tell when dependency is added/removed or
changes license.

Vladimir>"subfolders" Cons: "root" LICENSE becomes position-dependent
sebb>Not sure I follow why this is considered a problem; it's not something
sebb>that needs to change often, if at all.

For instance, jar files typically include LICENSE as  /META-INF/LICENSE.
What should be the location for third-party license files?
It could be /META-INF/licenses/asm-7.1/LICENSE
How that location should be referenced from the summary?

Should it be <<License texts can be found in /META-INF/licenses folder>>?
Should it be <<License texts can be found in /licenses folder>>?

sebb>; it's not something
sebb>that needs to change often, if at all.

When the software is bundled people might have different opinions on the
folder names.
If folder name is written explicitly in the license file, it complicates
bundling of that software.

You are right we don't expect to change JMeter layout often, however the
ones who bundle JMeter might
have their own preferences for "licenses" folder name.
They need to reproduce all licenses (including transitive), so they have to
treat "LICENSE file + licenses" folder as a single
unit, and I don't think that happens often.

Vladimir

Re: LICENSE for third-party software

[sebb <se...@gmail.com>]

On Wed, 17 Jul 2019 at 13:50, Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Hi,
>
> As you might know, bundled dependencies often require an entry in LICENSE
> file.

Correction: there should *always* be at least a minimal entry for each
bundled dependency.
This needs to state the dependency name and version and the License name.
That is the only way to be sure that all the dependencies have been
correctly accounted for.

> Gradle-based build would generate LICENSE file automatically, and i wonder
> if there are preferences for the file format.
>
> There are at least two ways to deal with that.
> As of now, JMeter is using "approach B" (==subfolder for third-party
> licenses), however I find "singlefile" approach is viable as well (and it
> might even be better).
>
> Does anybody have a preference / justification for one approach or another?
> It is really sad, yet I have no strong preference, however I might miss
> some use-cases.
>
> A) Bundle all the licenses to a single LICENSE file.
> For instance: (1MiB file ahead)
> https://github.com/microsoft/vscode-python/blob/master/ThirdPartyNotices-Distribution.txt
> Pros: single file contains all the licensing info
> Pros: LICENSE file is position-independent (it does not reference other
> paths)
> Cons: it complicates the license review (e.g. 1MiB file on a mobile do not
> work well)

It's harder for users to read compared with including a summary of the
license types in the LICENSE file.
Many users will only be interested in the license names (AL 2.0, MIT,
etc.), rather than the exact wording of each license.

> B) Put just references to a root LICENSE file, and include third-party
> license files to a subfolder.
> Pros: it is probably easier to review individual licenses
> Cons: It is harder to compare across different artifacts (e.g. diff for
> 1MiB file just works, and subfolders complicate that)

That depends on the diff tool used and what you are trying to compare.
e.g. if version B has and additional dependency compared with version
A, the single file version will differ by both the additional
dependency details and potentially the full license text (if a
different license). Harder to review.

> Cons: "root" LICENSE becomes position-dependent (for instance, subfolder
> with third-party licenses needs to be baked into the root LICENSE)

Not sure I follow why this is considered a problem; it's not something
that needs to change often, if at all.

> Vladimir