[od-discuss] v2.0dev Review Requested

Mon Jul 28 18:24:05 UTC 2014

Thanks for the clarification Aaron.
Herb

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
>>
>>
>

-- 

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/4d094490/attachment-0003.html>