[od-discuss] Please review: 'Datenlizenz Deutschland' for OD compliance.

Tue Mar 19 15:51:43 UTC 2013

Hi Daniel,
I have had a look at the pad and it looks good to me (other than it's in a
pad and not in an email with appropriate formatting).  I can't really see
anything to add.  Do you need more feedback on something specific?
Herb

On Mon, Mar 18, 2013 at 12:31 PM, Daniel Dietrich
<daniel.dietrich at okfn.org>wrote:

> Thanks Mike,
>
> I agree we should focus on the main point and perhaps skip points 1-3 from
> my initial draft or move them to addendum.
>
> I would really like to see others comments on this, so we might be able to
> send this of by the end of this week.
>
> Daniel
>
>
> On 18 Mar 2013, at 19:01, Mike Linksvayer <ml at gondwanaland.com> wrote:
>
> > Thanks for driving this forward Daniel!
> >
> > I made some substantial edits, reflecting my opinion that the problem
> > is clarity, but not that any of the likely readings make it non-Open.
> >
> > I also elided some points that might be re best practices, but IMO it
> > isn't entirely clear what the best practice in each case is, and they
> > don't have any bearing on conformance. Coped below with some of
> > Daniel's text and my comments. I think if we keep these in any form
> > they should be in a postscript/addendum and clearly demarcated as not
> > bearing on conformance:
> >
> > 1. it doesn't explicitly make sure how to reference the actual data
> > holder. (Meaning how to "mention the source"? I'm not sure this is a
> > problem. Overspecification can be more of a problem than
> > underpecification of attribution.)
> > 2. it doesn't explicitly make sure how to reference the license text
> > itself. (This is a minor point, but could be more explicit, maybe
> > provide canonical URI for refernecing license? This has nothing to do
> > with being conformant or not.)
> > 3. it doesn't explicitly make sure that it will be compatible with all
> > further versions of the license. (Why should it? It has no copyleft
> > aspect.) << this means that content that is licensed withv1.0 can
> > easily be upgrated to v1.1 ... Yes I know there's a case for such, but
> > it is an edge case unsupported by all(?) permissive licenses to date;
> > I don't know why they should.
> >
> >
> >
> > Tell me I'm wrong!
> > Mike
> >
> > On Mon, Mar 18, 2013 at 8:58 AM, Daniel Dietrich
> > <daniel.dietrich at okfn.org> wrote:
> >> Dear all,
> >>
> >> thanks to all for your comments.
> >>
> >> I would like to consolidate this into a short replay to the people in
> charge at the Ministry of the Interior as they requested the Advisory
> council to check the license for compliance with the OD.
> >>
> >> I have booted this pad to draft this answer:
> >>
> >> http://opendefinition.okfnpad.org/DE-OGD-license
> >>
> >> Please help me to get this done, so we can send it out asap. Thanks!
> >>
> >> Kind regards
> >> Daniel
> >>
> >>
> >>
> >>
> >> On 3 Mar 2013, at 00:21, Mike Linksvayer <ml at gondwanaland.com> wrote:
> >>
> >>> On Thu, Feb 28, 2013 at 9:07 PM, Andrew Stott
> >>> <andrew.stott at dirdigeng.com> wrote:
> >>>> It’s unclear to me what the precise meaning of the requirement is.
> >>>>
> >>>> (1) is it saying (a) that all the actual changes must be documented
> (Herb’s
> >>>> interpretation); or is it saying (b) that the attribution statement
> must be
> >>>> different if the data is changed (for instance from “reproduces data
> from
> >>>> Ministry” to “modified from data from Ministry”)?  The original German
> >>>> refers to a “Veränderungshinweis” which Google translates as a “Change
> >>>> Notice”, which could mean either a description of the changes or
> simply a
> >>>> notice that changes had been made.
> >>>>
> >>>> I recall seeing an Australian example [1] of CC-BY which required a
> >>>> different attribution statement if that data had been changed.
> >>>>
> >>>> (2) is it saying (a) that the licensor can later at its discretion
> instruct
> >>>> the licensee to remove the attribution (Herb’s interpretation); or is
> it
> >>>> saying (b) that the licensor can specify *in advance* that an
> attribution
> >>>> should *never* be given if the data is changed?
> >>>>
> >>>> I agree with Herb that if the meaning is 1(a) and 2(a) then it is
> >>>> non-conformant – and 1(a) would be burdensome and 2(a) would leave
> >>>> indefinite uncertainty.
> >>>>
> >>>> However requiring simply a different fixed attribution text (as in
> >>>> interpretation 1(b)), or no attribution at all (2(b)), if the data
> has been
> >>>> changed would seem to me to be a conformant way of the licensor
> distancing
> >>>> himself from modified data where there was reputational or moral
> liability
> >>>> involved.
> >>>
> >>> I'm not sure what the clause means either, but my best guess is a weak
> >>> version of 1(a) together with 2(b) (referring to Andrew's descriptions
> >>> above, not license sections). By weak, I mean that it doesn't require
> >>> a machine-readable version of changes. It would be great if the
> >>> language were more explicit, or if it already is, a German speaker
> >>> could explain.
> >>>
> >>> But I'm not sure any of above readings would make the proposed
> >>> attribution license non-Open. 2(a) is problematic, but then all
> >>> previously-deemed-Open CC BY and BY-SA licenses have that. As they do
> >>> require a weak version of 1(a). And previously-deemed-Open licenses
> >>> includes a strong version of 1(a), in particular ODbL does, as an
> >>> alternative to full source distribution (which may or may not be less
> >>> onerous depending on circumstances; OTOH maybe as an alternative it is
> >>> OK, but without full source option it is not).
> >>>
> >>> Though I'm not certain above readings would make proposed license
> >>> non-Open, I'd recommend both making conditions more clear and ensuring
> >>> they are minimal -- this presumably aims to be a permissive
> >>> attribution-only license; its effectiveness as such will be greatly
> >>> limited by difficult to understand and possibly understood as onerous
> >>> conditions.
> >>>
> >>> Mike
> >>
>
>

-- 
Herb Lainchbury
Dynamic Solutions Inc.
www.dynamic-solutions.com
http://twitter.com/herblainchbury
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/od-discuss/attachments/20130319/95752ef1/attachment.html>