[copyleft-next] copyleft-next 0.2.0 released

Richard Fontana fontana at sharpeleven.org
Thu Feb 21 05:40:46 UTC 2013


On Wed, Feb 20, 2013 at 01:35:44PM +0000, Gervase Markham wrote:
> Some licensing documents disclaim e.g. the application of the United
> Nations Convention on Contracts for the International Sale of Goods. Do
> they have good reason to do so, 

I don't actually know. I confess that as far as I can recall I've
never looked at that Convention. The most coherent argument I have
heard from a lawyer on this point was something to the following
effect: 'no one really knows what's in that Convention, or whether it
applies to software, but whatever is in it might be bad' (paraphrasing
heavily of course). I think the main reason we see this being excluded
is because someone initially decided to do so and this started a
process in which lawyers drafting licensing agreements all followed
suit.

> and we are _sure_ there are no rights of
> this sort we want to limit?

No, but if there were we'd want to do it explicitly (like the licenses
dealing with the UN Convention do).
 
> * "in a manner that fails to satisfy the Open Source Definition
> published by the Open Source Initiative as of 1 January 2013"
> 
> Who decides? That sounds like a recipe for lawyer argument. Is it better
> to refer to the OSI license list as of a certain date instead?

That was essentially what an earlier release did (IIRC). I'm really
trying to define what 'proprietary licensing' is and I don't know a
good way to do it. And the goal here isn't perfection, but rather to
ward off practitioners of certain kinds of business models. I just
want a way to signal "keep away" to a certain kind of potential
licensor. The definition doesn't have to be perfect for that purpose.

That said, I'm not satisfied that this can't be made better, including
perhaps in the way you've suggested.
 
> * "under the Apache License"
> 
> Perhaps you should give a version number. (Ah, I see you give one in the
> definitions - but I don't think people will obviously read "Apache
> License" as a defined term, because it normally has initial caps anyway.)

Ah, that's a good point. 
 
> * "or "powered by" statements"
> 
> Is this too specific, or are we hoping a judge would understand this as
> referring to a class of statements? E.g. if there was a "FooBar Inside"
> statement instead of "Powered by FooBar"...

This is just a clarification of what kinds of things absolutely are
not 'Legal Notices'. It isn't meant to be exhaustive, but I did
recently add 'Powered by statements' because that is such a common
form in which I've seen the problematic condition. 
 
> * "This condition may not be avoided through such means as separate
> distribution of portions of the Derived Work."
> 
> Is it considered that there is no need for a system library exception?
> Is that because the definition of Derived Work does not cover system
> libraries?

Sort of. The old system library exception can be seen as built into
the definition of 'Separate Work'. At least that was the intention. I
am not at all of the view that this definition could not be made
better.
 
> * "under any version of the GNU General Public License"
> 
> I look forward to the rationale for this change; I would worry that this
> would open the license up to the exploitation of flaws in e.g. GPLv1.

We might as well exclude GPLv1. I think leaving it open-ended on the
other side (GPLv2+) seems to make sense, but I suppose one could
question it. 

> I presume that the intent is that the GPL's pass-through can be used to
> get to AGPL licensing.

Not exactly. Earlier versions stated that Covered Works were
outbound-licensable under GPLv2+ or AGPLv3+. In the restructuring of
that provision I realized that you didn't have to mention AGPLv3
because GPLv3 itself is AGPLv3 compatible (and we can reasonably [?]
assume this will be so for all future versions of GPL and AGPL). And
the political benefit of explicitly allowing AGPLv3 compatibility
seems essentially nil, sadly.

> * "15 years"
> 
> Is that a conservative opening bid? :-) 

Not necessarily an opening bid, but I thought it was conservative. 

>I would say 10. 5 years is a bit
> short - the 5-years-old Linux kernel is still a pretty good bit of kit.
> But 15 years is a long period over which to track down contributors to
> get permission for some change.

True. I was mainly focusing on the policy issue of copyright duration
there, through the proxy of copyleft duration.  The side benefit of
making license changes easier was serendipitous.

> * Has consideration been given to combining how section 2 works with how
> section 8 works?

I haven't thought about that, beyond being aware of the inelegance
that I introduced in referring in section 2 to the Apache License
(which I did in a recent change because I thought it might make the
provision easier to understand -- this was a response to the comments
on Martin's article on LWN.net).

 - RF




More information about the copyleft-next mailing list