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
