How is your new copyleft license different from the existing ones, e.g. GPL-3 or AGPL?
As someone who's been active in a Linux distributions license team I see such activity with a lot of skepticism.
There are already FOSS licenses for pretty much every wish and many of them are redundant. License proliferation causes more incompatibilities and more work for people who have to decide whether or not something is acceptable in a FOSS environment.
If people ask me what license they should choose the number one advice I give is that they should take something more or less ordinary (Apache, MIT, GPL, CC0), avoid obscure or unclear licenses and absolutely avoid writing up new licenses.
Thanks for your distro work. Skepticism is the proper reflex.
L0-R is being revised, partly as a result of the OSI license-review process. But in general, speaking as of today, it differs from existing copyleft licenses in a few significant ways:
Reciprocity requirements trigger in even more situations than under AGPL. Use with non-OSS modifications, as a component of non-OSS, or to develop non-OSS (the most controversial) falls outside L0-R's license conditions, after a grace period. This is a big extension of AGPL's leap to triggering source provision conditions on use for remote network interaction.
Redistribution, on the other hand, is still permitted with retention or reproduction of terms and notices, a la BSD. So L0-R copyleft "hooks" into aggregated or modified _use_, instead of aggregated or modified _distribution_.
Once copyleft is triggered, L0-R is both more permissive and more strict than existing OSI-approved copyleft licensing.
On the license-terms side, L0-R permits any Open Source license terms, not just the terms of its own license, for follow-on code. That should significantly reduce intractable compatibility blocks. Essentially, it's (A)GPL-3.0 section 13 for the whole OSD roster.
On the source side, L0-R is in flux in its specific language, but aims to require source availability. Originally it was phrased in terms of "publication" of source. Current drafts fall back on the Open Source Definition, which despite itself speaks to source availability, and not just license terms.
If another license is "proliferation" in and of itself, L0-R is proliferation. But I think L0-R proliferates new ideas.
I do not agree that the current OSI-approved roster covers all bases. There is a happy collective medium somewhere between everyone having an OSD-conformant license tailored to their precise needs and preferences, and restricting the community to a very limited palette of approved forms, which is easiest on the receiving end. Open data and tooling---which I've been involved in---make it easier to identify and handle license diversity, make it a software problem. Meanwhile, licenses have fallen down addressing legal, community, and community challenges. MIT, BSD, and ISC aren't good patent licenses. Apache-2.0 isn't hacker friendly, and has its own gotchas. AGPL didn't put so much as a dent in closed-source service.
> Use with non-OSS modifications, as a component of non-OSS, or to develop non-OSS (the most controversial) falls outside L0-R's license conditions, after a grace period.
I'm trying to understand your "controversial" clause. I have doubts this is compatible with any existing definition of FOSS, but maybe I'm misunderstanding.
Does that mean everything I create with a software under that license is under the same license?
To put this into a concrete example: If I have a text processor under that license - does that mean if I use it to write my emails I have to disclose my emails to anyone who is asking, because they're now under a copyleft license?
If you're correct, it's unlikely that this license would be enforceable under current copyright law. This can only work if output contains parts of the copyrighted work (see: Bison's GPL exception).
As someone who's been active in a Linux distributions license team I see such activity with a lot of skepticism. There are already FOSS licenses for pretty much every wish and many of them are redundant. License proliferation causes more incompatibilities and more work for people who have to decide whether or not something is acceptable in a FOSS environment.
If people ask me what license they should choose the number one advice I give is that they should take something more or less ordinary (Apache, MIT, GPL, CC0), avoid obscure or unclear licenses and absolutely avoid writing up new licenses.