[OSM-legal-talk] Licenses for Produced Works under ODbL
Michael Collinson
mike at ayeltd.biz
Tue Oct 30 12:30:36 GMT 2012
Hi Igor and fellow legal-talk,
A rather long email, so summary: I am rather hijacking Igor's email, but
I hope it will help provide an answer though not immediately. The
present "Trivial Transformation" Community Guideline, [1], is applying
tactics and discussion without having any overriding strategy or
conclusion. It is therefore confusing and difficult to develop further
as is. I propose that we base a re-write on: *OpenStreetMap considers
**Open Data to be a usefully collected set of intelligently or
machine-made physical observations only. Purely algorithmic
augmentation of data and re-casting of data to use, store or transmit it
in different manners is not part of the data IP. Share Alike may however
apply to physical observations inside the augmented or re-cast data; in
this case the physical observations must be provided to the public in a
commonly used or documented open format as per ODbL clause 4.6b*. The
wording might be improved, but that is the general idea. If follows the
general direction of discussion within the License Working Group but
takes it to a more extreme, but I think logical, conclusion. Argument
follows using Igor's posting.
> I've read it carefully and it doesn't really answer my questions, it
just raises some new ones.
I rather feared that.
> *is there a place for proprietary/closed source software in OSM
ecosystem*?
Yes, that is a key question. I will argue below that yes there
absolutely is a place. However, this is not necessarily a consensus view
and it is presented for discussion.
> I see some serious issues with the way how we approach the whole ODbL
thing.
I do not think the issue is ODbL. The issue is the application of Share
Alike to open data under whatever license. ODbL 1.0 has made a
tremendous leap forward here. But it is like climbing a mountain. You
need to climb the first ridge to start understanding what the rest of
the climb looks like. I understand this causes issues for commercial
companies, but our primary concern is growing open geodata and *very
carefully* evolving open data IP to lower barriers on everyone using it
in "creative, productive, or unexpected ways".
To properly answer Igor, we need to do two things:
1) Establish a general principle that the OSM community is happy with.
2) Determine whether the general principle can be translated into
unambiguous wording without gotchas and whether it jives with specific
issues, for example as per Frederik's email. It should be presented as
a well-written Community Guide line. Once really understood, we can
then look at whether ODbL can be improved and give input for other open
licenses, such as CC.
Here is what I, personally, see as the general principle and the
argument for it.
OSM, and possibly any open data project, is about collecting a set of
physical observations and making them open in an open format.
Additionally, (and not used by other projects, like US government data),
we want to apply a certain amount of pressure on folks who take
advantage of the results to open up and share more physical observations
of their own. For that we use Share Alike. Some like this, some don't.
But it is what we do. It has some great advantages for commercial
entities; it has some headaches.
The key words here are "physical observations".
Messing around with fancy algorithms and neat ways to store data
efficiently provides no added value to the data itself. It does not
generate more observations. It may provide more interesting information
or knowledge, but that is a creative process unrelated to the data
itself. [This is the contentious bit, counter comments welcome].
It is a somewhat weak software IP analogy, but if Igor writes an amazing
book using vanilla Libre Office, then what he does with the book is
irrelevant to Libre Office licensing. He has not done anything to
improve Libre Office.
The major exception to this is if Igor has somewhere along the line
added some more physical observations. Share Alike may apply to these
and proprietary transformation or storage mechanism may block access.
The obvious solution is to make available the physical observations,
just the observations, in an open format, such as OSM XML.
And so hence the first attempt at creating clear, unambiguous wording
with no side-effects:
"*OpenStreetMap considers Open Data to be a usefully collected set of
intelligently or machine-made physical observations only. Purely
algorithmic augmentation of data and re-casting of data to use, store or
transmit it in different manners is not part of the data IP. Share Alike
may however apply to physical observations inside the augmented or
re-cast data; in this case the physical observations must be provided to
the public in a commonly used or documented open format as per ODbL
clause 4.6b *."
[1]
http://wiki.openstreetmap.org/wiki/Open_Data_License/Trivial_Transformations_-_Guideline
On 29/10/2012 18:07, Igor Brejc wrote:
> Hi Michael,
>
> First of all, thanks for the link. I've read it carefully and it
> doesn't really answer my questions, it just raises some new ones.
> Those guidelines, as they are written, treat the issue of
> proprietary/closed source code very superficially and without
> considering too much the practical consequences. They also don't
> really answer the question "what is a Database". Let's take, for
> example, the statement "Rendering databases, for example those
> produced by Osm2pgsql, are clearly databases". First of all, what are
> "rendering databases"? I don't share the same "clearliness" of that
> statement, frankly.
>
> Another issue is "machine-readable form" of an algorithm. Who says I
> should interpret that as a source code? And if I do, under what
> license can/should/must I release the source code? I'm certainly not
> going to release my work under the Public Domain.
>
> I think the core issue that needs to be addressed and answered is: *is
> there a place for proprietary/closed source software in OSM
> ecosystem*? If we follow the "strict reading" logic of the mentioned
> guideliness and the one expressed in Frederik's answer, I would
> certainly have to say the answer is NO.
>
> I see some serious issues with the way how we approach the whole ODbL
> thing. As someone who has invested a lot of time and energy into OSM
> and who is trying to find a business model that would enable me to
> stay in the OSM domain, I think the core questions about ODbL have not
> been answered and this scares people/companies off. If the OSM
> community wants all the OSM-based software to be open source, then
> please say so. But please treat all the players the same: Apple, esri,
> Google and one-man-band companies.
>
> Best regards,
> Igor
>
> On Mon, Oct 29, 2012 at 9:34 AM, Michael Collinson <mike at ayeltd.biz
> <mailto:mike at ayeltd.biz>> wrote:
>
> Hi Igor,
>
> I wonder if this resource helps with your question?
>
> http://wiki.openstreetmap.org/wiki/Open_Data_License/Trivial_Transformations_-_Guideline
> (a work in progress)
>
> Mike
>
>
>
> On 22/10/2012 18:45, Igor Brejc wrote:
>> Hi,
>>
>> Thanks for your clarifications, everybody. I was under the (looks
>> like wrong) impression the produced work must also be available
>> under the ODbL license.
>> One issue still bugs me though:
>>
>> If the closed software you have used did not work on the data
>> directly, but on some sort of pre-processed or augmented
>> data, then *that* would be the data you have to hand over.
>>
>>
>> What does "pre-processed or augmented" data really mean? OSM data
>> has to be preprocessed to get to the form suitable for rendering.
>> Some examples of preprocessing:
>>
>> 1. Importing it into PostGIS and flattening the geometries
>> (like Mapnik does it).
>> 2. Generalizations: simplifications of roads, polygons etc.
>> for a certain map scale.
>> 3. Finding suitable label placements.
>> 4. Extracting topology from the data (like multipolygon
>> processing, merging of polygons, road segments etc.).
>> 5. Running other complex algorithms on the OSM data.
>>
>> This preprocessing can be done "on-the" fly or (in case of
>> Mapnik) as a separate prerequisite step.
>>
>> Igor
>>
>> On Mon, Oct 22, 2012 at 2:06 PM, Frederik Ramm
>> <frederik at remote.org <mailto:frederik at remote.org>> wrote:
>>
>> Hi,
>>
>> On 10/22/12 12:07, Igor Brejc wrote:
>>
>> 2. I generate a PDF map from that extract using an
>> unpublished,
>>
>> closed-source software. The map includes the
>> appropriate OSM
>> attribution text.
>>
>>
>> 1. Is this possible?
>>
>>
>> Yes (assuming that the PDF is not a database).
>>
>> > 2. What are my obligations in terms of ODbL license? What
>> (if anything)
>>
>> > do I have to provide, publish etc.?
>>
>> Recipients of the PDF, i.e. anyone who views iStockPhoto,
>> would have the right to ask you to hand over the database on
>> which the map is based. You would then have the option of
>> saying "it's plain OSM, simply download it from <X>", or
>> actually give them the data.
>>
>> If the closed software you have used did not work on the data
>> directly, but on some sort of pre-processed or augmented
>> data, then *that* would be the data you have to hand over.
>>
>> 3. Would there be a difference if it was PNG/SVG instead
>> of PDF?
>>
>>
>> I don't think so.
>>
>> 4. Can the buyer of such a map then password-protect his
>> own resulting
>>
>> work (which includes that map)?
>>
>>
>> Yes. You will have sold him the work under the condition that
>> he continues to attribute OSM, but other than that he has no
>> obligations (unless you put some in).
>>
>> If you sell the work with an OSM attribution but without the
>> condition to perpetuate that attribution, you may be in
>> breach of ODbL or you may not; this depends on how you
>> interpret the "suitably calculated to make anyone ... aware"
>> clause.
>>
>> Bye
>> Frederik
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/legal-talk/attachments/20121030/433047f9/attachment-0001.html>
More information about the legal-talk
mailing list