[od-discuss] compatibility should (was Re: Status of Vancouver and Surrey OGL varients)

Fri May 15 20:32:26 UTC 2015

I would like to see a best-practices guide regardless. I think the
*concern* about excess shoulds is valid. I don't think we should have a
prohibition on shoulds. I think each case should be considered.

On 05/15/2015 01:29 PM, Mike Linksvayer wrote:
> We have shoulds in section 1.
> 
> We could remove those too. But I think they convey rather valuable info
> and are appropriate to context.
> 
> Standards sometimes contain shoulds, and sometimes that is useful.
> 
> Best practice guides are vastly lower in visibility.
> 
> That's my rationale for including. :)
> 
> Mike
> 
> On 05/15/2015 01:08 PM, Herb Lainchbury wrote:
>> Whenever I see a "should" I think it introduces wiggle room, which will
>> no doubt be exploited and cause waste, so my inclination for the
>> purposes of the definition is to eliminate as many "shoulds" as possible.
>>
>> It basically says, "we would like you to do this, but we're not going to
>> hold you accountable".  To me the definition is all about
>> accountability.  Sometimes it's not so black and white, which is where
>> the council and the process come in.
>>
>> As it stands, in 2.1 only one "should" remains with regard to license
>> conformance, and that is the one contained in 2.1.4.  It arguably could
>> (should!) be changed to a "must".  Otherwise, it seems it's just
>> commentary.
>>
>>
>> As for compatibility, I think compatibility is one of the primary value
>> propositions of the definition so we should definitely look for
>> opportunities to bolster that.  How to do that is a good question.  Our
>> current approval process helps where we ask the proponent to identify
>> all existing approved licenses that the new license is compatible with.
>>
>> Maybe I am wrong, but I am just not sure what adding another "should"
>> would do.
>>
>>
>> On Fri, May 15, 2015 at 12:33 PM, Aaron Wolf <wolftune at riseup.net
>> <mailto:wolftune at riseup.net>> wrote:
>>
>>     My inclination is to word it sort of like:
>>
>>     "The license should aim for compatibility with…"
>>
>>     and perhaps
>>
>>     "The license should avoid [extraneous] conditions that would create
>>     incompatibilities with other Open licenses"
>>
>>     Basically, the point is something like "Any clause that creates
>>     incompatibilities should require justification and careful
>>     consideration."
>>
>>     Essentially, "consider compatibility with other Open licenses as a
>> high
>>     priority, and do not carelessly introduce incompatible terms."
>>
>>     I hope some of this perspective and writing can be used / adapted
>> into
>>     this concern which I basically agree with.
>>
>>     Cheers,
>>     Aaron
>>
>>     On 05/15/2015 12:24 PM, Mike Linksvayer wrote:
>>      > On 12/10/2014 12:18 AM, Mike Linksvayer wrote:
>>      >> On 12/09/2014 11:52 PM, Paul Norman wrote:
>>      >>> On 11/20/2014 1:45 PM, Mike Linksvayer wrote:
>>      >>>>
>>      >>>>      A bigger issue to me is that I've been told by
>>     governments using
>>      >>>>      them that the OGL-BC derived licenses (OGL-Surrey,
>>     OGL-Vancouver)
>>      >>>>      are not compatible with CC BY, ODC-BY or the ODbL.
>>     Because the
>>      >>>>      Canadian OGL variants are essentially only usable by a
>> single
>>      >>>>      government, this leaves me with an impossible situation
>>     for making
>>      >>>>      works from multiple sources and my work.
>>      >>>>
>>      >>>>
>>      >>>> That's also extremely annoying but wouldn't make the licenses
>>     non-open
>>      >>>> per the definition.
>>      >>>>
>>      >>> While I agree in principle that an open license need not be
>>     compatible
>>      >>> with other open licenses, I am worried by licenses which are
>>      >>> interoperable with neither CC or ODC licenses.
>>      >>>
>>      >>> I am not sure that a non-reusable license which fails to be
>>     compatible
>>      >>> with any other open licenses can be considered open. If I take
>>     Vancouver
>>      >>> data, modify it and add my own copyrightable contributions, and
>>     want to
>>      >>> release the new work, I cannot do so under any open license.
>>     Other open
>>      >>> licenses are not compatible, and I cannot release it under the
>>      >>> OGL-Vancouver license as I am not the City of Vancouver.* To my
>>     mind,
>>      >>> this is non-open.
>>      >>
>>      >> I'm very sympathetic to your argument, but we (whoever was
>>     participating
>>      >> at time anyway, I haven't dug up discussion) decided to not
>> address
>>      >> compatibility in OD 2.0. The fallback was to require that a
>>     license be
>>      >> compatible with at least one of CC-BY-SA, ODbL, or GPL in order
>>     to be
>>      >> put in "recommended" category.
>>      >>
>>      >> I've added https://github.com/okfn/opendefinition/issues/77 for
>>     2.1 to
>>      >> make sure this gets re-evaluated
>>      >
>>      > I've created a pull request addressing this, rationale below for
>>      > discussion, copied from
>>     https://github.com/okfn/opendefinition/pull/103
>>      >
>>      > I continue to think compatibility an important issue and that the
>>      > definition is by far the most powerful venue this group has, so
>>     should
>>      > (heh) be mentioned there.
>>      >
>>      > We have other *should*s in the definition, this one is as
>> important.
>>      >
>>      > I've kept this very brief:
>>      >
>>      >> The **license** *should* be compatible with other open licenses.
>>      >
>>      > Some obvious ways to extend:
>>      >
>>      >> The **license** *should* be compatible with other open licenses
>>     to the
>>      > maximum extent possible given its policy ends.
>>      >
>>      > or
>>      >
>>      >> The **license** *should* be compatible with other open
>> licenses, in
>>      > particular one or more of the most commonly used copyleft
>> licenses.
>>      >
>>      > However I tend to think generality is good here, message should
>> not
>>      > prompt thinking of excuses (which ...policy ends... does) nor
>>     narrowness
>>      > (which ...copyleft licenses does).
>>      >
>>      > Mike
>>      > _______________________________________________
>>      > od-discuss mailing list
>>      > od-discuss at lists.okfn.org <mailto:od-discuss at lists.okfn.org>
>>      > https://lists.okfn.org/mailman/listinfo/od-discuss
>>      > Unsubscribe: https://lists.okfn.org/mailman/options/od-discuss
>>
>>     --
>>     Aaron Wolf
>>     co-founder, Snowdrift.coop
>>     music teacher, wolftune.com <http://wolftune.com>
>>     _______________________________________________
>>     od-discuss mailing list
>>     od-discuss at lists.okfn.org <mailto: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
>>
>>
>>
>> _______________________________________________
>> 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

-- 
Aaron Wolf
co-founder, Snowdrift.coop
music teacher, wolftune.com