[copyleft-next] copyleft-next 0.3.0 released

Richard Fontana fontana at sharpeleven.org
Sat May 18 03:23:47 UTC 2013


On Fri, May 17, 2013 at 03:31:24PM +0200, Antoine Pitrou wrote:

> I have a couple of questions about it:
> 
> >   If I offer to license, for a fee, a Covered Work under terms other than
> >   a license that is OSI-Approved or FSF-Free as of the release date of this
> >   License or a numbered version of copyleft-next released by the
> >   Copyleft-Next Project, then the license I grant You under section 1 is no
> >   longer subject to the conditions in sections 2 through 5.
> 
> Is it desirable? 

I have assumed so. There is a good argument that (at this advanced
stage of FLOSS history) it merely serves to make a symbolic or
political statement and as such is just taking up space, but I don't
fully agree with that argument.

> What if, in a collectively owned FLOSS project, a single
> contributor
> decides to re-use one of their contributions for a closed source project?
> Does it
> impact the collectively owned FLOSS project as a whole?

That's an interesting question. I believe I initially misunderstood
it. I currently believe when you say 'collectively owned' you do not
mean something like the US copyright law concept of joint ownership
but rather 'typical FLOSS project with diversity of copyright
ownership and absence of copyright ownership or outbound licensing
power aggregation'.

So I think what you are asking about is the case where you have a
normal FLOSS project, with diversity of copyright ownership, and a
contributor contributes a patch, say, and the patch has to be licensed
under copyleft-next (this may be so by operation of section 6, the
'symmetrical licensing' provision). So then the contributor separately
uses the same copyrightable patch in some closed source project.

Let me first note that the provision in question is obviously directed
at a more narrow sort of conduct than the language suggests; it is
meant to discourage copyright-aggregating licensors from using
copyleft-next as the FLOSS licensing instrument in a
revenue-generating dual-licensing or open core scheme. The reason the
language is broader is that to narrow it would (I think) make the
provision lengthier and more inelegant.

I believe you have discovered what I think is at most a harmless
problem that results from that generality of language. The worst that
can happen in your hypothetical is that the project the contributor
contributed to gets to use the patch under permissive-next, so to
speak, instead of copyleft-next. This makes section 6 superfluous in
that case. But it doesn't somehow cause an entire version of the work
released by the project and incorporating the contributor's patch to
be under permissive-next. Moreover, I believe that the bigger the
contribution, the more just it would be for this 'error' to occur, so
in other words the error remains harmless as the contribution gets
more significant. Though maybe I'm wrong about that.

Let us suppose that this version reflects 100 contributions from 100
copyright holders, one of which is this person's patch. Then the
recipient of this version is getting 99 copyleft-next licenses, each
of which applies only to such contributor's copyright interest, and
one permissive-next license covering this person's patch. 

But if I have misunderstood the issue, or have correctly understood it
but am overlooking something important, please let me know.

Thanks,
- RF



More information about the copyleft-next mailing list