Re: [OSM-legal-talk] Lawyer responses to use cases, major problems
Frederik Ramm wrote: I'm surprised that nobody else seems to see a problem in this. Am I perhaps barking up some completely imaginary tree? Not at all; I am still reading through the draft, and have exactly the same concern. It may be I have misunderstood how this is intended to apply, but I think both 4.6a and 4.6b end up making derivative databases (effectively any mechanical processing of the original content whatsoever, IMO) problematic. In many cases, generating a file containing all of the alterations will be at least as much work as making the derivative database available (leaving aside that publishing these alterations may reveal some proprietary information, making it less likely for OSM data to be used). That is not always practical, and if all my transformations are destructive then I don't think it's even useful (compared to simply making a copy of the original database available, to ensure the source data is never lost if openstreetmap.org goes away). I'm not sure what format a file containing all of the alterations would take. Does this mean a machine-readable list of the exact transformations that were performed, or simply a human-readable summary of the transformations made? If I map our fixed point lat/lons to 32-bit floats, I will create a derivative database (32-bit floats can't represent all integers exactly, so I've lost some information and can't go back). Do I need to publish exactly which floating point value each integer was mapped to, or simply say I converted all lat/lons to floats? The latter makes more sense, but do I also need to specify that they're IEEE floats and which of the four IEEE rounding modes were used? I don't have a better phrasing for 4.6b, but I would like to allow alterations to be specified as: - A literal set of transformations to apply (e.g., a lookup table or code that could be executed to apply the transform). - A human-readable set of instructions that are reasonable Introducing reasonable means I can have my lawyer argue with yours over whether convert to floats is a reasonable summary or not, and not have to worry about being sued because I used an unusual rounding mode like round-to-infinity and forgot to mention it. It also means you can publish imported into PostGIS using this schema as your alteration, and not have to provide the literal derivative database created by your particular version of PostGIS when run on a specific platform/OS. -dair ___ d...@refnum.com http://www.refnum.com/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] 23rd Dec board meeting
Peter Miller wrote:
Is there not a large potential conflict of interest between SteveC in relation
to his driving this change within the Foundation and also being a director of
a company that could well benefit from the OSM project not offering a full set
of services? I don't know, but I certainly don't have the information to feel
comfortable with this initiative until we have some more facts available to
us.
I think this is uncalled for.
There are any number of technical things you need to think through before
switching from a system that pretty much works to something (anything) else.
While it's valid to question what those things are, and their significance,
I don't think you can jump from that to it all being an evil plot hatched in
CM's volcano lair.
You argue that anyone with a commercial interest in OSM (e.g., me) who's
listed on the {{PD-user}} page (me again) has a potential conflict of
interest.
You could argue that as a commercial interest who's been pushing very hard
for the licence issue to be resolved, perhaps you have some ulterior motive
too...
Nothing useful comes out of that kind of discussion.
The current progress on the licence is certainly frustrating for those of us
who are thinking about how our companies can best use and contribute to OSM,
but I suspect it's been a very frustrating process on the OSMF side as well.
E.g., we have no idea what the background to all communications with Jordan
had broken down was, or what impact that has had. It would be nice to know
what happened, but having a public discussion about that while trying to
resolve whatever the issue was probably wouldn't have been helpful.
I would definitely recommend you stand for the OSMF next year, as I think
you could make a valuable contribution to the process (e.g., I agree with
your thinking re the trademark).
I don't know if you'll find the grass is any greener though.
Although the licence project seems to be moving forward very slowly, it is
at least moving (vs what happened previously, where we had endless
GPS-vs-BSD debates on the mailing list but no real progress whatsoever).
-dair
___
d...@refnum.com http://www.refnum.com/
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Paid services from OSM
Simon Ward wrote: I¹d rather those providing the PostGIS data be obliged to provide their source (planet dumps, whatever) to the same people. ... The example was convoluted, but I hope it illustrates my point that mere translation should not be excluded from being counted as a derived database. If you're obligated to provide the source to your translation, providing access to the translation itself seems pointless. One difference between OSM usage and free software is that a great many uses of OSM will be a one way process. Tags will be discard or translated from the OSM model to a simpler model, IDs might be lost, coordinates might be truncated, etc. What's left might be useful for reconstructing OSM in an emergency, but the planet dump that went into the process would be much more helpful. If the data is just a translation from OSM (or some data literally derived from it, like a precalculated routing table/simplified graph/etc) then making that accessible is pointless. If the data is augmented or modified in a significant way then by far the best way (for everyone: OSM as a whole, and the translator) to pick up those changes would be to simply insert them into OSM and pick them up downstream. If that can't be done then, yes, those changes should be published in a form that could be used by OSM. I don't see that necessarily has to be via the translated database though. A .osm patch, or a modified planet file, would be easier to create and easier to merge in (if they turned out to be something we wanted). I believe the goal should be to pick up changes that improve OSM, rather than to use OSM as a lever to force open other file formats. If the translation doesn't improve the OSM data, and you get the source planet dump with the translation, what would you do with the translation that you couldn't do better with the planet dump? If the translation does improve the OSM data, but you get the source planet dump plus the improvements as a .osm file, requiring the translation itself be a public format seems excessive if the goal is to improve/protect OSM. -dair ___ [EMAIL PROTECTED] http://www.refnum.com/ ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
