[od-discuss] v2.0dev Review Requested

Mon Jul 28 18:53:42 UTC 2014

The word "rigor" was a poor choice.  Apologies.

Thanks everyone for the clarification.

I am in favour of keeping these clauses for the reasons that Aaron and Mike
provide.  I think they add clarity, make explicit what was formerly
implicit and are in-line with our overall intention that they work for the
general benefit of the open knowledge community.

I wonder if we need to update the summary statement?

"Knowledge is open if anyone is free to use, modify, and redistribute it —
subject only, at most, to requirements to attribute and share-alike."

Could it read?

"Knowledge is open if anyone is free to use, modify, and redistribute it —
subject only, at most, to requirements to attribute, share-alike and
protect the provenance and openness of works."

H

On Sun, Jul 27, 2014 at 3:08 PM, Mike Linksvayer <ml at gondwanaland.com>
wrote:

> I basically agree with Aaron's analysis. The new clauses do not introduce
> new rigor (that is, restrict what may be in an open license), they clarify
> that no new rigor is being introduced, only clarified -- the new clauses
> are acceptable conditions, matching those in widely used and considered to
> be open by conventional wisdom licenses.
>
> If we want to remove these new clauses, I see 3 options, not completely
> mutually exclusive:
>
> 1. Change
>
> "The *license* shall not limit, make uncertain, or otherwise diminish the
> permissions required in Section 2.1 except by the following allowable
> conditions"
>
> to something like
>
> "The *license* shall not limit, make uncertain, or otherwise diminish the
> permissions required in Section 2.1 except by conditions which protect the
> provenance and openness of works, such as"
>
> This would allow removing the "new" clauses while plausibly keeping
> existing conventionally deemed to be open license within the definition,
> and allowing new licenses with such not explicitly named conditions. But
> may reduce clarity, require interpretation.
>
> 2. Declare that conventional wisdom and this group until now have been
> wrong, by the new definition almost all licenses, except
> unconditional/public domain ones (though in theory others could comply, but
> don't think any exist that would, eg do any not require retaining notices
> in some form?) are not open. This might be sound from perspectives of
> theory and comedy, but seems unrealistic.
>
> 3. Have the content of the new clauses be implicit knowledge: existing
> licenses with such conditions remain evaluated as open, new licenses with
> such clauses if no other problems will be evaluated as open. This is
> presumably what would happen if new clauses removed without other changes.
> Doesn't seem to help clarity or ability for non-insiders interpret.
>
> Mike
>
>
>
> On Sun, Jul 27, 2014 at 10:42 AM, Aaron Wolf <wolftune at gmail.com> wrote:
>
>>
>>
>> On Sun, Jul 27, 2014 at 10:10 AM, Herb Lainchbury <
>> herb at dynamic-solutions.com> wrote:
>>
>>> 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.
>>>
>>>
>> The justification of 2.2.4 is: some of the accepted licenses in the known
>> list of approved licenses that nobody has object to do indeed contain such
>> requirements, so this makes the possibility of such requirements explicit.
>>
>>
>>
>>>
>>> "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.
>>>
>>>
>> Similarly, 2.2.5 is justified as it explicitly permits the clauses
>> present in accepted licenses (in this case, the GPL family). This is an
>> explicit statement that these clauses of the GPL are acceptable, and as
>> such are also acceptable in other licenses.
>>
>>
>>
>>>
>>> "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.
>>>
>>>
>> Same issue. Acceptable licenses already make this statement (GPLv3
>> family), and this explicitly accepts that and generalizes it. The concept
>> is not new.
>>
>>
>>
>>>
>>> "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.
>>>
>>
>> Same issue again mostly: this generalizes the idea of protecting the
>> freedom to make derivative works from the threat that the license terms
>> will be undone by the employment of other restrictions via patents etc. It
>> is justified and is already included in a form in licenses like the GPLv3
>> family.
>>
>>
>>>
>>>
>>> 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
>>>
>>>
>> Sure, so the point is not that strange new items have been added, but
>> merely that the definition itself clarifies the appropriateness of clauses
>> there were already present in Open licenses. This helps to make things more
>> explicit and to generalize the items from these licenses.
>>
>> Cheers,
>> Aaron
>>
>>
>>
>>>
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

-- 

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/20140728/46afe73a/attachment-0003.html>