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 <m...@ayeltd.biz
<mailto:m...@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
<frede...@remote.org <mailto:frede...@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
_______________________________________________
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
