Hi Michael, For my part, I really like your proposed wording and I hope we'll reach consensus on these issues in a way that satisfies both "producers" and "consumers" of OSM data.
Best regards, Igor On Tue, Oct 30, 2012 at 1:30 PM, Michael Collinson <m...@ayeltd.biz> wrote: > ** > 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>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>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
