This discussion might be clearer.[1] [1] https://issues.apache.org/jira/browse/LEGAL-323
On Mon, Nov 25, 2024 at 7:18 PM Calvin Kirs <k...@apache.org> wrote: > > > On Mon, Nov 25, 2024 at 6:25 PM Bertil Chapuis <bchap...@gmail.com> wrote: > >> Hello Calvin, >> >> Are you referring to the following email? I struggled to find a reference >> to Netty in the dev mailing-list, but this one related to Hadoop seems to >> be the most closely related. >> https://lists.apache.org/thread/h8bbvwm5l9c5n9gzs4prhkrcmj9q5js1 >> >> As mentioned, I’ve observed different practices among top-level Apache >> projects. For example, Hadoop and Spark include LICENSE, LICENSE-binary, >> NOTICE, and NOTICE-binary files, as well as license and >> license-binarydirectories. While we could introduce similar directories in >> Baremaps, I’m concerned that they might quickly become outdated, given that >> we lack the same level of resources as these large projects. Moreover, even >> in Hadoop’s case, these files and directories haven’t been updated for four >> to five years. >> > Yes, but that's something you have to do when releasing binary versions. > I'm not sure if providing a link to indicate the license source in the > LICENSE file would be acceptable. For example, with the MIT License: "The > above copyright notice and this permission notice shall be included in all > copies or substantial portions of the Software." I don't think providing > just a link would work, but perhaps you could check with the ASF legal > team. > > > >> On the other hand, other top-level projects that depend on Hadoop and >> Spark (e.g., Drill, Sedona, etc.) seem to follow a simpler approach similar >> to ours: a LICENSE file listing the dependencies and their licenses. Their >> NOTICE files also don’t appear to include additional information (though I >> could be overlooking something). >> > > Not all practices of top-level projects are necessarily correct. I haven't > kept up with Sedona, but I raised this issue with Drill last year[2]. > > [1]https://infra.apache.org/licensing-howto.html#binary > [2]https://issues.apache.org/jira/projects/DRILL/issues/DRILL-8475 > >> >> I’d prefer to stick with the simple approach (which is already quite >> time-consuming :-) as it aligns with what many other projects are doing. If >> this approach isn’t sufficient, I’d really appreciate gathering broader >> input so we can define something actionable and maintainable for this >> release and future ones. >> >> Best regards, >> >> Bertil >> >> >> >> >> > On 25 Nov 2024, at 04:41, Calvin Kirs <k...@apache.org> wrote: >> > >> > Hi Bertil, >> > >> > In addition to what Justin mentioned, I brought up in the dev mailing >> list >> > that the binary release is missing the NOTICE section (at least we >> omitted >> > the NOTICE for Netty). >> > The LICENSE file is also missing and needs to be addressed in the next >> RC >> > version. >> > >> > On Sun, Nov 24, 2024 at 10:40 PM Bertil Chapuis <bchap...@gmail.com> >> wrote: >> > >> >> Hello Justin, >> >> >> >> I believe I now have enough information to release a new candidate. I’m >> >> closing this vote and will start a new one early next week. >> >> >> >> Here is a summary of the corrections I made: >> >> - Removed the unlicensed fuji.png file and fixed the related tests. >> >> - Added a missing license header to scripts/generate-flageobuf.sh. >> >> - Revised the notice file to ensure all paths are correct. >> >> - Configured Spotless to ignore third-party files and added original >> >> license headers. >> >> - Created a licenses directory and added copies of third-party >> licenses. >> >> - Replaced the URLs in the LICENSE file with pointers to these local >> files. >> >> - Included these new files in the assembly configuration. >> >> >> >> These changes are listed here (I will probably squash them into a >> single >> >> release commit): >> >> https://github.com/apache/incubator-baremaps/pull/905/files >> >> >> >> Thank you very much for helping with these changes. Please don't >> hesitate >> >> to provide additional feedback if needed. >> >> >> >> Best regards, >> >> >> >> Bertil >> >> >> >>> On 23 Nov 2024, at 22:50, Justin Mclean <jus...@classsoftware.com> >> >> wrote: >> >>> >> >>> HI, >> >>> >> >>>> According to the documentation [1], what’s currently missing in our >> >> LICENSE file are pointers (“For details, see deps/flatgeobuf”). I >> suggest >> >> to modify the third party section as follow, so we have pointers for >> >> everything. >> >>>> >> >>>> THIRD PARTY LICENSES: >> >>>> >> >>>> Code and data produced outside the ASF that is included in the >> >>>> distribution of this product is subject to the following >> >>>> additional license terms: >> >>>> >> >>>> - FlatGeobuf, BSD-2-Clause license, see >> >> https://github.com/flatgeobuf/flatgeobuf. >> >>>> - GeoPackage Java, MIT License, see >> >> https://github.com/ngageoint/geopackage-java. >> >>>> - OSMPBF, MIT License, see >> >> https://github.com/openstreetmap/OSM-binary/pull/35. >> >>>> - OSM Test Data, Public domain, see >> >> https://github.com/osmcode/osm-testdata. >> >>>> - Mapbox Vector Tile, Creative Commons Public License, see >> >> https://github.com/mapbox/vector-tile-spec. >> >>>> - Palantir Streams, Apache License 2.0, see >> >> https://github.com/palantir/streams. >> >>>> - Planetiler, Apache License 2.0, see >> >> https://github.com/onthegomap/planetiler. >> >>>> - PMTiles, BSD-3-Clause license, see >> >> https://github.com/protomaps/PMTiles. >> >>>> - pyosmium, BSD 2-Clause "Simplified" License, see >> >> https://github.com/osmcode/pyosmium. >> >>> >> >>> While knowing where the files come from is useful (and it would be >> best >> >> to keep that info), the “pointers” mentioned need to be to local files >> >> containing the license text in full, not to a URL whose content may >> change. >> >> This is usually a condition of the license that you need to include its >> >> text when distributing it. >> >>> >> >>>> The reason for the notice file is that we never “bundled” a whole >> >> project into baremaps. Instead, we derived and adapted a couple of >> files >> >> from third party projects and included them in our sources. This is the >> >> reason why we found useful to tell more about it in the NOTICE file. >> >>> >> >>> Even if you bundle a single file or a single function from a 3rd party >> >> project, that license information would still go in LICENSE, not >> NOTICE. >> >>> >> >>>>> It can be placed in the LICENSE file, or you can have the LICENSE >> file >> >> provide a pointer to it in the artifact, e.g. some projects create a >> >> licenses directory and put all 3rd party licenses in that. >> >>>> >> >>>> So I guess the pointers listed above should be sufficient. >> >>> >> >>> Nope, you need to include the full license text somewhere. >> >>> >> >>> Kind Regards, >> >>> Justin >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> >> >> > >> > -- >> > Best wishes！ >> > CalvinKirs >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > > -- > Best wishes！ > CalvinKirs > -- Best wishes！ CalvinKirs
