[od-discuss] v2.0dev Review Requested

Aaron Wolf wolftune at gmail.com
Tue Jun 17 01:47:39 UTC 2014


I just submitted a pull-request for substantial wording improvements
throughout the definition. None of this changes the meaning, but the
wordings are much clearer.

I recently practiced a lot of writing based on some ideas I learned at the
WriteTheDocs conference. One point: reduction of the verb "to be" aids not
only in the pointedness of the wordings but makes translation easier and
cheaper. I do not follow this dogmatically, it's just one of those many
good ideas to consider.

So I think all my improvements are worth including.

Here's the pull request: https://github.com/okfn/opendefinition/pull/41

Cheers,
Aaron

--
Aaron Wolf
wolftune.com


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


More information about the od-discuss mailing list