[od-discuss] v2.0dev Review Requested

Tue Jun 10 01:45:14 UTC 2014

> * 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?

+1.  don't have a good way to express this but would welcome one.

> * 1.1.6 "Impartiality" seems stronger than "non-discrimination". Do we
really want to mandate terms that treat everyone equally? I think the
crucial thing is that everyone has open terms available, not that everyone
has the same terms. Also somewhat redundant with 1.1.8.

My thought is that the intention is to treat everyone equally
(non-discrimination of people and groups) but maybe I'm wrong on this.

> Also somewhat redundant with 1.1.8.

Agreed.  1.1.6 is meant to deal with the "who".  1.1.8 is meant to deal
with the "what".. we could probably take the ", by any person or group of
persons" out of 1.1.8 and not lose anything.

On Mon, Jun 9, 2014 at 12:20 PM, Mike Linksvayer <ml at gondwanaland.com>
wrote:

>  On 05/09/2014 11:27 AM, Aaron Wolf wrote:
>
> A number of thoughts:
>
> Summary: *Data or content is open if anyone is free to use, reuse, and
>> redistribute it — subject only, at most, to the requirement to attribute
>> and/or share-alike.*
>>
>
>  First, it would be ideal to find a better subject for this sentence than
> "data or content".  The word "content" is a problem term. Although I'm not
> suggesting deference to their dogma, it is on the GNU project's list of
> problem words: https://www.gnu.org/philosophy/words-to-avoid.html#Content
>  Words like "works" and "information" and "publications" are better.
>  Notice that if we make the subject, "content or data" it really feels
> awkward. That highlights the lousiness of the word "content". In this case,
> I think "data" is fine; we just need a better term for works generally.
>
>
> I don't mind content, and do mind it being on that list (I'd prefer it be
> strictly limited to terms unambiguously harmful to software freedom;
> "content" is a mere peeve), but I agree that "data or content" is ugly.
>
> Rearranged and reworded the intro/terminology opening a bit.
>
>
>  Second, free use, reuse, and redistribution doesn't cover *access*. Can
> we really say that something is "open" if access to it initially is
> prohibitive. I think access needs to be included alongside the other
> things. Also, modification isn't explicitly covered here. How about
> "access, use, modification, and redistribution" in this summary?
>
>  I really *like* the focus on being synonymous with "free" and "libre".
> It's wonderful that we're trying to be inclusive rather than distinctive.
> That said, "free" and "libre" do not directly reference access. As I
> mentioned above, I think access is essential for openness, and "libre"
> definitions only address the freedoms after you have gotten access. So we
> should add "access" to the freedoms covered by "open" and clarify that
> "open" includes all the values of "free/libre" *plus* the value of open
> access. It would be fine to reference how, in practice, most things
> described as "free/libre" are indeed open access.
>
>  Ah, I see "work" is embraced in the formal definition (instead of
> "content" etc), so let's just be consistent in the summary too.
>
>
> I think these were covered by Rufus' suggestion which Herb pushed, but
> feel free to look again.
>
>
>  As I said above, I don't think the term "reuse" necessarily carries
> connotations of being able to substantially modify something. I think
> "modification" is better. I don't feel strongly about this, as the
> definition is clear in the details.
>
>
> Agree, fixed.
>
>
>  In 1.2.1 there's a missing comma after "if this condition is imposed"
>
>  The "must" in 1.2.2 is totally redundant (and thus confusing even) given
> the word "require"
>
>  2.1.2 includes the access issues I was talking about, so we just need to
> include "access" in the summary and other relevant places.
>
>  There's no reason for a 2.1 section if there's no 2.2. Just makes 2.1.1
> and 2.1.2 and 2.1.3 become 2.1, 2.2, and 2.3.
>
> The wording "the performance of the licensed rights" is a bit legalistic
> in wording and unfriendly to regular people.
>
> "This can be achieved by the provision of the work in an open data format"
> is also legalistic and wordy. First, The heading is "open format" so let's
> stick with that instead of "open data format". Overall, I suggest this be
> changed to "
>
> " no restrictions monetary or otherwise upon its use" needs commas, as in:
> "no restrictions*,* monetary or otherwise*,* upon its use"
>
>
> Made some of these wording/punctuation changes, but look again.
>
>
>  A suggestion then for 2.1.3:
>
> "The *work* *must* be provided in an Open format, i.e., one whose
> specification is freely available to the public and which places no
> restrictions monetary or otherwise upon its use. The work must also be
> available in the preferred form for making modifications."
>
>  The problem with saying that no technological restrictions impede the
> licensed rights is that it becomes really complex. We could say things like
> "this older computer doesn't run the program that uses this format, that's
> a technological restriction." The important thing is not that we can remove
> all technological issues but that the work doesn't itself impose them
> intentionally.
>
>
> Pull request?
>
>
>  Anyway, I have a suggestion for a NEW section. It is a bit bold:
>
>  We need to say that works must not be encumbered by patents or other
> legal restrictions that frustrate the licensed rights. In other words, we
> addressed technological restrictions, but we must also say that to be
> "open" a publisher must also not impose legal restrictions to the freedoms
> of access, use, modification, redistribution…
>
> Pull request? I don't think this would be bold at all, but probably does
> need to be limited to encumbrances licensors are able to remove, otherwise
> random patents make everything non-open.
>
> ...
>
> I made some further edits to the 2.0 draft, mostly interested ensuring
> there's no room for arguing that what got 2.0 rolling (conditions which
> make permissions uncertain eg "misuse") is acceptable.
>
> A few further thoughts, not reflected in edits so far:
>
> * 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?
>
> * 1.1.6 "Impartiality" seems stronger than "non-discrimination". Do we
> really want to mandate terms that treat everyone equally? I think the
> crucial thing is that everyone has open terms available, not that everyone
> has the same terms. Also somewhat redundant with 1.1.8.
>
> * Conditions conventionally deemed acceptable but not listed:
> ** Retain copyright/license notices
> ** Provide source
> ** Prohibit technical restrictions
>
> Mike
>
> _______________________________________________
> 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
>
>

-- 

Herb Lainchbury, Dynamic Solutions
250.704.6154
http://www.dynamic-solutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20140609/277e793a/attachment-0003.html>