Posting GitHub comment to list.
-------- Original Message --------
Subject: Re: [copyleft-next] Revise Proprietary Relicensing poison
Date: Sun, 30 Dec 2012 06:35:05 -0800
From: Engelnyst <notifications(a)github.com>
To: richardfontana/copyleft-next <copyleft-next(a)noreply.github.com>
CC: Richard Fontana <fontana(a)sharpeleven.org>
I'm very, very glad to see this reference of the OSI approval. It is
the best usable criterium I can think of, to distinguish a license
from 'proprietary licensing'.
* Simplicity argument is fair and reasonable IMHO: indeed it is
straightforward to know what falls under the OSI list, and tbh that is
very useful to developers. Not everyone will or can take the time to
figure out on their own what may fall under a definition like OSD, FSD
or Debian (except to use those definitions for understanding, context,
argumentation in particular cases).
* If there are doubtful licenses on the OSI list, personally I don't
see that as a downside of any significance. One can very well take the
path to publicly discourage or not encourage or express doubt on them,
rather than make the whole definition in this license legally too
restricted or confusing. That risks to be unusable.
* I should say, I do think that a relying on a definition has its
strenghts however, besides the risks.
not to mention the offense the FSF is likely to take
This is a purely political argument, one that smells very bad. I've
been occasionally following development of copyleft-next, with the
hope that it will perhaps define copyleft without compromises which,
lets say, have no good reasons to be made. Not trying to open an
argument on that side, lets just say that IMHO a reasonable enough
criterium (even if perhaps no criterium is perfect) is preferable to
compromises with others 'offenses'.
It occurs to me that this Proprietary Relicensing provision is the
part of copyleft-next that is in danger of taking on certain GPLv3-ish
stylistic qualities that are undesirable generally for
copyleft-next. I am not sure how to solve that without making the
provision significantly longer or removing it from copyleft-next. I
don't like either of those options.
What do you mean by "certain GPLv3-ish stylistic qualities that are
undesirable generally for copyleft-next"? A quick pointer to where I
can find details will be enough. Thank you.
Reply to this email directly or view it on GitHub: