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

Fri May 15 20:57:39 UTC 2015

> I don't think we should have a prohibition on shoulds. I think each case
should be considered.

Agreed.

On Fri, May 15, 2015 at 1:32 PM, Aaron Wolf <wolftune at riseup.net> wrote:

> 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
> _______________________________________________
> 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/20150515/267c10e1/attachment-0003.html>