On Wed, 17 Jul 2019 at 13:50, Vladimir Sitnikov
<[email protected]> 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

Reply via email to