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

Fri May 15 20:11:34 UTC 2015

I support Herb's concerns.

I think the solution is to have a distinct "best practices" guide
separate from the definition. It can include items discouraging license
proliferation, encouraging compatibility, encouraging legal terms that
are internationally clear, encouraging human-readability the style of
the writing, etc.

We can reference that further to apply to a given case. Such as, "While
this license meets the strict definition, we have these concerns about
where it does not follow best practices. Would you please consider
addressing these issues?"

-Aaron

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
> 

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