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

Fri May 15 20:29:12 UTC 2015

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
>