I haven't had too much time to work on copyleft-next lately because of some recent work, vacation, and conference commitments. Here's most of what's happened since the previous update:
Based on a discussion I had with Bradley Kuhn at LinuxCon about clarifying the Harvey Birdman Rule, a patch from Bradley was merged.
I added a clarification to the GPLv2-ish 'Later License Versions' section to the effect that mere inclusion of a copy of "this" particular version of copyleft-next does not signify restriction to a particular license version for purposes of that section. This resolves an ambiguity that occasionally arises in GPL practice. If some code has a COPYING file containing GPLv2, but no other statement about license versions, is the author limiting downstream use (let's assume we know what that means) to GPLv2 or is this instead a case of what GPLv2 means by "the Program ... not specify[ing] a version number of this License"? copyleft-next says it's the latter: i.e., if the author wants to restrict downstream recipients to v1.0, the author must say so in some way more explicit than merely including a copy of copyleft-next v1.0. (That could be something quite minimal, like separately saying "Licensed under copyleft-next v1.0.")
I've made a change to the Corresponding Source definition that Bradley might not like, but I assume he hasn't seen it yet. I've made it a bit less GPLv3-ish and a bit more GPLv2-ish in style, removing the set of verbs we see in the definition in GPLv3. The intention is not to alter the scope of what is Corresponding Source but to maximize clarity.
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Finally, I have adopted MPL 2.0's approach in relaxing the requirement to include a copy of the license text to "inform[ing] recipients how they an obtain a copy". This was motivated by some recent discussion on the OSI license-discuss list, and also by a conversation I had at LinuxCon about a related issue.
- Richard
On 09/08/2012 10:17 PM, Richard Fontana wrote:
I've made a change to the Corresponding Source definition that Bradley might not like, but I assume he hasn't seen it yet. I've made it a bit less GPLv3-ish and a bit more GPLv2-ish in style, removing the set of verbs we see in the definition in GPLv3.
Er, more precisely, removing the set of verbs which is descended from a corresponding set in GPLv3 (it was not identical at the point of deletion.)
- RF
On 09/08/2012 09:17 PM, Richard Fontana wrote:
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Presumably you are referring to... http://lcna2012.sched.org/event/55548175096c8c2912a6c6e87ff07551#.UEwTax-Wth...
Which was apparently paraphrased in the press, e.g. http://www.internetnews.com/blog/skerner/how-do-you-define-open-source-linux...
Do you know if there is an original video (audio) available from this event. I'd ask for "slides", but, you know, slides really don't tell the story!
Regards,
--Tom
On 09/08/2012 11:58 PM, Tom Marble wrote:
On 09/08/2012 09:17 PM, Richard Fontana wrote:
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Presumably you are referring to... http://lcna2012.sched.org/event/55548175096c8c2912a6c6e87ff07551#.UEwTax-Wth...
Which was apparently paraphrased in the press, e.g. http://www.internetnews.com/blog/skerner/how-do-you-define-open-source-linux...
Do you know if there is an original video (audio) available from this event. I'd ask for "slides", but, you know, slides really don't tell the story!
Regards,
--Tom
A speaking outline would be fine in conjunction with slides. Annotated slides would be fabulous too.
Stephen Michael Kellat
On 09/08/2012 11:58 PM, Tom Marble wrote:
On 09/08/2012 09:17 PM, Richard Fontana wrote:
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Presumably you are referring to... http://lcna2012.sched.org/event/55548175096c8c2912a6c6e87ff07551#.UEwTax-Wth...
Which was apparently paraphrased in the press, e.g. http://www.internetnews.com/blog/skerner/how-do-you-define-open-source-linux...
There was some possibility that an LWN.net journalist was going to write something up on this talk, but I guess that is now unlikely. I might write something for opensource.com on it in the near future, if I have time.
Do you know if there is an original video (audio) available from this event. I'd ask for "slides", but, you know, slides really don't tell the story!
The celebrated Free as in Freedom oggcast might broadcast audio of this talk sometime in October. I have put the slides up at http://linuxcon2012-fontana.rhcloud.com/ (showoff on OpenShift) but note that for some reason the slides containing quotes from Bradley don't display the quotation marks. The slides are probably of limited help without the audio.
- RF
On 09/08/2012 10:17 PM, Richard Fontana wrote:
I haven't had too much time to work on copyleft-next lately because of some recent work, vacation, and conference commitments.
Life happens.
Here's most of what's happened since the previous update:
Based on a discussion I had with Bradley Kuhn at LinuxCon about clarifying the Harvey Birdman Rule, a patch from Bradley was merged.
Harvey Birdman Rule otherwise known as disclosure of "ex parte communications"?
I added a clarification to the GPLv2-ish 'Later License Versions' section to the effect that mere inclusion of a copy of "this" particular version of copyleft-next does not signify restriction to a particular license version for purposes of that section. This resolves an ambiguity that occasionally arises in GPL practice. If some code has a COPYING file containing GPLv2, but no other statement about license versions, is the author limiting downstream use (let's assume we know what that means) to GPLv2 or is this instead a case of what GPLv2 means by "the Program ... not specify[ing] a version number of this License"? copyleft-next says it's the latter: i.e., if the author wants to restrict downstream recipients to v1.0, the author must say so in some way more explicit than merely including a copy of copyleft-next v1.0. (That could be something quite minimal, like separately saying "Licensed under copyleft-next v1.0.")
Since the question is indirectly broached, how are we defining "downstream"?
I've made a change to the Corresponding Source definition that Bradley might not like, but I assume he hasn't seen it yet. I've made it a bit less GPLv3-ish and a bit more GPLv2-ish in style, removing the set of verbs we see in the definition in GPLv3. The intention is not to alter the scope of what is Corresponding Source but to maximize clarity.
I prefer to err on the side of clarity as non-lawyers may potentially wield this license and deploy it.
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
I agree with Tom Marble's questions and reiterate my further amplification thereof.
Finally, I have adopted MPL 2.0's approach in relaxing the requirement to include a copy of the license text to "inform[ing] recipients how they an obtain a copy". This was motivated by some recent discussion on the OSI license-discuss list, and also by a conversation I had at LinuxCon about a related issue.
If possible, could this external discussion be summarized? I would strongly prefer to include the entire license text in an accessible fashion. Creative Commons deeds, when the HTML snippets generated by their chooser tool, provide much the same access to license text in lieu of providing a copy. See, for example: http://lisnews.org/listen_an_lisnewsorg_program_episode_210 & http://ohio.ubuntu-us.org/node/110
[snip]
Stephen Michael Kellat
On 09/09/2012 12:10 AM, Stephen Michael Kellat wrote:
Based on a discussion I had with Bradley Kuhn at LinuxCon about clarifying the Harvey Birdman Rule, a patch from Bradley was merged.
Harvey Birdman Rule otherwise known as disclosure of "ex parte communications"?
The Harvey Birdman Rule is related to the problem of ex parte communication, though I wouldn't say they are entirely equivalent concepts.
To a significant extent HBR is directed against lawyers. Applying the principle that it is relatively acceptable to criticize one's own guild, I would say that lawyers have some tendency to cause problems when they get involved in FLOSS-related legal reform endeavors, at least ones that are seen (correctly or [usually] not) as important. Among other things, left to their own devices, they will quickly call for application of the troublesome Chatham House Rule, find it normative to pass around redlined Word docs as a method of collaboration (this is after all what many of them do in their day-to-day work), and will engage in what you'd call ex parte communications with subsets of participants. However, to be sure, HBR attacks a set of problems that is not limited to the involvement of lawyers.
Finally, I have adopted MPL 2.0's approach in relaxing the requirement to include a copy of the license text to "inform[ing] recipients how they an obtain a copy". This was motivated by some recent discussion on the OSI license-discuss list, and also by a conversation I had at LinuxCon about a related issue.
If possible, could this external discussion be summarized?
The OSI discussion is archived somewhere on opensource.org (archives of license-discuss). As for the LinuxCon conversation, I am not sure the person I had the discussion with would want me to describe it publicly. It had nothing to do with copyleft-next (thus keeping the details private is not a HBR violation), but the specific issue is one that I believe was noted by someone else in the license-discuss thread anyway.
I would strongly prefer to include the entire license text in an accessible fashion. Creative Commons deeds, when the HTML snippets generated by their chooser tool, provide much the same access to license text in lieu of providing a copy. See, for example: http://lisnews.org/listen_an_lisnewsorg_program_episode_210 & http://ohio.ubuntu-us.org/node/110
[snip]
I wasn't sure if you were talking in part about the desirability of CC-style "deeds". I have mixed feelings about such deeds.
- Richard
On Sat, Sep 8, 2012 at 7:17 PM, Richard Fontana fontana@sharpeleven.org wrote:
I added a clarification to the GPLv2-ish 'Later License Versions' section to the effect that mere inclusion of a copy of "this" particular version of copyleft-next does not signify restriction to a particular license version for purposes of that section. This resolves an ambiguity that occasionally arises in GPL practice. If some code has a COPYING file containing GPLv2, but no other statement about license versions, is the author limiting downstream use (let's assume we know what that means) to GPLv2 or is this instead a case of what GPLv2 means by "the Program ... not specify[ing] a version number of this License"? copyleft-next says it's the latter: i.e., if the author wants to restrict downstream recipients to v1.0, the author must say so in some way more explicit than merely including a copy of copyleft-next v1.0. (That could be something quite minimal, like separately saying "Licensed under copyleft-next v1.0.")
How does this work in conjunction with
Finally, I have adopted MPL 2.0's approach in relaxing the requirement to include a copy of the license text to "inform[ing] recipients how they an obtain a copy". This was motivated by some recent discussion on the OSI license-discuss list, and also by a conversation I had at LinuxCon about a related issue.
which I take to be inclusive of the mechanism of providing a link to a copy of the license. Let's say a human reading the link sees a version number, eg copyleft-next.tld/copyleft-next-1.0
Hopefully that would not be enough to permit v1 only, just as providing a copy of v1 would not be enough to permit v1 only, assuming current language, assuming v1 of copyleft-next, etc.
I would prefer or later versions to be the default, with "only" needing to be specified. Maybe this could be expressed with fewer words, something like
diff --git a/Drafts/copyleft-next b/Drafts/copyleft-next index b720b2f..14fa86d 100644 --- a/Drafts/copyleft-next +++ b/Drafts/copyleft-next @@ -196,12 +196,10 @@ THIS IS A DRAFT. DO NOT USE AS A LICENSE.
The Copyleft-Next Project may publish new versions of copyleft-next, designated by a distinguishing version number. If - the Received Work explicitly grants you the option of Distributing - Covered Works under later published versions of copyleft-next, or - if it does not specify a version number at all, then you may - Distribute Covered Works under any later version of - copyleft-next. Mere inclusion of this license document is not - specification of a version number. + the Received Work does not explicitly remove the option of + Distributing Covered Works under later published versions of + copyleft-next then you may Distribute Covered Works under any + later version of copyleft-next.
12. No Warranty.
Speaking of later versions, isn't GPLv3 bullet in outbound compatibility section redundant, given GPLv2 and later versions of foregoing bullets? I see MPL2 doesn't list GPLv3 separately as a secondary license.
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
+1 to requests for the goods.
On Sat, Sep 8, 2012 at 9:10 PM, Stephen Michael Kellat skellat@fastmail.net wrote:
On 09/08/2012 10:17 PM, Richard Fontana wrote:
Finally, I have adopted MPL 2.0's approach in relaxing the requirement to include a copy of the license text to "inform[ing] recipients how they an obtain a copy". This was motivated by some recent discussion on the OSI license-discuss list, and also by a conversation I had at LinuxCon about a related issue.
If possible, could this external discussion be summarized? I would strongly prefer to include the entire license text in an accessible fashion. Creative Commons deeds, when the HTML snippets generated by their chooser tool, provide much the same access to license text in lieu of providing a copy. See, for example: http://lisnews.org/listen_an_lisnewsorg_program_episode_210 & http://ohio.ubuntu-us.org/node/110
I don't have a non-silly summary (silly summary: thread participant exits recursively) but I suppose http://projects.opensource.org/pipermail/license-discuss/2012-September/0006... is the most relevant message here.
Mike
On Sun, Sep 9, 2012 at 3:57 PM, Mike Linksvayer ml@gondwanaland.com wrote:
On Sat, Sep 8, 2012 at 7:17 PM, Richard Fontana fontana@sharpeleven.org wrote:
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Not being trollish here: if I understood your critiques of the OSD, don't most of them also apply to the FSD (e.g., ignore community structure, development mechanisms, etc.)? Further discussion may be OT for this list, but I would love to hear your thoughts on this at some point.
Luis
On 09/09/2012 07:03 PM, Luis Villa wrote:
On Sun, Sep 9, 2012 at 3:57 PM, Mike Linksvayer ml@gondwanaland.com wrote:
On Sat, Sep 8, 2012 at 7:17 PM, Richard Fontana fontana@sharpeleven.org wrote:
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
Not being trollish here: if I understood your critiques of the OSD, don't most of them also apply to the FSD (e.g., ignore community structure, development mechanisms, etc.)? Further discussion may be OT for this list, but I would love to hear your thoughts on this at some point.
The FSD has problems too, don't get me wrong. I do like the document the FSF maintains here: http://www.gnu.org/philosophy/free-sw.html as distinct from the FSD proper.
(Not that I agree with everything in this document, but I like the structure of an elegant definition followed by periodically revised interpretive commentary.)
As noted in my earlier message I may write something up about this soon, though I've been kind of busy.
- Richard
On 09/09/2012 06:57 PM, Mike Linksvayer wrote:
I would prefer or later versions to be the default, with "only" needing to be specified. Maybe this could be expressed with fewer words, something like
diff --git a/Drafts/copyleft-next b/Drafts/copyleft-next index b720b2f..14fa86d 100644 --- a/Drafts/copyleft-next +++ b/Drafts/copyleft-next @@ -196,12 +196,10 @@ THIS IS A DRAFT. DO NOT USE AS A LICENSE.
The Copyleft-Next Project may publish new versions of copyleft-next, designated by a distinguishing version number. If
- the Received Work explicitly grants you the option of Distributing
- Covered Works under later published versions of copyleft-next, or
- if it does not specify a version number at all, then you may
- Distribute Covered Works under any later version of
- copyleft-next. Mere inclusion of this license document is not
- specification of a version number.
- the Received Work does not explicitly remove the option of
- Distributing Covered Works under later published versions of
- copyleft-next then you may Distribute Covered Works under any
- later version of copyleft-next.
- No Warranty.
Good suggestion. I merged your patch, thanks.
Speaking of later versions, isn't GPLv3 bullet in outbound compatibility section redundant, given GPLv2 and later versions of foregoing bullets? I see MPL2 doesn't list GPLv3 separately as a secondary license.
Good point, and also applied.
I removed the reference to the Open Source Definition in the Proprietary-Relicensing section, because (to the extent I ever did) I no longer consider the Open Source Definition to be a useful definition of open source (a point I explained in my talk at LinuxCon).
+1 to requests for the goods.
I might write up something about this on opensource.com next week or so, though the likelihood is not extremely high. In brief: I find the Debian Free Software Guidelines, on which the OSD is based, a strange document when viewed outside its historical context. When viewed in historical context, it makes some sense as an effort to distill policies Debian had applied to figure out what sorts of software it was distributing should be kept out of main as a signal of possible danger to downstream commercial Debian redistributors. It's a 1990s noncommercial distro project "possibly unsafe to put on a for-sale CD" definition, and quite unsuitable as a *general* definition of open source. One suspects it was chosen as a definition by Perens and Raymond in 1998 because they had nothing else at hand to use and needed something really quick. I do find it interesting that some in the larger OSI community occasionally refer to OSD planks when discussing licenses, but there is no evidence I'm aware of that the OSI itself specifically considers the OSD when deciding whether to approve licenses as 'Open Source'. This casts further doubt on the usefulness of the definition.
At the end of my talk I proposed (among other things) that the OSI replace the OSD with something close to the FSF's simpler Free Software Definition.
- RF
copyleft-next@lists.fedorahosted.org