[Osmf-talk] New license change proposal status

[80n]

On Fri, Dec 4, 2009 at 1:04 AM, Matt Amos <matt at asklater.com> wrote:

> 80n wrote:
>
>  On Thu, Dec 3, 2009 at 4:05 PM, Matthias Urlichs <matthias at urlichs.de<mailto:
>> matthias at urlichs.de>> wrote:
>>
>>    On Do, 2009-12-03 at 15:09 +0000, 80n wrote:
>>     > You've tried to show that you've addressed the question of
>> complexity
>>     > in your proposal document by referencing a human readable version of
>>     > the license.
>>
>>    That's a totally sensible thing to do when the original document cannot
>>    be simplified.
>>
>>    Please tell us exactly what you think can be simplified instead of
>>    simply calling for unspecific simplification, particularly this late.
>>
>> I'm not calling for simplification.  I'm calling for the LWG to properly
>> acknowledge the risks associated with a compex legal agreement.
>>
>
> ok - that's something constructive i can raise at the LWG meeting... uhh...
> later today.
>
>
>      > The ODbL is a complex license that is new and untried.
>>
>>    True. We don't know that there are risks involved with the ODbL, an we
>>    don't know whether it's broken.
>>
>>    However, we DO know that the current CC license is SEVERELY broke.
>>
>>
>> Maybe it's one of those things that doesn't work in theory but does work
>> in practice.  OSM has been using it very successfully for over five years
>> now without any serious problems.
>>
>
> who was it that said something like "absence of evidence is not evidence of
> absence"? we had the same discussion on legal-talk a while ago and there was
> a variety of opinion, but i stick by the basic principle; if several civil
> engineers (lawyers) tell you that your house (license) is likely to fall
> down (be legally indefensible) and suggest something better, wouldn't that
> be good advice to heed?
>
>
>  If it's SEVERLY broke then you'd have to say that OSM itself is SEVERLY
>> broken and there's nobody saying that.
>>
>
> i don't follow your reasoning. CC BY-SA is severely broken, but no-one is
> saying that OSM is fundamentally broken. the license is broken, but that's
> just one element, and one that we can fix.
>
>
>  There are however multiple risks associated with the license change that
>> could break the project.  In the most general terms the ones that come to
>> mind are:
>>
>
> my personal feeling is that the project is as strong as its community and
> that our community is intelligent and strong enough to survive a license
> change.
>
>
>  * The assignment of rights to OSMF introduces a range of potential failure
>> points
>>
>
> there is no assignment of rights to OSMF. we discussed this in the meeting
> which you cited earlier. the contributor terms leaves full database and
> copyrights (if any) with the author and OSMF is only a licensee.
>
>
>  * The lack of any coherent license and therefore protection for the
>> database content (as opposed to the database)
>>
>
> a lot of jurisdictions do not recognise any rights inherent in single,
> factual contents. it's very difficult, if not impossible, to create a
> global, coherent license for things for which there are no inherent rights.
>
>
>  * The weakness of the contract elements of the license when not supported
>> by click-through
>>
>
> indeed. but the alternative is putting a click-through in front of all
> methods of accessing OSM data, which i don't think anyone wants. it's true
> that the contractual elements are weaker without a click-through, but there
> are mitigations we can use to retain some of the strength.
>
> it's also worth noting that CC BY-SA doesn't work, regardless of the
> presence of a click-through or not, so this isn't really an argument that
> works in the context of CC BY-SA vs. ODbL. it works for ODbL vs. PD, though.
>
>
>  * The exclusion of the reverse engineering clause (which couldn't be made
>> to work, so just got dropped)
>>
>
> there were several questions about whether the reverse engineering clause
> meant that produced works weren't compatible with the CC BY-SA license.
> since such compatibility was a specific use case, LWG undertook legal
> advice, the result of which (you'll remember, it was at that same meeting
> you cited earlier) was that the reverse engineering clause wasn't strictly
> necessary, and had been included only for the avoidance of doubt.
>
>
>  * The loss of significant contributors and their data
>>
>
> this is a problem with any move away from the current license. however,
> according all the legal opinions i've heard: CC BY-SA is broken and, if we
> want a license which works, we have to move. this is regrettable, and LWG is
> trying to do everything it can think of to reduce the loss of contributors
> and data.
>
>
>  * The incompatability of ODbL with itself and with OSM's contributor
>> terms.
>>
>
> ODbL, as far as i know, is compatible with itself. it is incompatible with
> the contributor terms, but as i explained earlier, it's a choice between
> allowing ODbL-licensed contributions and greater relicensing flexibility to
> allow for an uncertain future. it's an either-or choice and your opinion of
> the relative benefits may be different from mine.
>
>
>     Therefore,
>>
>>     >   This makes it higher risk than the existing license.
>>
>>    ... your assertion is questionable, if not false.
>>
>> The onus of proof ought to be on those proposing change.  Can the LWG
>> demonstrate that their proposals reduce the risks or at least do not
>> increase the risks?
>>
>
> i absolutely agree. here are the current risks:
>
> * CC BY-SA, according to all legal opinion i've received, is at best risky
> for protecting our data and, at worst, provides no protection at all. the
> current license, in certain jurisdictions, could result in the use of our
> data without compliance the attribution and share-alike conditions.
>
> here are further problems with the current license:
>
> * it protects "works" and not data. that means anyone can take the OSM
> data, improve it, and distribute the resulting "works" under the CC BY-SA
> license. note that this doesn't necessarily mean that the data can be
> incorporated back into OSM, as the provider may claim other rights (such as
> database rights) over the data which would prohibit that.
>
> * the attribution requirements aren't clear. CC BY-SA is designed for use
> with creative works which typically have a few authors, not 18,000 or
> whatever OSM has at the moment.
>
> here are the risks i can see with the new license proposal:
>
> * data loss. there will be some people who disagree with the proposal, or
> who can't be reached.
>
> * no perfect protection. the new license is weaker in jurisdictions which
> don't recognise database rights or copyrights on collective data than it is
> in the EU and US.
>
> * choice of law / ported license. the OSMF legal counsel and ITO's counsel
> have both expressed doubts about the lack of a "choice of law" clause in the
> ODbL.
>
> here are some comments on the previous points:
>
> * as i said earlier, any license move is likely to result in some data
> loss. we would *really* like to reduce this to the minimum possible, but
> it's my strong belief that we cannot stay with the current license.
>
> * copyrights on creative works have a much better international foundation,
> but OSM aims to be a representation of the real world (i.e: factual) and so
> can't take advantage of this rare example of international bullying^W
> cooperation.
>
> * the ODbL's author doesn't believe there is a problem with the lack of a
> "choice of law" clause. the lack of consensus is worrying, but since none of
> us are lawyers specialising in international IP law, i'd say it's better to
> let ODC sort it out in later versions of the license.
>
> the conclusion, in my opinion, is that the new license proposal isn't
> perfect, but protects the data and the contributors attribution and
> share-alike rights much better than the existing license. in my opinion the
> risks associated with continuing with the current license are unacceptably
> high.
>
> Matt
Thank you.  I appreciate your considered and balanced response.

80n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20091204/3117dc41/attachment.html>