[od-discuss] compatibility should (was Re: Status of Vancouver and Surrey OGL varients)
Herb Lainchbury
herb at dynamic-solutions.com
Fri May 15 20:56:50 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.
Agreed, I was commenting only in relation to license conformance testing.
I could have been more explicit about that.
> Standards sometimes contain shoulds, and sometimes that is useful.
> Best practice guides are vastly lower in visibility.
Agreed.
On Fri, May 15, 2015 at 1:29 PM, Mike Linksvayer <ml at gondwanaland.com>
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
>
--
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/17a96f4b/attachment-0003.html>
More information about the od-discuss
mailing list