[od-discuss] v2.0dev Review Requested

Mon Jun 9 19:20:50 UTC 2014

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20140609/8cef372c/attachment-0002.html>