On Wed, Oct 12, 2022 at 10:36:02AM +0200, Thomas Wolff wrote: > > > Am 11/10/2022 um 22:13 schrieb Brian Inglis: > > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > > I'm trying to upload a new version of git-filter-repo, and took the > > > opportunity to set the LICENSE value in the cygport file. The new value > > > looks valid according to my reading of the SPDX specification, but is > > > being rejected by calm. > > > The license for git-filter-repo is a bit complicated, because different > > > parts have different licenses, and several of them aren't "normal" > > > licenses. The license is described at [0] and files referenced / linked > > > from there. > > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > > I've encoded this as the somewhat verbose > > > LICENSE='(MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) > > > AND GPL-2.0-only' > From a mere Boolean perspective, this looks redundant and should be > simplified to > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) > AND GPL-2.0-only'
Hmm. You're obviously correct from a Boolean logic perspective, but my aim was to provide something more information-rich than a purely Boolean statement. Specifically, each file within the packages produced by this cygport script will be covered by one of the and-joined statements. Some files are GPLv2, some are MIT, "inherit-git" or "inherit-libgit2", and some are MIT, "inherit-git", "inherit-libgit2" or "inherit-libgit2-examples". Removing "inherit-libgit2-examples", as logically simplifying the statement would do, in my mind implies that license isn't at all relevant, even though it does apply to some parts of git-filter-repo. Which version is preferable probably comes down to the intent of the LICENSE value in the cygport file and in the various places that consume that information, either now or in future. If it's intended significantly for human consumption, having the information-rich version may be useful; if it's intended primarily for machine consumption, the simplified version would probably be preferable. >From digging around the SPDX specifications and examples a bit, I think we're already some distance away from the intent of SPDX. If you look at [0], for example, you can see detail is given separately for the source and compiled code, and within each of those, the license information is specified separately for each file. Using a single license string for -- potentially -- multiple packages means we're much more likely to encounter this sort of problem, as it's much more likely that different packages produced by the same cygport file, or different files within each package, are going to be covered by different licenses. [0]: https://github.com/spdx/spdx-examples/tree/master/example4/spdx
