[od-discuss] v2.0dev Review Requested

Sun Jul 27 22:08:13 UTC 2014

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