[od-discuss] no endorsement clauses and OKD conformance (was Re: Up and Coming: Open Government Licence in Canada (OGL-C))

Mon Dec 17 17:39:17 UTC 2012

On Sun, Dec 16, 2012 at 1:06 AM, Herb Lainchbury
<herb at dynamic-solutions.com> wrote:
> I have been going back and forth over this one.
>
> As conditions, the clauses from the OGL-C could be seen as contradictory.
>
> acknowledge the source of the Information by including any attribution
> statement specified by the Information Provider(s) and, where possible,
> provide a link to this Licence;
> ensure that you do not use the Information in a way that suggests any
> official status or that the Information Provider endorses you or your use of
> the Information;
>
> One meaning of the word "endorse" is "approval".  So, Do I have approval to
> use this data or not?  Not exactly the same meaning, I know, but it's close.

FWIW CC-BY and BY-SA have had similar, conceivably conflicting or at
least confusing attribute/do-not-imply-endorsement terms for about 10
years now, and I don't know that it has been an issue. Maybe not
enough lawyers in governments-gone-tyrannical have read the licenses.
:-)

> I think the "move to no-permission" suggestion  for OGL-C is valid.  I think
> it satisfies both the conditions of the definition and the desire to remind
> folks that they aren't getting extra things like endorsement.  I really hope
> they can move it.

It is absolutely the right thing to do, regardless of which side of
open the current language marginally falls on.

I started a draft document for feedback from this group; just an
outline with some open questions
http://opendefinition.okfnpad.org/ogl-c-draft-feedback

> Written as conditions, I think one effect of these clauses is that they turn
> a potential fraud allegation into both a fraud and copyright infringement
> allegation.  e.g. If this license was in place and someone was accused of
> saying that the publisher endorsed them, then they would be facing not only
> a possible fraud allegation, but also they are now using the data without
> permission, so they have committed a copyright offence as well.  Without
> this clause they are accused of fraud, which is bad enough, but they are
> both serious.  I don't know enough about either of these to go any further
> with this line of thinking but it's one additional twist I thought of and
> perhaps it's meaningless.

It seems to me the do-not-mislead term thankfully already removed from
OGL-C is far more ripe for abuse; falsely implying endorsement could
be thought of as a tiny subset of any kind of misleading, and can
easily be dislaimed, wheras something like "nothing in the above
information is intended to mislead you" is nonsense. That and history
are the reasons I'm saying may-not-imply-endorsement may be just
barely OK, while do-not-mislead is definitely not. But certainly not
including may-not-imply-endorsement is a better practice that we
should encourage.

> Practically though, for the vast majority of folks, the effect is clutter.
> And though I would prefer that the license be clear and concise, I think one
> of the reasons the open definition exists is because we realise that the
> license writers aren't always going to be able and willing to achieve that
> so we provide this reference and conformance test to add some clarity and
> ease of use.  If we can't get some movement on this clause in the OGL and
> it's forks I would be tempted to update the definition.  The problem we face
> is how to allow it.  Do we add it to the integrity section as you suggest?
> Or, do we need to actually allow another type of restriction, which is how
> it's currently worded in the OGL-C.  And if we allow this restriction, then
> why not others?  Slippery.

Right. Just to be clear, I'm suggesting adding as a comment in the
integrity section, equivalent to the annotation in the OSD. One would
still have to squint to justify OKD conformance. :-)

Mike