[od-discuss] v2.0dev Review Requested

Fri May 9 18:32:48 UTC 2014

Addendum:

Sorry about my type at "Overall, I suggest this be changed to" where I
inserted something between that and the actual suggestion.

Also, I now reviewed Rufus' suggestions and support those as well, some of
which address some of my concerns.

--
Aaron Wolf
wolftune.com

On Fri, May 9, 2014 at 11:27 AM, Aaron Wolf <wolftune at gmail.com> 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.
>
> 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.
>
> 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.
>
> 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"
>
> 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.
>
> 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…
>
> Cheers,
>
> Aaron Wolf
> Snowdrift.coop
>
>
> --
> Aaron Wolf
> wolftune.com
>
>
> On Fri, May 9, 2014 at 5:14 AM, Rufus Pollock <rufus.pollock at okfn.org>wrote:
>
>> I think this now looking *really good* :-)
>>
>> Some final thoughts (I think we are very close to having our 2.0 here!)
>>
>> A. I'm wondering if we swap section 2 and section 1 so that Open Works
>> come first and then refers to Open License stuff which is section 2
>>
>> B. Section 2.1.1
>>
>> I think we need to make clearer that you actually need to apply an open
>> license. Suggested tweak:
>>
>> The *work* *must* be available under an open *license *(as defined in
>> section 1). Any additional terms accompanying the work (such as a terms
>> of use) *must not* contradict the terms of the license.
>>
>> C. Machine readable and bulk
>>
>> We seem to have lost stuff around machine-readable and bulk. I wonder if
>> we can tweak 2.1.3 (rename complements 2.1.1 which is about legal openness)
>>
>> 2.1.3 Technically Open
>>
>> The *work* *must* be provided in a convenient and modifiable form such
>> that there are no unnecessary technological obstacles to the performance of
>> the licensed rights. Specifically, data should be machine-readable,
>> available in bulk and provided in formats that are open or, at the very
>> least, can be processed with at least one free/open source software tool.
>>
>> Comment: an open data format is one whose specification is publicly and
>> freely available and which places no restrictions monetary or otherwise
>> upon its use.
>>
>> Aside: could also provide a definition of machine readable if needed e.g.
>> this is what we have on http://okfn.org/opendata/ i.e.
>>
>> <quote>
>> Data can be provided in many ways and this can have significant impact on
>> the ability to easily use it. The Definition thus requires that data be
>> machine-readable and available in “bulk”.
>>
>> Data is machine-readable if it can be easily processed by a computer.
>> This does not just mean digital, but that it is in a digital structure that
>> is appropriate for the relevant processing. For example, consider a PDF
>> document containing tables of data. These are digital, but computers will
>> struggle to extract the information from the PDF (even though it is very
>> human readable!). The equivalent tables in a format such as a spreadsheet
>> would be machine readable. Read more about [machine-readability in the open
>> data glossary].
>>
>> Data is available in bulk if you download or access the whole dataset
>> easily. Conversely it is non-bulk if you are you limited to just getting
>> parts of the dataset, for example, are you restricted to a few elements of
>> the data at a time – imagine for example trying to a database of all the
>> towns in the world one element at a time.
>> </quote>
>>
>>
>> On 7 May 2014 23:05, Herb Lainchbury <herb at dynamic-solutions.com> wrote:
>>
>>> I have further refined the v2.0 dev file and think it's getting close to
>>> final form.
>>>
>>>  As discussed I've removed all comments and examples and attempted to
>>> make things clear without losing anything.  I think you should be able to
>>> look at v1.1 and find every clause covered in v2.0dev, though in some cases
>>> in the new "must" form rather than the v1.1 "must not" form.
>>>
>>> You'll find it here:
>>>
>>> https://github.com/okfn/opendefinition/blob/master/source/open-definition-dev.markdown
>>>
>>> I request that members of the AC review this draft and confirm that it
>>> is at least as rigorous as v1.1 and if not, make suggestions.  We don't
>>> want to unintentionally lose anything in the revision.
>>>
>>> Once we're satisfied that we haven't lost anything I would suggest we
>>> test it against existing conformant licenses and make sure we're consistent
>>> with v1.1 in that previously approved licenses would still be approved
>>> under the new version (or if not, be able to explain why not).
>>>
>>> Thank you,
>>> Herb
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>>
>> * Rufus Pollock Founder and President | skype: rufuspollock |
>> @rufuspollock <https://twitter.com/rufuspollock> Open Knowledge
>> <http://okfn.org/> - see how data can change the world **http://okfn.org/
>> <http://okfn.org/> | @okfn <http://twitter.com/OKFN> | Open Knowledge on
>> Facebook <https://www.facebook.com/OKFNetwork> |  Blog
>> <http://blog.okfn.org/>*
>>
>> The Open Knowledge Foundation is a not-for-profit organisation.  It is
>> incorporated in England & Wales as a company limited by guarantee, with
>> company number 05133759.  VAT Registration № GB 984404989. Registered
>> office address: Open Knowledge Foundation, St John’s Innovation Centre,
>> Cowley Road, Cambridge, CB4 0WS, UK.
>>
>> _______________________________________________
>> 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/20140509/007f42f1/attachment-0003.html>