[od-discuss] v2.0dev Review Requested

Sun Jul 27 17:10:58 UTC 2014

I believe we are very close now.  As a reminder, our goals for v2.0 are:

   1. separation of license conditions from works conditions
   2. clearer wording

We want to achieve this and ensure the definition maintains it's essential
meaning from 1.1 to 2.0.

To move forward I think we need to ensure:

   1. we haven't lost any rigor (i.e. all clauses in 1.1 are present in
   2.0, any we have dropped have been dropped intentionally, and reworded
   clauses are not unintentionally less rigorous)
   2. we haven't introduced any new rigor unintentionally (i.e. all clauses
   in 2.0 can be found in 1.1, any new clauses have been introduced
   intentionally, and reworded clauses are not unintentionally more rigorous)

I encourage anyone who can to do this.  I myself have done this and it
appears to me that as it stands we have introduced several new clauses,
some of which are necessary for this release, some of which are making what
was implicit, explicit for clarity, and some of which appear to be net new.

I would move to postpone the inclusion of the net new clauses for a
subsequent release as we have done with other new clauses, or, if we feel
they are needed in this release, document that need here.

As I see it the new clauses are:

"1.1 The work must be available under an open license (as defined in
Section 2). Any additional terms accompanying the work (such as a terms of
use, or patents held by the licensor) must not contradict the terms of the
license."

This clause is necessary as it links the new section 1 to the new section 2.

"2.1.1 - The license must allow free use of the licensed work."

This clause is making what was implicit in 1.1, explicit.

"2.2.3 Share-alike - The license may require copies or derivatives of a
licensed work to remain under under a license the same as or similar to the
original."

The clause is making what was implicit in 1.1, explicit.

"2.2.4 Notice - The license may require retention of copyright notices and
identification of the license."

I think this clause is net new and should be justified or moved to a future
release.

"2.2.5 Source - The license may require modified works to be made available
in a form preferred for further modification."

I think this clause is net new and should be justified or moved to a future
release.

"2.2.6 Technical Restriction Prohibition - The license may prohibit
distribution of the work in a manner where technical measures impose
restrictions on the exercise of otherwise allowed rights."

I think this clause is net new and should be justified or moved to a future
release.

"2.2.7 Non-aggression - The license may require modifiers to grant the
public additional permissions (for example, patent licenses) as required
for exercise of the rights allowed by the license. The license may also
condition permissions on not aggressing against licensees with respect to
exercising any allowed right (again, for example, patent litigation)."

I think this clause is net new and should be justified or moved to a future
release.

If I have incorrectly called out any of the net new clauses, please let me
know.  I don't see them in 1.1.  If not, let's either discuss why they are
necessary in this release or defer them to a future release and discuss
them at that time.

In other words, now is a good time to speak up for any of these clauses
I've identified as net new if you think they should be included in this
release.

Thanks,
Herb

On Mon, Jun 16, 2014 at 6:47 PM, Aaron Wolf <wolftune at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20140727/f67af2a9/attachment-0002.html>