[od-discuss] v2.0dev Review Requested

[Aaron Wolf]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20140728/66323eeb/attachment-0003.html>