On Thu, Feb 13, 2020 at 4:28 PM Theodore Y. Ts'o <tytso(a)mit.edu> wrote:
Take it from the perspective of project leader, either for a new or
existing OSS project. There are going to be a couple of things that
such a project leader might ask:
I've embraced copyleft-next for most of my own projects, including new
Linux drivers. And so I figured I'd share a few of my own answers to
the questions below. These are of course observed as a developer, not
an attorney, but I think that's probably the language / things which
some other developers may want to read. I hope this might be helpful.
Feel free to use / adopt as you see fit to help with this effort.
* What makes this license different from all other licenses?
The evolution of the license parallels the evolution of software
projects, all done on a mailing list. There is not only an effort, but
a strict push as part of the ethical code stipulated on the evolution
of the license so that all things are discussed in public, the
so-called "Harvey Birdman Rule". This means anything related to shady
backroom deals are extremely frowned upon, and so it keeps those used
to those shenanigans away which can only be good for our ecosystem.
There is also a separation between "church and state", if you will,
ie, copyleft-next has nothing to do with the FSF. There is also no
corporate incentive behind it. It is grown purely out of love for
simplicity and evolution of copyleft.
* Why should I consider using the copyleft-next license? What are
its
benefits?
If you enjoy copyleft and simplicity, this brings both, and its
evolution together.
One of the other reasons I personally like the license is it lets me
contribute dual licensing GPLv2/copyleft-next to a larger GPLv2
project such as Linux, and yet know I can take code out and use only
copyleft-next for copyleft-next licensed projects. If you're an
advocate of advancing copyleft you could have thought it was rather
impossible to bridge advances in copyleft beyond GPLv2, if you
contributed mostly to GPLv2 projects. For example, you can't keep the
GPLv2 of a project if you contribute, say AGPL licensed code to it.
But with copyleft-next we can, and Linux is a perfect example of that.
The GPLv2 applies when used in Linux, but since the dual license
language was in the end preferred, it also also means I can take code
from such projects to outside copyleft-next only projects, and advance
copyleft that way.
* What licenses is this licenses compatible with? Incompatible with?
I did the legwork to get RedHat and SUSE to review compatibility with
GPLv2 and that's why I ended up using it for Linux. I can't speak
about others.
* How does copy-left-next work in dual-licensing scenarios?
At least for Linux, we have discussed this prospect since 2016 and in
July 2017 I made my first two driver submissions which are not part of
upstream Linux. We have a MODULE_LICENSE() thing, and so Linus'
preference was that we make it clear that GPLv2 applies with it [0],
and so for that macro we use MODULE_LICENSE("GPL"). Then as per
discussion I ended up embracing an "or" language to air on the side of
caution [1]. The first 2 drivers I added to Linux, lib/test_sysctl.c
and lib/test_mod.c, were prior to us embracing the SPDX tag and so
they didn't get the SPDX license tag. I'm adding a new driver this
month, I just posted patches about lib/test_sysfs.c last night [2] and
it's going with the SPDX license tag:
// SPDX-License-Identifier: GPL-2.0-or-later
Because as with the MODULE_LICENSE("GPL") tag, the SPDX tag clarifies
even more that GPLv2 applies when used on Linux. As per our guidelines
for SPDX, when dual licensing is used you still keep some boilerplate,
and so I do that as well to make it clear that copyleft-next projects
can benefit.
I don't think we have an SDPX license tag for copyleft-next yet? And
so projects where only copyleft-next applies may not have an SPDX
license tag available until that becomes available. Anyone know what
the process to get one is?
[0]
https://lore.kernel.org/lkml/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aK...
[1]
https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com
[2]
https://lkml.kernel.org/r/20210702050543.2693141-1-mcgrof@kernel.org
* What are potential pitfalls if I take an existing codebase and
covert it to copyleft-next?
I haven't heard of one. In fact, just recently someone was about to
try to contribute some AGPL code to one of my projects, a GPLv2
project, kdevops, but I postulated as a compromise embracing
copyleft-next instead, so we get the benefits of both worlds. If there
are drawbacks I'd love to hear about them.
Luis