Re: Fwd: License: GPL-3.0-or-later AND GPL-2.0-or-later

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 14, 2023 at 08:47:36AM -0500, Michael Catanzaro wrote:
> On Tue, Mar 14 2023 at 09:37:25 AM -0400, David Cantrell
> <dcantrell@xxxxxxxxxx> wrote:
> > There may
> > be longer examples.
> 
> Uh, yeah. texlive's is bad enough but I'm skeptical that that's close to a
> worst-case. Proponents of this style of license tag should try this exercise
> for WebKitGTK, Chromium, Firefox, LibreOffice, Inkscape, or Linux kernel and
> report back. Even if you somehow succeed once, ***your result will become
> stale each time the package gets rebased***. We're real bad at keeping the
> existing *simple* license fields updated so there's just no way we'll be
> able to handle the complex version.

We are bad at this, which is one of the big reasons we worked to revise the
current guidelines and process.  By moving to SPDX, Fedora gets out of the
business of not only having to maintain a list of identifiers and consistently
using them, but also coming up with what those identifiers are.  SPDX takes
care of the second part for us by giving us a list and a standard to make
project-specific non-colliding identifiers.

> Even for simple packages, there is no way anybody would ever be able to rely
> on the License field for any purpose: companies will have to do their own
> checks anyway. Maybe we should just remove it instead of pretending that
> it's accurate?

We can't get rid of the License tag, unfortunately.  See:

https://www.linuxfoundation.org/blog/blog/spdx-its-already-in-use-for-global-software-bill-of-materials-sbom-and-supply-chain-security

And as part of the US Executive Order on Cybersecurity, we need to start using
SPDX identifiers in software we package and provide so that our downstream
users are in compliance:

https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

Software licenses are hard, but trust me when I say that all of the work that
has gone in to revising Fedora's license policies for packages has been done
to relieve developers and package maintainers of the complicated legal work.

As a software developer, I find licensing tedious and sometimes not that
interesting.  *but* I want to know that I am using a license that (a) keeps my
source code open, (b) allows others to use it and benefit from it, and (c)
does not prevent problems for downstream users.

-- 
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux