On Sat, Sep 8, 2012 at 7:17 PM, Richard Fontana <fontana(a)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(a)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/0...
is the most relevant message here.
Mike