[od-discuss] v2.0dev Review Requested

Wed Jul 30 18:39:14 UTC 2014

+1 to Herb. A work that requires derivatives to use a different license
(that can still be fully Open) still meets the basic definition even if we
don't prefer this sort of case.

--
Aaron Wolf
wolftune.com

On Wed, Jul 30, 2014 at 11:36 AM, Herb Lainchbury <
herb at dynamic-solutions.com> wrote:

> Just to follow up on Mike, Engel and Aaron's sub-thread about the clause
> that is currently numbered 2.1.3:
>
> 2.1.3 Modification
> The license must allow the creation of derivatives of the licensed work
> and allow the distribution of such derivatives under the same terms of the
> original licensed work.
>
> I think the point is that it is desirable (more open) for downstream users
> to be free to use the same specific license as well as other licenses.
>
>
> However, there are some instances where I think I am prevented from
> reusing a license.
>
> Take the UK-OGL for example.
> If I download a dataset, modify it and re-distribute it, I don't think I
> am free to use the UK-OGL for my derivative.  It's specifically for public
> sector information providers.  I would need to choose another license for
> my derivative.
>
>
> I think Engel's concern about the Wiki is valid, and such a license would
> be a poor choice for a wiki, but I'm not sure it's not open if I am still
> free to use the information and redistribute it under open terms.
>
>
> I think Mike's suggestion to relax the text is a good one, and we don't
> need to force publishers to allow others to use their specific license.
>
>
> I may be missing something here, but that's how I see it right now.
>
> Herb
>
>
>
>
>
>
>
>  On Mon, Jul 28, 2014 at 2:28 PM, Aaron Wolf <wolftune at gmail.com> wrote:
>
>> Engel, your comment was hard to parse as you had multiple clauses some
>> you were proposing as equivalent, others as opposite, some as acceptable,
>> and others not. It wasn't marked clearly.
>>
>> I *think* I got your point though. I think either "must allow" or "must
>> not forbid" are both fine but "must allow" is the clearer.
>>
>> I think your interp is fine. The original clause merely blocks anything
>> that would mandate a change of terms for derivatives. Derivatives must be
>> allowed to have the same terms as the original (although the license could
>> also be changed if the original license otherwise allows that).
>>
>> --
>> Aaron Wolf
>> wolftune.com
>>
>>
>> On Sun, Jul 27, 2014 at 9:01 PM, Engel Nyst <engel.nyst at gmail.com> wrote:
>>
>>> On 06/09/2014 03:20 PM, Mike Linksvayer wrote:
>>>
>>>>
>>>> * 1.1.3 "/must/ allow the derivatives to be distributed under the terms
>>>> of the original licensed work" I know this has been around forever, but
>>>> I don't know that there's a principled reason for it. The crucial thing
>>>> is that derivatives can be distributed under open terms. Why mandate
>>>> same terms?
>>>>
>>>>
>>> Just checking I understand this correctly. I think 1.1.3 doesn't
>>> actually mandate same terms. It merely /allows/ to be distributed under the
>>> terms I received the original. It mandates that the license allows me
>>> (doesn't forbid me) to simply transmit my adaptation over without changing
>>> the license at all. I can change it (for some cases) but 1.1.3 says I don't
>>> /have to/. [1]
>>>
>>> "/must/ not forbid the derivatives to be distributed under the terms of
>>> the original licensed work"
>>>
>>> The consequence of changing this would be:
>>>
>>> "/may/ forbid the derivatives to be distributed under the terms of the
>>> original licensed work, but /must/ allow their distribution under open
>>> terms".
>>>
>>> Such a license would break the principle of least surprise... What's
>>> more, it would prevent the most widespread model of collaboration on a
>>> project, one based on the license of the project and it alone. For example,
>>> in writing communities where people collaborate on the text, they would be
>>> /forced/ to make their corrections or reformulations (derivatives, likely)
>>> under another license than they received. It's not clear to me how would a
>>> wiki even work naturally.
>>>
>>> This sounds to me like a major change from OD 1.1... which is why I'm
>>> sending this email for you to please consider.
>>>
>>>
>>> If, OTOH, what you were pondering is that there's no real reason for
>>> licenses to necessarily "mandate same terms" in order to keep a share-alike
>>> condition, then perhaps the right target for relaxation of "the same"
>>> requirement is 2.2.3:
>>> "may require copies or derivatives of a licensed work to remain under
>>> under a license the same as or similar to the original".
>>>
>>> "Similar" is actually a relaxation of the requirement to be "the same"
>>> terms... It's a vague qualification. I think it can be read in the
>>> direction currently followed by CC on compatibility (which is a nice
>>> development IMHO), while "similar" might (or not) cover also different
>>> implementations of a share-alike mechanism. (such as keeping some, but not
>>> all, conditions for downstream, so in effect not mandating "the same terms")
>>>
>>> If 2.2.3 reads "may require [...] to remain under open terms", is it
>>> better? Assuming open terms are defined accurately and concisely.
>>>
>>>
>>> [1] I can't tell why exactly do certain non-reusable licenses fare with
>>> this requirement; maybe because they don't mandate, just make it odd, but I
>>> think in practice it hasn't been a problem. (that I recall... now that I
>>> think of it, there's a case of Debian and PHP license, however in that case
>>> too, Debian let the oddness be)
>>>
>>> --
>>> "Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can
>>> *legally* have your permission to distribute your CC-licensed works?"
>>>
>>> _______________________________________________
>>> od-discuss mailing list
>>> od-discuss at lists.okfn.org
>>> https://lists.okfn.org/mailman/listinfo/od-discuss
>>> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>>>
>>
>>
>> _______________________________________________
>> od-discuss mailing list
>> od-discuss at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/od-discuss
>> Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20140730/a3d6f85f/attachment-0003.html>