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

Fri May 15 20:08:22 UTC 2015

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

-- 

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/20150515/1728ce54/attachment-0003.html>