Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
I had given a little thought to the idea in the past, but while I was on the OSI board (2013-2019) I considered it to be inappropriate.
Richard
I would presume that only happens when the license is thought to be ready to be applied to some actual software project. Is it at that state?
Otherwise, I think OSI has mailing lists where licenses could be discussed in order to broaden the conversation prior to submission for approval.
On 2020-02-13 9:03 a.m., Richard Fontana wrote:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
I had given a little thought to the idea in the past, but while I was on the OSI board (2013-2019) I considered it to be inappropriate.
Richard _______________________________________________ copyleft-next mailing list -- copyleft-next@lists.fedorahosted.org To unsubscribe send an email to copyleft-next-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/copyleft-next@lists.fedorahoste...
On Thu, 13 Feb 2020 at 10:03, Richard Fontana fontana@sharpeleven.org wrote:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
I'd say yes. IMHO it's a great little license, and even just the act alone of submitting for OSI approval will increase its visibility, and help with the chicken-and-egg problem licenses face in growing (including by potentially mollifying any concerns folks might have about an "untested" license).
And, to the degree that it might not be mature or fully-considered enough (which I personally doubt, but I'm just an amateur enthusiast and not a lawyer, it must be said!) then the potential feedback from the OSI review process is all the more valuable.
Would that imply having a blessed 1.0 release at some point?
On Thu, Feb 13, 2020 at 9:03 AM Richard Fontana fontana@sharpeleven.org wrote:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
I had given a little thought to the idea in the past, but while I was on the OSI board (2013-2019) I considered it to be inappropriate.
Richard _______________________________________________ copyleft-next mailing list -- copyleft-next@lists.fedorahosted.org To unsubscribe send an email to copyleft-next-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/copyleft-next@lists.fedorahoste...
On Thu, Feb 13, 2020, 12:03 Richard Fontana fontana@sharpeleven.org wrote:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
If that number is 1.0, I'd say it should start the approval process. If the number still starts with a zero, getting some feedback on license-discuss sounds like a good idea.
Or to put it another way: is there anything significant that still needs to be added or reworked?
I'm inclined to say "let's tag 1.0rc1" and see what happens.
On Thu, Feb 13, 2020 at 04:59:18PM -0500, Ben Cotton wrote:
On Thu, Feb 13, 2020, 12:03 Richard Fontana fontana@sharpeleven.org wrote:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
If that number is 1.0, I'd say it should start the approval process. If the number still starts with a zero, getting some feedback on license-discuss sounds like a good idea.
Or to put it another way: is there anything significant that still needs to be added or reworked?
Looking at https://github.com/copyleft-next/copyleft-next, one thing which really strikes me as missing is the collateral material. The 1.0 release and the OSI approval will cause a lot of people to take a look. So they'll do a Google search, and find the github repository.... and not much else. Yes, there are are some interviews from 2012[1] and 2013[2], but I'd claim that's not enough.
[1] https://www.datamation.com/open-source/copyleft.next-and-the-future-of-gnu-g... [2] https://lwn.net/Articles/537559/
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:
* What makes this license different from all other licenses?
* Why should I consider using the copyleft-next license? What are its benefits?
* What licenses is this licenses compatible with? Incompatible with?
* How does copy-left-next work in dual-licensing scenarios?
* What are potential pitfalls if I take an existing codebase and covert it to copyleft-next?
Cheers,
- Ted
On Thu, Feb 13, 2020 at 4:28 PM Theodore Y. Ts'o tytso@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_94aKLsO... [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
On Fri, Jul 2, 2021, at 3:30 PM, Luis Chamberlain wrote:
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?
I've gone through the process to get SPDX identifiers for copyleft-next back in 2018 (and the process changed shortly afterward):
- https://spdx.org/licenses/copyleft-next-0.3.0.html - https://spdx.org/licenses/copyleft-next-0.3.1.html
Only these two versions were added, as older versions did not seem to have been published when the license was still actively being developed, and haven't been used much in software projects.
-- Kuno.
On Fri, Jul 2, 2021 at 1:30 PM Luis Chamberlain mcgrof@kernel.org wrote:
// SPDX-License-Identifier: GPL-2.0-or-later
Just figured I'd provide an update at the the correct SPDX tag would actually be:
// SPDX-License-Identifier: GPL-2.0-or-later OR copyleft-next 0.3.1
I had failed to notice that we *do* provide "OR" lines on SPDX lines.
Luis
Two years on, I'm reviving this thread:
Richard Fontana wrote back in mid-2020:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
A summary of the two most salient points (IMO) from downthread are:
(0) copyleft-next doesn't have a enough meta-material / collateral material / advocacy-why-this-license-is-good material. Get that first before submitting.
(1) copyleft-next should be 1.0 before submitting it to OSI, purely for perception reasons (i.e., we could rebrand existing draft as 1.0)
Adding my $0.02:
IF: the OSI is willing to consider, and ultimately approve licenses that were just recently written by a lawyer for a single client that tread new territory and are not well vetted by the larger community (aka Van Lindberg's so-called Cryptographic Autonomy License, see https://lwn.net/Articles/797065/ , and also, Mark Radcliffe's CPAL from long ago — same situation then)
THEN: I don't see any reason why they shouldn't accept copyleft-next, since it's had 100% public discussion since its inception, has major contributions from at least five different FOSS licensing experts, has minor contributions from lots of folks, and really isn't too many new licensing concepts — just bringing together ones already widely discussed in pro-copyleft circles.
… but I also know there is rarely justice in the world, so I could easily be surprised by OSI on this and they could reject us, which would look bad (on them as much as it did on copyleft-next).
Point (0) above (again, details downthread) though, isn't really about having that material available *for* OSI to approve, but rather, to have it ready when OSI does approve as a method to advocate and educate about copyleft-next. That does seem indeed useful.
(HBR cure: Luis Chamberlain, Fontana and I had a private side-thread discussion about submitting to OSI that mainly was just discussion of the ever-shifting requirements of OSI, and debate about whether OSI approval really is *that* important. Luis may post additional HBR cure if needed.).
-- bkuhn
On May 25, 2022, at 8:53 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
Two years on, I'm reviving this thread:
Richard Fontana wrote back in mid-2020:
Does anyone have an opinion on whether copyleft-next (presumably the most recent numbered release) should be submitted for OSI approval?
A summary of the two most salient points (IMO) from downthread are:
(0) copyleft-next doesn't have a enough meta-material / collateral material / advocacy-why-this-license-is-good material. Get that first before submitting.
(1) copyleft-next should be 1.0 before submitting it to OSI, purely for perception reasons (i.e., we could rebrand existing draft as 1.0)
Adding my $0.02:
IF: the OSI is willing to consider, and ultimately approve licenses that were just recently written by a lawyer for a single client that tread new territory and are not well vetted by the larger community (aka Van Lindberg's so-called Cryptographic Autonomy License, see https://lwn.net/Articles/797065/ , and also, Mark Radcliffe's CPAL from long ago — same situation then)
THEN: I don't see any reason why they shouldn't accept copyleft-next, since it's had 100% public discussion since its inception, has major contributions from at least five different FOSS licensing experts, has minor contributions from lots of folks, and really isn't too many new licensing concepts — just bringing together ones already widely discussed in pro-copyleft circles.
… but I also know there is rarely justice in the world, so I could easily be surprised by OSI on this and they could reject us, which would look bad (on them as much as it did on copyleft-next).
Point (0) above (again, details downthread) though, isn't really about having that material available *for* OSI to approve, but rather, to have it ready when OSI does approve as a method to advocate and educate about copyleft-next. That does seem indeed useful.
(HBR cure: Luis Chamberlain, Fontana and I had a private side-thread discussion about submitting to OSI that mainly was just discussion of the ever-shifting requirements of OSI, and debate about whether OSI approval really is *that* important. Luis may post additional HBR cure if needed.).
-- bkuhn
At this point I would say just go ahead and do it.
Stephen Michael Kellat
copyleft-next@lists.fedorahosted.org