[OSM-legal-talk] "A Creative Commons iCommons license"

Sat Feb 28 14:27:07 GMT 2009

On Sat, Feb 28, 2009 at 12:57 PM, Richard Fairhurst <richard at systemed.net>wrote:

>
> 80n wrote:
> > Indeed it is exactly this case I had in mind, where the license gives
> > the contributor fewer rights.  It creates a class of derivative works,
> > called Produced Works, that are not share alike.
>
> No. This is really, really important.
>

No.  CC-BY-SA does not have a class of derivative works that are not share
alike.  ODbL does.  Under ODbL the share alike clause does not apply to any
derivative works (except derived databases).  This is clearly *less*
restrictive than CC-BY-SA.  We are asking people to agree to a weaker
license in this particular respect.

>
> The concept of a "Produced Work" is not ODbL magically exempting more works
> from copyleft. Produced Works is simply ODbL's effort to _define_ something
> that exists in all copyleft licences. It isn't a new class of restriction.
>

Yes it is.  CC-BY-SA does not exempt any derived work from share alike.
ODbL does.

>
> * CC-BY-SA uses two terms to describe how work "uses" the original:
> Derivative Work and Collective Work.
> * ODbL uses three terms: Derivative Database, Produced Work and Collective
> Database.
>
> Very roughly (I'm generalising here), in both cases, Derivatives refer to a
> situation where the entire result is copyleft, Collectives refer to
> something where only part of it is. Produced Works are a subclass of the
> latter, not a new class at all. The data component is still copyleft, and a
> stronger copyleft than CC-BY-SA gives, but other independently sourced
> components may not be.
>
> We have this at the moment. Think of CloudMade's* routing application. Its
> raison d'etre is OSM data, and anything derived from that is theoretically
> copyleft (not, ahem, that CC-BY-SA requires it to be contributed back). But
> no-one is suggesting that CloudMade have to release their code under
> CC-BY-SA. The GPL is similar. If you compile a program with GCC, the binary
> contains all the optimisations that are probably the most "creative" aspect
> of GCC, so in moral terms it could be considered a derivative. But no-one's
> suggesting your code therefore has to be GPLed.
>
> ODbL just uses a new term to help firm up the boundaries. The fact we're
> still arguing five years on (cf flosm.de) about what's derivative and
> collective when CC-BY-SA is applied to data shows how better terminology is
> desperately needed.
>
>
> FWIW, I do think that the ODbL Produced Work provisions _may_ need
> rewording. There seems to be a myth around here that a Produced Work can be
> public domain. Clearly it can't - not in the traditional sense of PD -
> because of 4.7 (the Reverse Engineering provision that dictates that the
> data is still copyleft). If there is any restriction on a work, it isn't
> PD.
> This is perhaps not apparent and could do with hardening up.

I agree that a Produced Work is not PD.  Strictly it's licensed as an "ODbL
Produced Work", but as you say it's very hard to figure out what rights such
a work has just from trying to read the ODbL.  Redrafting is required to
make this part of the license usable.

>
>
> > The attribution is to the owner of the database, not the author of the
> > work.  There is no requirement in ODbL to provide attribution to the
> > authors of the database's content.  Indeed the ODbL asserts that it
> > provides no protection over any of the content, just on the database
> > as a collective whole.  It makes the provision for the database content
> > to be protected by some other mechanism, such as copyright, but we
> > see that the proposed FIL license doesn't provide that protection.
>
> Again, this hinges on whether FIL _is_ what's proposed. I don't believe
> that
> was Jordan's intention.
>

As I understand it Jordan is not our lawyer and cannot advise us on whether
or not we should use the FIL.

According to Grant's email of Feb 27th OSMF have been advised by Clark Asay
of Wilson Sonsini to use the FIL.  Grant can you publish a copy of that
advice so that we can see exactly what was said please?

>
>
> The wiki is contradictory: in one place it says
>  "Sign up page now states you agree to license your changes under both
> CCBYSA and also ODbL."
>
> but in another
>  "when you upload your individual contributions, you agree to licence them
> under the Factual Info Licence."
>
> You're on the OSMF board, you can tell us. :)

The FIL has never been discussed by the OSMF board.  I know no more about it
than you.

> For what it's worth, I
> distinctly remember Jordan telling me in Reading that he expected
> individual
> users to license their contributions under ODbL; and though in my heart of
> hearts I'm a PD person and prefer things like the FIL, I too think that
> ODbL
> is pragmatically what OSM should be adopting here.
>
> > > [...]
> > > Database rights only exist for collections.  A single person's
> > > contribution may not, on its own, be a database.
> > [...]
> > Let me clarify.  The database right applies to a collection of facts.
> > An individual contribution may not qualify as a database if it is not
> > a significant collection of facts, not because it is just one person.
> > Most individual contributions will be insufficient *on their own*
> > to constitute a database.
>
> In which case they're uncopyrightable and don't qualify for any protection
> under CC-BY-SA either, so it's moot. I don't quite see your point.
>

You are implying that something that is small enough to fall outside the
database right is also small enough to fall outside of copyright.  They are
two different tests.  To take an extreme example, an easter egg comprising a
single node may be copyrightable as a creative work, but it is not a
database.

If individual contributions could be licensed under ODbL then Clark Asay
would not have recommended the use of FIL.

>
> >> I believe Jordan's original intent (but he can say this much better than
> >> me, and contradict me if necessary) was that users' contributions could
> >> individually be licensed under ODbL.
> > If that were the case then the FIL license would not be necessary.
>
> Yes, absolutely. Indeed for most people FIL is irrelevant. It's a specific
> clarification to cover an issue in Australian law:
>
>
> http://lists.openstreetmap.org/pipermail/legal-talk/2008-February/000607.html
>
> In general terms, FIL covers the individual, atomic, uncopyrightable facts.
> ODbL covers your aggregation of these into your contributions to OSM.
>

According to that thread FIL is basically PD with a special case for
Australia.  So are we asking everyone to sign away *all* their rights?  That
seems a lot weaker than asking them to contribute under a CC license.  CC
might not be enforcable in some places, but it's a lot more enforceable than
PD.

>
> > Attribution to individuals is really really important to many
> > contributors.
> > They give their time and effort, attribution is the *only* reward for
> > these
> > people.  They want to be able to say "I did that".
>
> Fine. So let's give them attribution. We don't at the moment, by the way.
> ;)
>

We are not giving contributors anything.   Contributors are giving us
content and requiring that anyone using that content provides attribution.
Don't look at this from the wrong side of the fence.

And we should not confuse the *right* to attribution with what happens in
practice.  Contributors have the right to demand attribution, the fact that
some contributors have not exercised that right does not take it away from
others.

>
> cheers
> Richard
>
> * or anyone else's, for that matter
> --
> View this message in context:
> http://www.nabble.com/%22A-Creative-Commons-iCommons-license%22-tp22260709p22261842.html
> Sent from the OpenStreetMap - Legal Talk mailing list archive at
> Nabble.com.
>
>
> _______________________________________________
> legal-talk mailing list
> legal-talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/legal-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20090228/2ad21fac/attachment.html>