[OSM-talk] License plan - what data would need deleting
80n
80n80n at gmail.com
Wed Mar 4 11:30:39 GMT 2009
On Wed, Mar 4, 2009 at 11:18 AM, Ed Avis <eda at waniasset.com> wrote:
> You have discussed some elaborate plans about what data from a
> non-relicensing
> contributor would have to be deleted and what would have to be kept.
>
> In the worst case, in the event of a dispute, do you really fancy trying to
> convince a court of law that the elaborate heuristics you applied are
> sufficient
> to make the map completely independent of the work of the users who said
> 'no'?
>
> The only sound rule that can be sure to stand up in court is to delete all
> data
> from the contributors who didn't give explicit permission, and all data
> that
> depends on it. Period.
>
> You may think this is unnecessarily paranoid. Indeed it is: but if the
> relicensing exercise doesn't put the project on a legally unassailable
> footing,
> it is not worth doing. At the moment we can say with certainty that 100%
> of the
> contributors have clicked 'yes' to an agreement to distribute their changes
> under
> CC-BY-SA. Any legal niceties tidied up by a move to a different licence
> are good
> to have, all other things being equal, but are hugely outweighed if the
> data
> becomes a questionable mishmash of contributions that have agreement, and
> those
> that don't have agreement but pass some odd set of rules we invented
> ourselves to
> convince ourselves that we didn't need to get permission.
>
I believe this is a wise approach. OSM is traditionally very conservative
about using any data not from a know clean source. On the grand scale its
relatively easy to capture map data, the value of a clean database far
outweighs the risks associated with infringing anyone's copyright. We
should apply the same degree of conserativism to our CC-BY-SA licensed data
as we would to any other copyrighted data.
Perhaps we are thinking about this all wrong. If we considered the ODbL to
be a license fork of the project (albeit a friendly from the inside fork)
then it makes it much easier to think about how all this should happen.
80n
>
> --
> Ed Avis <eda at waniasset.com>
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090304/72da56fd/attachment.html>
More information about the talk
mailing list