Add the Planetiler NOTICE to the project's NOTICE file.

[CalvinKirs]

For modifications to third-party original files, we typically need to reflect these changes in the root directory's NOTICE file.

The License file can be implemented through referencing. However, the NOTICE file does not explicitly state this. Under the AL2, it is explicitly required to include third-party NOTICE files in the NOTICE if the modified third-party project contains a NOTICE.

[bchapuis]

The part of Planetiler integrated into Apache Baremaps is a fast, memory-mapped data structure solely released under the Apache License, which is unrelated to the software mentioned in their NOTICE file. Therefore, I have integrated the reference to Planetiler directly into our main LICENSE file and left the copyright in all the adapted files. I applied the same approach to all the code adapted from third party projects (e.g. Palantir Stream). In the last release, we also added a notice/ and notice-binary/ directory to carry these files in the release.

I may be wrong, but I think adding appending this NOTICE to our main NOTICE may create confusion. For instance, the Planetile NOTICE file mentions GeoTools (LGPL) and EPSG (proprietary), which are are incompatible with the Apache License.

incubator-baremaps/LICENSE

Line 219 in c811515

- Planetiler, Apache License 2.0, see licenses/planetiler.

We spent a significant amount of time finding alternatives and rewriting code from scratch to completely remove these incompatible dependencies in Apache Baremaps. Leaving these references feels like a footgun and may give people who discover the project the impression that we rely on Apache-incompatible code. I’d be happy to get your opinion on this and of the other mentors in this discussion (cc @julianhyde, @bdelacretaz, @desruisseaux).

[CalvinKirs]

The part of Planetiler integrated into Apache Baremaps is a fast, memory-mapped data structure solely released under the Apache License, which is unrelated to the software mentioned in their NOTICE file. Therefore, I have integrated the reference to Planetiler directly into our main LICENSE file and left the copyright in all the adapted files. I applied the same approach to all the code adapted from third party projects (e.g. Palantir Stream). In the last release, we also added a notice/ and notice-binary/ directory to carry these files in the release.↳

I may be wrong, but I think adding appending this NOTICE to our main NOTICE may create confusion. For instance, the Planetile NOTICE file mentions GeoTools (LGPL) and EPSG (proprietary), which are are incompatible with the Apache License.

incubator-baremaps/LICENSE

Line 219 in c811515

- Planetiler, Apache License 2.0, see licenses/planetiler.

We spent a significant amount of time finding alternatives and rewriting code from scratch to completely remove these incompatible dependencies in Apache Baremaps. Leaving these references feels like a footgun and may give people who discover the project the impression that we rely on Apache-incompatible code. I’d be happy to get your opinion on this and of the other mentors in this discussion (cc @julianhyde, @bdelacretaz, @desruisseaux).

We should include only this.

This product contains code from Planetiler project

## Licenses

Planetiler licensed under the Apache license, Version 2.0

Copyright 2021 Michael Barry and Planetiler Contributors.

[CalvinKirs]

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, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places:

https://www.apache.org/licenses/LICENSE-2.0 4. Redistribution.

[bchapuis]

Great explanation 👍 this works well for me and will avoid ambiguities. Do not hesitate to update and squash merge.

[bchapuis]

Shall we remove the notice directory and keep only the notice-binary? Or does it make sense to keep everything for reference.

[CalvinKirs]

Shall we remove the notice directory and keep only the notice-binary? Or does it make sense to keep everything for reference.

yes, but for the binary distribution, I’m unsure if the current binary NOTICE is viable or if referencing the binary NOTICE via a pointer is acceptable. Apologies if I’m being overly cautious—it’s just that this involves legal matters.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[CalvinKirs]

Shall we remove the notice directory and keep only the notice-binary? Or does it make sense to keep everything for reference.↳

yes, but for the binary distribution, I’m unsure if the current binary NOTICE is viable or if referencing the binary NOTICE via a pointer is acceptable. Apologies if I’m being overly cautious—it’s just that this involves legal matters.↳

@bchapuis Could you create a ticket for the legal team to consult on this issue? https://issues.apache.org/jira/projects/LEGAL/

[bchapuis]

@CalvinKirs I think it's good to be cautious, and I also apologize for the amount of work that results from my questions. In this regard, how would you frame the question to the legal team? Personally, I feel quite comfortable with the current solution, as we include all the NOTICE files in our binary distribution, which seems in line with what other projects are doing.

The current solution is already hard to maintain and will probably require a couple of hours of manual work per release to keep it up to date. What worries me is that the proposed solution will be even more impractical in terms of maintenance, without addressing the fundamental issue of licensing.

To illustrate my current understanding, here is a description of the maintenance steps involved: When updating a dependency, we should obtain the latest NOTICE file, audit it, retain the meaningful parts, and copy it into the NOTICE-binary directory. I didn't update the dependencies in version 0.8.2 for this reason.

I believe this is why, even in top-level projects, these NOTICE-binary directories (or concatenated files) quickly become outdated. Overall, even if these practices make a few people more comfortable, they are probably a lose-lose situation for both maintainers and legal specialists, as outdated NOTICE files would likely not survive a serious audit.

[CalvinKirs]

@CalvinKirs I think it's good to be cautious, and I also apologize for the amount of work that results from my questions. In this regard, how would you frame the question to the legal team? Personally, I feel quite comfortable with the current solution, as we include all the NOTICE files in our binary distribution, which seems in line with what other projects are doing.↳

The current solution is already hard to maintain and will probably require a couple of hours of manual work per release to keep it up to date. What worries me is that the proposed solution will be even more impractical in terms of maintenance, without addressing the fundamental issue of licensing.↳

To illustrate my current understanding, here is a description of the maintenance steps involved: When updating a dependency, we should obtain the latest NOTICE file, audit it, retain the meaningful parts, and copy it into the NOTICE-binary directory. I didn't update the dependencies in version 0.8.2 for this reason.↳

I believe this is why, even in top-level projects, these NOTICE-binary directories (or concatenated files) quickly become outdated. Overall, even if these practices make a few people more comfortable, they are probably a lose-lose situation for both maintainers and legal specialists, as outdated NOTICE files would likely not survive a serious audit.↳

I completely understand, and to be honest, some TLPs barely maintain their binaries NOTICE/LICENSE. One reason is exactly what you mentioned. I've created a ticket to discuss this issue, and you're welcome to add any additional thoughts directly on the JIRA. If the legal team allows this approach, it would make things significantly easier for many projects.

https://issues.apache.org/jira/browse/LEGAL-697

[bchapuis]

Thanks a lot for opening the issue 👍

[bchapuis]

@CalvinKirs Thanks for merging. So if I understand correcly the discussion, we should have a single NOTICE-binary file in the repository instead of directory and clean the irrelevant parts.

[CalvinKirs]

@CalvinKirs Thanks for merging. So if I understand correcly the discussion, we should have a single NOTICE-binary file in the repository instead of directory and clean the irrelevant parts.

yes