[od-discuss] compatibility should (was Re: Status of Vancouver and Surrey OGL varients)
Herb Lainchbury
herb at dynamic-solutions.com
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>
More information about the od-discuss
mailing list