On Sat, Dec 9, 2023 at 6:48 PM Mark Wielaard <mark@xxxxxxxxx> wrote: > > SPDX is community-driven project. Under Linux Foundation. With all > > materials open and all decisions done in public. > > Even if it is, then it is still problematic to request Fedora > contributors to file issues in these external third-pary proprietary > trackers. I agree that this is problematic though we are already using a third-party proprietary system (gitlab.com) to host the Fedora License Data repository, so does the fact that SPDX is hosted on GitHub really make things materially worse? (Surely the fact that gitlab is open core shouldn't make much of a difference for use of their hosted version, though I get the sense that some people feel this way.) I personally wouldn't be opposed to hosting Fedora License Data on pagure.io (or finding some other FOSS solution) but I think some others on the team would. :) If anyone objects to direct use of GitHub, we can file issues on their behalf. Same goes for anyone who objects to gitlab.com. I'll make a note to put this in the Fedora legal documentation. > Also we never just relied on third parties even if we > closely worked together with the FSF and OSI, Fedora never really worked closely with the OSI. It did, at one time, work closely with the FSF's license compliance lab, during the Brett Smith era, but that was well over a decade ago. But this is a concern I had too - when we started this I was worried about SPDX taking too long to review issues coming from Fedora. This has actually not turned out to be a significant problem in practice. The delays in the process have had more to do with things on our side. > Fedora always reviewed > more licenses than either of them, and I doubt the SPDX project will > either. Over the past year and a half, I believe SPDX has made an unprecedented expansion of the SPDX license list and this is mostly due to SPDX accommodating issues from Fedora. Also, SPDX is a standard that does not lock us in to the SPDX license list. We can bypass the SPDX license list inclusion process by using Fedora-defined `LicenseRef-` identifiers, and indeed we have done this in quite a few cases (including for allowed licenses). The current policy is to aim for SPDX license list inclusion at least for all Fedora-allowed FOSS licenses. This is less a benefit for Fedora than it is for SPDX and the larger community that is likely to make increasing use of SPDX identifiers. Also, in an extreme scenario (for example, if the SPDX project dies out or becomes impossible to work with) we can fork SPDX, or more precisely the limited aspects of SPDX that are relevant to Fedora. > I don't mind the SPDX project trying to create a collection of Free > Software licenses with comment identifier names that can be used to > refer to them. But some of the other things they seem to promote, like > these SBOMs, feel like just setup to promote proprietary software > "based on" Free Software (without a commitment to make sure the user > will actually get the complete and corresponding source code). I > cannot say I can get very excited about that. I don't especially like SBOMs either, and I don't think SBOMs have any relevance to Fedora, but I don't think this is a good argument for not using the SPDX license expression standard, which is really separate from other aspects of the SPDX project. Richard -- _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
