[copyleft-next] comments on 0.1.1

Tom Marble tmarble at info9.net
Sun Feb 10 01:44:32 UTC 2013


On 02/08/2013 09:15 PM, Richard Fontana wrote:
> On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
>> [...]
>> Is there a convention, for example,
>>    that changesets should document the rationale for
>>    changes on the affected lines?  Short of having
>>    a good memory on the "oral tradition" of the license
>>    evolution would commit messages or any other approach
>>    answer the question "what is the point *that* phrase?"
>>    or "why did the BFDL choose this solution among alternates?"?
> 
> Could you explain a bit more? I've tried to be good about informative
> commit messages. Would something more than this or different from this
> be helpful?

I was thinking of requesting that commit messages contain
rationale for changes and that individual lines could be tracked
via git blame:
  http://alblue.bandlem.com/2011/07/git-tip-of-week-assigning-blame.html

While this is generally a good practice it does not lend itself
to a format which is readily accessible by muggles. Instead it may be
helpful to collect rationale from the FOSDEM presentation (which provided
excellent background) as well as some sort of companion
document which includes annotations on each section.

This does increase the number of documents to the license,
the FAQ and the Rationale, yet it seems this would be
serve as a central location to better understand specific
parts of the license as well as collect the thinking over
the course of drafting.

> And yes, allowing "relicensing" under GPL/AGPL means that if such
> relicensing occurs or is deemed to occur, you get any problems
> (assuming such problems exist) in those outbound licenses
> restored. This is a drawback, but I've assumed that having
> copyleft-next be flat-out GPL-incompatible (I suppose AGPL doesn't
> seriously matter at this point) is worse than having that drawback.

Would there be a way to allow relicensing with the added
restriction of §3?

> It is not compatible with the EPL. But I've been seriously thinking
> that the github person who suggested a far more liberal compatibility
> policy than we have with GPL may be on the right track. I think
> orthodox GPL compatibility doctrine may itself be a source of
> competitive disadvantage for strong copyleft. 

While EPL compatibility would be very nice it should
not come at the expense of weakening or adding loopholes
to copyleft-next.

>> 5. Compliance freshness date encourages prompt remedies?
>>    Is the goal of §11.a to encourage coming in to compliance
>>    quickly else requiring You to negotiate a new license with Us?
>>    In other words downloading a new copy of the "Covered Work"
>>    does not reset the clock on a terminated license?
> 
> "Termination of Your rights disqualifies You from receiving new
> licenses covering the Received Work...." (or does that not resolve the
> concern?)

I think "everyone knows" you can't just re-download the code
and restart the clock on the license, but something like this
might prevent hucksters from attempting such an approach.

>> 6. Does the definition of "Corresponding Source" combined with §7
>>    effectively form an anti-lockdown provision?
> 
> No, or at least that is not the intention.

I realize such a provision may not be popular with the more
permissive minded on this list (including those from a
permissive Linux mindset), yet I would like such a provision
even if it specifically allowed key replacement (as to counteract the
alarmist fears of private key disclosure).

I note that James Bottomley, on behalf of the Linux Foundation,
offers such a key replacement approach for UEFI Secure Boot
as discussed at Linux Conf Australia:
  http://linux.conf.au/schedule/30115/view_talk?day=thursday

> So the year is a grace period. After that grace period expires, you no
> longer have any excuses and the poison pill kicks in. In a sense, by
> that point there is an irrebuttable presumption that the continued
> proprietary and copyleft licensing of P is nefarious. (That
> presumption is actually unfair, but I wouldn't want to have a grace
> period of more than a year.)
> 
> Maybe this makes things more complicated than is really necessary. 

It seems generous and accommodates transitions.  Thanks for
the clarification.

Regards,

--Tom


More information about the copyleft-next mailing list