[copyleft-next] comments on 0.1.1

Richard Fontana fontana at sharpeleven.org
Sat Feb 9 03:15:34 UTC 2013


On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
> All:
> 
> Upon review of a recent release (0.1.1) I am wondering the following:
> 
> 1. Will there be a FAQ?

RSN.

> 2. Is the rationale for design decisions captured explicitly?
>    The mailing list has provided a great deal of clarification
>    regarding goals, approaches and thinking.  However searching
>    the mailing list for thinking on a specific point may
>    be difficult. 

Agreed. This concerns me.

> 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?

> 3. Why list in §10 specific license compatibility?
>    In fact this is is more license *morphing* than compatibility.
>    If, for example, copyleft-next is intended to plug
>    loopholes of AGPL then does not §11 preserve such
>    loopholes (through morphing)?

You're right that it's license morphing, which is deemed by tradition
to achieve GPL compatibility through magical means. This of course is
problematic. But outbound (A)GPL compatibility is a design goal. 

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.

Maybe there's a better way to handle GPL-compatibility (short of a
GPLv4 with bi-directional copyleft-next compatibility being released
in 2028). It's clear that the FSF regards magical relicensing clauses
as an easy way to do it, and if the FSF thinks copyleft-next is
GPL-compatible, so will the rest of the universe. I suppose I've been
trying to avoid opening the can of worms of figuring out what magical
relicensing clauses actually are, or do, but we might have to do so.

> 4. Is copyleft-next compatible with the EPL?
>    This question is a troll.

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. 
 
> 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?)

> 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.

>    A Product shipping with Corresponding Source yet not runnable
>    by rebuilding the Source (due to, for example, the lack of a certain
>    cryptographic signature) would withhold freedom #1.
>    It is not obvious that the interpretation of copyleft-next
>    could simultaneously support lockdown and qualify
>    as a Free Software license by supporting all four freedoms.

Can't the same be said of GPLv2, as interpreted by most who've tried
to interpret it (including the FSF)? Not to mention noncopyleft
licenses. It's also true of GPLv3 since the anti-lockdown provisions
only apply to 'User Products'. GPLv3 legislative history will show
that the FSF assumed that GPLv3-software-containing medical devices
could be locked down.

>    Certain developers may believe there is a solution in
>    explicitly allowing key replacement
>    (such that private key material need not be disclosed).
> 
> 7. What triggers derivation vs. aggregation?
>    For the purpose of understanding the applicability of §5
>    is there a "bright line" test to distinguish aggregation?

No more than in the GPL.

>    For example, if Object Code from the Covered Work is
>    linked with a Separate Work is the result a Derived Work?

I don't think there's any clearer general answer than you'd get with
the GPL. 

>    Or if Object Code operates in conjunction with a Separate Work
>    over a network connection is the result a Mere Aggregation?

That seems likely in most if not all cases.

A question underneath your question is whether copyleft-next (or
copyleft-next + FAQ) could or should create more clarity around such
questions than we've had with the GPL (or more precisely GPL + FSF FAQ
+ evolving customary interpretation).

Within the license itself, I'm not sure it's possible without making
the license longer even than GPLv3.
 
> 8. Based on the FOSDEM presentation
>    https://fosdem.org/2013/schedule/event/copyleft_next/
>    is the choice of a Hyena as a mascot an allusion
>    to the unfortunate occurrence of tribal infighting (cannibalism?)
>    in Free Software communities (first mentioned in a blog
>    post long ago by Mark Shuttleworth)?

I can confirm that this was *not* a reason for the choice of a hyena
as the mascot.

However, while HBR does not require this disclosure, I will disclose
that at lunch with Karen Sandler, Deb Nicholson, and Martin Michlmayr
following that presentation, there appeared to be among those three
individuals a unanimous sentiment that a hyena was a remarkably poor
choice for a mascot.

> 9. Proprietary relicensing deflation loophole
>    Why offer a loophole of one year in §3 before
>    deflation kicks in?

Here are the situations I was thinking of:

i) Foo Inc. does proprietary licensing of program P at T0. At T1 Foo
ceases further proprietary licensing and places P under
copyleft-next. This should not trigger the poison pill.

ii) Foo Inc., which has a proprietary software product P, is acquired
by Bar Inc. Bar continues the ongoing business of Foo wrt P, but
intends to transition towards what I'm afraid (as I believe you know)
some companies call "open sourcing" of P. The process may be such that
proprietary P will be distributed simultaneously with copyleft-next P
during some time period. 

Regarding case ii, I was influenced by something I remember Bradley
once saying, that he thought it was reasonable for a company acquiring
proprietary software assets to take a year to accomplish completion of
a transition from proprietary to free. 

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. 

> 10. Getting to 201 lines
>     All the metrics of copyleft-next are currently meeting
>     objectives, except for line count.  How can we best
>     get down to 201 lines?  Do we really need decorations
>     for §13 and §14?  That may be acceptable if it is
>     an alternative for SCREAMING in all caps.  Perhaps
>     limiting decorations to the margins would eliminate
>     8 lines?

That's a good idea. If Luis Villa ever sees this I'm curious to know
what he'd think of that. 8 lines is a lot.
 
> 11. Will copyleft-next* (i.e. copyleft-next or copyleft-next-ns)
>     be silent on data or try to incorporate the spirit of the
>     Franklin Street Statement?

I don't know yet. 

 - RF



More information about the copyleft-next mailing list