Re: clarification on -only and -or-later

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

 



We should take care not to conflate changes made because: (a) all
relevant copyright holders consented, vs. (b) consent not available from the
copyright holders.  (a) and (b) differ greatly, both politically and legally.

With (a), we can certainly ask copyright holders for any notice changes that
seem useful, expedient, and would help Linux as a project.  (e.g., if, as
Thomas says, Red Hat is sole copyright holder of some code and agrees to
relicense it from GPL-1.0-or-later to GPL-2.0-or-later, I see no reason not
to gleefully accept that and make the change (copyright holders assent
well-documented in the commit log with relevant Signed-Off-By: , of course).
Similarly, (to "cross" the two active threads a bit), that we really have no
worries about old-notice-preservation if all relevant copyright holders
assents to replace their old notice with an SPDX Identifier.

However, with (b), judgment and risk analysis, both of legal and political
nature, will always be required.

During the "Great SPDX GPL Identifier Change" last year, Jilayne and I dug
deep on the legal judgment/risk-analysis about some of these notices -- in
collaboration with FSF (as license steward) and many others in the FOSS
licensing community -- to come to conclusions about the two ambiguous cases
Jilayne listed as (1) and (3) initially in this thread.  Jilayne's
suggestions for these cases were presumably informed by that, and I suspect
that's why she's recommending them as -or-later conclusions.

Nevertheless, if there is political risk (or even, as Greg points out,
annoying work not worth doing) involved with moving GPL-1.0-or-later code to
(say) GPL-2.0-or-later instead, then there is no reason to do so.
Furthermore, such a change also relates to this point:

There is danger of taking things that legal analysis concludes are
'-or-later' and turning them into '-only'.  Narrowing from '-or-later' to
'-only' is always permitted by downstream (and also the effective license of
the whole work of Linux will undoubtedly remain GPL-2.0-only).  However, so
many people have expressed a desire for accurate, complete, and
as-broad-as-legally-possible file-by-file licensing inventory.  This project
exists, presumably, to serve those requests.  We should strive to make sure
that, on a "file-by-file level", this project doesn't inadvertently narrow
permissions unduly.  Furthermore, combining the work of notice-replacement
with license *changing* adds undue risk; the two activities should be fully
separated by both time and workflow.

If the upshot of this *also* means we live with more GPL-1.0-or-later
notices floating around, I don't think it's that big of a deal.  Better
that than annoyed contributors, and, more importantly, downstream users
who wish to take a the more liberal license for some code in the Linux tree,
etc.

As always, IANAL and TINLA,
--
Bradley M. Kuhn

Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux