Re: [OSM-legal-talk] ODbL and publishing source data

[James Livingston]

On 1 December 2011 00:18, Jonathan Harley  wrote:

> By way of analogy: suppose I sent you a private email which included a
> license saying if you publicly use my email, you must share with me any
> other emails you combine it with. My email sits in your inbox together with
> other emails, and you can do searches across all of them. If it's a unix
> system, they're probably all in one single file. But have you really
> "combined" my email with your other private emails? My email is sitting
> there unmodified and completely independent of all your other private
> emails; it is not itself combined with them. So no, "storing next to" is
> not "combining". You can safely share a screenshot of your mail program
> without having to send me all your other private emails.


The problem with analogies is that they are analogies and aren't the same
as the original thing. As a similar one, what if instead you sent me your
mailbox rather than a single email, and I imported all your mail into mine
(so are probably stored in the same file). Although none of the actual data
(emails) have changes, they are stored together (possible even in a SQL
database rather than flat files).

I don't know if that would count as two collective databases or a single
derived database.


> If the rendering of the second output depends on the first dataset, the
> Produced Work created from the second dataset is not independent of of the
> first dataset.
>

No, the produced work isn't independent of it, but the datasets are still
> independent of each other, that's my point.
>

My point is that to actually do the rendering, you will have created a
single database containing both datasets in the process (albeit possible as
transient in-memory data structures). I don't think we're really
disagreeing, just both unsure as to where the line is and guessing on
different sides :)



>
>> I guess it's possible the rendering algorithm for the second dataset
>> could use the Produced Work from the first rather than the first dataset
>> directly, which may be okay except that it's arguable whether you are
>> reverse engineering part of the first database.
>>
>>
> Yes, I think that point's arguable - if the combined produced work is
> based on two previous renderings from the two datasets, you might be able
> to argue that those renderings are themselves databases, particularly if
> they use vectors - though it's a very murky area, because rendering usually
> involves throwing away lots of information. (For example, suppose two roads
> meet at a T junction, and I render them both in the same line style without
> names; you can no longer tell their IDs, tags, or even how many ways in OSM
> make up that rendered T shape.)


To give a more explicit example, consider if you rendered a map with a
white background containing all the OSM data excluding hotels (you can just
release the algorithm to remove hotels, which is trivial). You then did a
rendering of your hotel data, using an algorithm that tries to avoid
putting the hotels on a non-white section of the image.  The rendering then
indirectly depends on the OSM data, but not on the OSM database itself.


I guess that's the a question: if you write a program that reads data from
> two sources and uses both to produce it's output, are the temporary
> in-memory data structures considered derived or collective for the purposes
> of copyright and database right law?
>
>
Yes, I've puzzled over that one too. If in-memory structures count as
> derivative databases, then that would be the one you would have to ask for
> under ODbL, which only requires licensees to release the last in any chain
> of derivative databases. It would make that whole side of ODbL pretty much
> impossible to enforce if so.


Assuming that it does count as a derivative database for this point, it's
likely to be hard to impossible for them to release that since it only
existed for a brief period of time while it was rendering - it's quite
possible that the whole thing didn't exist at the same point in time as
data was processed progressively.



>
>  The answer probably depends on how the program is implemented, but given
>> that we won't know the implementation, how can we ever determine whether
>> someone's Produced Work requires them to release their database? If we say
>> we can't determine that, aren't we essentially saying that it's impossible
>> to enforce that part of the ODbL?
>>
>
> Even the attribution part of ODbL isn't necessarily easy to enforce - I
> suspect that the more complete OSM gets, the more difficult it will be
> sometimes to tell that a map with no attribution used OSM data. And yes,
> the share-alike part is much harder to enforce that that. It's not so
> gloomy really, though - in some cases we will know the implementation
> because it'll be open source, and most companies are professional and
> consider obeying the law pretty important.


Probably more important than the actual enforcement is the ability to t

Re: [OSM-legal-talk] ODbL and publishing source data

[Jonathan Harley]

On 30/11/11 06:02, James Livingston wrote:
On 30 November 2011 01:03, Jonathan Harley > wrote:


On 28/11/11 23:59, James Livingston wrote:

Depending on the rendering, it may not be the same. The
placements of name text can depend on other data so it's not
on top of something else, or POIs can be hidden if there are
too many in a given area.

In the first case (or combining layers in the browser), the
rendering of OSM data cannot depend on the location of your
hotels, and the rendering of hotel names can't easily depend
on what else is on the map. In the second case (combining data
before rendering) collisions can be avoided or the resulting
map altered.


Yes, but it's only the produced work, the rendering, which is
altered. You probably don't need to make changes to the OSM data
to acheive this.

So the OSM data and other data could remain independent. If they
do, then the mechanism for combining (and computer/s on which it
happens) is indeed irrelevant.


While that's true, you are combining the two datasource together prior 
to rendering.



Say I created some local postgres database tabled and loaded OSM data 
into it, and then loaded data from another source into it too. What I 
have is now a database derived from both OSM and the other source. If 
I then rendered that data to create a Produced Work, would my combined 
database not be a Derived Database?




No, not if the data remained unmodified and independent. If data were 
changed - for instance duplicates deleted, or names or co-ordinates 
changed because one source was considered more accurate than the other - 
then yes, that's a derivative database. But if not, it's a collective 
database. Whether they're in the same instance of postgres or not is 
irrelevant, because software is not a database for the purposes of 
database law (at least in the EU). Only the data itself constitutes a 
database.


By way of analogy: suppose I sent you a private email which included a 
license saying if you publicly use my email, you must share with me any 
other emails you combine it with. My email sits in your inbox together 
with other emails, and you can do searches across all of them. If it's a 
unix system, they're probably all in one single file. But have you 
really "combined" my email with your other private emails? My email is 
sitting there unmodified and completely independent of all your other 
private emails; it is not itself combined with them. So no, "storing 
next to" is not "combining". You can safely share a screenshot of your 
mail program without having to send me all your other private emails.






This was discussed on legal-talk a few months ago, and my
opinion was that it depended on whether you could produce the
same output by merging separately-rendered Produced works. If
you can get _identical_ output by merging layers on the
browser side, then it's okay to the merging on the server
side. However if you can't get identical results by merging
the rendered output, then you've obviously combined the
databases prior to rendering.


Not necessarily. For example, the rendering might depend on what
order data is rendered. But the data being rendered would remain
independent of each other; it may be only the rendered result
which varied. And that's a produced work, not a database.


Can you get the same result by rendering the first dataset (creating a 
Produced Work), rendering the second dataset (creating another 
produced work, if it's ODbL too) and then combining the output? If so, 
they're definitely independent. You can render the second dataset 
first if you like provided you combine them in the right order.


If the rendering of the second output depends on the first dataset, 
the Produced Work created from the second dataset is not independent 
of of the first dataset.


No, the produced work isn't independent of it, but the datasets are 
still independent of each other, that's my point.




I guess it's possible the rendering algorithm for the second dataset 
could use the Produced Work from the first rather than the first 
dataset directly, which may be okay except that it's arguable whether 
you are reverse engineering part of the first database.




Yes, I think that point's arguable - if the combined produced work is 
based on two previous renderings from the two datasets, you might be 
able to argue that those renderings are themselves databases, 
particularly if they use vectors - though it's a very murky area, 
because rendering usually involves throwing away lots of information. 
(For example, suppose two roads meet at a T junction, and I render them 
both in the same line style without names; you can no longer tell their 
IDs, tags, or even how many ways in OSM make up that rendered T shape.)





Hav

Re: [OSM-legal-talk] ODbL and publishing source data

[James Livingston]

On 30 November 2011 01:03, Jonathan Harley  wrote:

> On 28/11/11 23:59, James Livingston wrote:
>
>> Depending on the rendering, it may not be the same. The placements of
>> name text can depend on other data so it's not on top of something else, or
>> POIs can be hidden if there are too many in a given area.
>>
>> In the first case (or combining layers in the browser), the rendering of
>> OSM data cannot depend on the location of your hotels, and the rendering of
>> hotel names can't easily depend on what else is on the map. In the second
>> case (combining data before rendering) collisions can be avoided or the
>> resulting map altered.
>>
>
> Yes, but it's only the produced work, the rendering, which is altered. You
> probably don't need to make changes to the OSM data to acheive this.
>
So the OSM data and other data could remain independent. If they do, then
> the mechanism for combining (and computer/s on which it happens) is indeed
> irrelevant.
>

While that's true, you are combining the two datasource together prior to
rendering.


Say I created some local postgres database tabled and loaded OSM data into
it, and then loaded data from another source into it too. What I have is
now a database derived from both OSM and the other source. If I then
rendered that data to create a Produced Work, would my combined database
not be a Derived Database?



>
>> This was discussed on legal-talk a few months ago, and my opinion was
>> that it depended on whether you could produce the same output by merging
>> separately-rendered Produced works. If you can get _identical_ output by
>> merging layers on the browser side, then it's okay to the merging on the
>> server side. However if you can't get identical results by merging the
>> rendered output, then you've obviously combined the databases prior to
>> rendering.
>>
>
> Not necessarily. For example, the rendering might depend on what order
> data is rendered. But the data being rendered would remain independent of
> each other; it may be only the rendered result which varied. And that's a
> produced work, not a database.
>

Can you get the same result by rendering the first dataset (creating a
Produced Work), rendering the second dataset (creating another produced
work, if it's ODbL too) and then combining the output? If so, they're
definitely independent. You can render the second dataset first if you like
provided you combine them in the right order.

If the rendering of the second output depends on the first dataset, the
Produced Work created from the second dataset is not independent of of the
first dataset.

I guess it's possible the rendering algorithm for the second dataset could
use the Produced Work from the first rather than the first dataset
directly, which may be okay except that it's arguable whether you are
reverse engineering part of the first database.



>
>
>> Having two instances of say Postgres and having one program that reads
>> both and renders is still creating a derived database, even if it is only
>> in the memory of the rendering program.
>>
>>
> It might create a derivative database, or it might not; it would depend on
> the algorithm. If the OSM data remain unmodified, then it could be creating
> a collective database, which is explicitly not a derivative database.
>

I guess that's the a question: if you write a program that reads data from
two sources and uses both to produce it's output, are the temporary
in-memory data structures considered derived or collective for the purposes
of copyright and database right law?

The answer probably depends on how the program is implemented, but given
that we won't know the implementation, how can we ever determine whether
someone's Produced Work requires them to release their database? If we say
we can't determine that, aren't we essentially saying that it's impossible
to enforce that part of the ODbL?

-- 
James
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Martin Koppenhoefer]

2011/11/29 Rob Myers :
> A PNG doesn't fit this description as its intent is to encode a single
> complete image and the pixels are not independent. Likewise PNG and SVG.
> Place them in a systematic or methodical collection and you have a
> database of images. But this is separate from their contents.
>
> If I place a travel photo of mine into a PNG and then print it out, I
> have not gained a database right.


IMHO there is a difference between a travel photo and a map rendering.
This is a jpeg:
http://www.tnooz.com/wp-content/uploads/2011/02/ITA-QR-code-1.jpg

cheers,
Martin

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Rob Myers]

> Eugene Alvin Villar  writes:
>
> The European definition of a database is "a collection of independent
> works, data or other materials arranged in a systematic or methodical
> way and individually accessible by electronic or other means".

Which really, really should be the end of this.

A PNG doesn't fit this description as its intent is to encode a single
complete image and the pixels are not independent. Likewise PNG and SVG.
Place them in a systematic or methodical collection and you have a
database of images. But this is separate from their contents.

If I place a travel photo of mine into a PNG and then print it out, I
have not gained a database right. Likewise if I autotrace it to SVG
before printing it. There is a single work, arbitrarily encoded. No
database right.

- Rob.

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Jonathan Harley]

On 28/11/11 23:59, James Livingston wrote:
On 28 November 2011 21:55, 80n <80n...@gmail.com 
> wrote:


On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm
mailto:frede...@remote.org>> wrote:

I could render a map from OSM and then render something else
on top of it, say a commercially acquired set of hotel POIs.
That would clearly be a Produced Work; I could point anyone
asking for the source data to the planet file and the
rendering rule, and keep the hotel POIs to myself.


This is an overlay on top of a Produced Work.  Whether it's
produced by layers at the browser end or by compositing two
separate images doesn't seem to be materially different.


I agree.

I could also remove all hotels from my OSM copy and add in the
commercial hotels instead, then render a map from it. Unless
the commercial dataset is missing data, the resulting map
could look 100% identical to the map from the first process,
but this time I would be required to release the hotel dataset
because it is part of the derived database used to create the
produced work.


Leaving aside the step about removing content for the moment, I
don't see how this is materially different from the first
example.  You've simply overlaid your hotels on top of the OSM
data.  I don't think the mechanics of how you achieved this are,
from a legal perspective, important.  Any process can be
considered as a series of inputs to a black box and some outputs. 
If the inputs are the same (an OSM database and a set of POIs) and

the output is the same (a map with an overlay of the POIs) then it
shouldn't matter whether it was achieved using a complex machine
or monkeys with typewriters.


Depending on the rendering, it may not be the same. The placements of 
name text can depend on other data so it's not on top of something 
else, or POIs can be hidden if there are too many in a given area.


In the first case (or combining layers in the browser), the rendering 
of OSM data cannot depend on the location of your hotels, and the 
rendering of hotel names can't easily depend on what else is on the 
map. In the second case (combining data before rendering) collisions 
can be avoided or the resulting map altered.




Yes, but it's only the produced work, the rendering, which is altered. 
You probably don't need to make changes to the OSM data to acheive this. 
So the OSM data and other data could remain independent. If they do, 
then the mechanism for combining (and computer/s on which it happens) is 
indeed irrelevant.


Of course if Frederik did remove hotels from the OSM dataset as he 
described above, then that's clearly a derivative database which he 
would have to share.




This was discussed on legal-talk a few months ago, and my opinion was 
that it depended on whether you could produce the same output by 
merging separately-rendered Produced works. If you can get _identical_ 
output by merging layers on the browser side, then it's okay to the 
merging on the server side. However if you can't get identical results 
by merging the rendered output, then you've obviously combined the 
databases prior to rendering.


Not necessarily. For example, the rendering might depend on what order 
data is rendered. But the data being rendered would remain independent 
of each other; it may be only the rendered result which varied. And 
that's a produced work, not a database.




Having two instances of say Postgres and having one program that reads 
both and renders is still creating a derived database, even if it is 
only in the memory of the rendering program.




It might create a derivative database, or it might not; it would depend 
on the algorithm. If the OSM data remain unmodified, then it could be 
creating a collective database, which is explicitly not a derivative 
database.



Jonathan.

--
Jonathan Harley: Managing Director : SpiffyMap Ltd

Email: m...@spiffymap.com   Phone: 0845 313 8457   www.spiffymap.com
Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Eugene Alvin Villar]

On Tue, Nov 29, 2011 at 6:42 PM, Ed Avis  wrote:
>>The European definition of a database is "a collection of independent
>>works, data or other materials arranged in a systematic or methodical
>>way and individually accessible by electronic or other means".
>>
>>Individual pixels comprising a typical image (say a PNG map tile) are
>>not independent works. Each pixel cannot stand on its own and aren't
>>useful unless considered together with its neighboring pixels to form
>>an image.
>
> That makes some sense but you are implicitly taking the individual pixel as
> the level of granularity.  If you took the OSM planet file as your example
> once again, you could state that neither the individual co-ordinate numbers 
> like
> 50.1234, nor individual tag strings like 'highway', have any independent
> existence.  They must stand together with other data items to form a complete
> object such as a node, which even then may not have much meaning without 
> others.

The difference is that for the OSM database, you can construct a
systematic level of granularity where individual objects at that
granularity are individually useful. Certainly, individual tags or
individual pairs of coordinates are not generally useful but a
collection of tagged POIs, ways, and relations are each individually
useful.

Whereas for a *typical* image consisting of a matrix of pixels,
there's no level of granularity that would make individual objects
generally useful, whether those objects are single pixels, or rows of
pixels, or columns of pixels, or tiles of 8x8 pixels. You have to take
the image as a whole to make sense of it.

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Ed Avis]

Eugene Alvin Villar  writes:

>Taking this argument to its logical conclusion, every digital file is
>a database of bytes

Yes, I suggest that legally speaking this is likely to be the case.

Certainly any digital file that is in a documented, structured file format
with certain fields in certain positions has just as strong a claim to being
a 'database' as, say, the OSM planet file.

>The European definition of a database is "a collection of independent
>works, data or other materials arranged in a systematic or methodical
>way and individually accessible by electronic or other means".
>
>Individual pixels comprising a typical image (say a PNG map tile) are
>not independent works. Each pixel cannot stand on its own and aren't
>useful unless considered together with its neighboring pixels to form
>an image.

That makes some sense but you are implicitly taking the individual pixel as
the level of granularity.  If you took the OSM planet file as your example
once again, you could state that neither the individual co-ordinate numbers like
50.1234, nor individual tag strings like 'highway', have any independent
existence.  They must stand together with other data items to form a complete
object such as a node, which even then may not have much meaning without others.

Richard F. noted that "audiovisual works... as such" are not databases.
I imagine it is an open question whether this means photographs and other
pictorial images, and whether it applies to images with a defined schema such
as heatmaps (which can equally well be considered as a database of co-ordinates
mapped to values) or to diagrams and maps with a defined schema and a strict
correspondence between pixel co-ordinates and geographical position.  (I also
note that "as such" is a weasel phrase which European law may wiggle through,
as with the exclusion of computer programs "as such" from patentability.)

In general I think that introducing the concept of "database" into licensing
causes more problems than it solves, and tends to muddle more than it clarifies,
but that's just my opinion.

-- 
Ed Avis 


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[James Livingston]

On 28 November 2011 21:55, 80n <80n...@gmail.com> wrote:

> On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm wrote:
>
>> I could render a map from OSM and then render something else on top of
>> it, say a commercially acquired set of hotel POIs. That would clearly be a
>> Produced Work; I could point anyone asking for the source data to the
>> planet file and the rendering rule, and keep the hotel POIs to myself.
>>
>
> This is an overlay on top of a Produced Work.  Whether it's produced by
> layers at the browser end or by compositing two separate images doesn't
> seem to be materially different.
>

I agree.



>  I could also remove all hotels from my OSM copy and add in the commercial
>> hotels instead, then render a map from it. Unless the commercial dataset is
>> missing data, the resulting map could look 100% identical to the map from
>> the first process, but this time I would be required to release the hotel
>> dataset because it is part of the derived database used to create the
>> produced work.
>>
>
> Leaving aside the step about removing content for the moment, I don't see
> how this is materially different from the first example.  You've simply
> overlaid your hotels on top of the OSM data.  I don't think the mechanics
> of how you achieved this are, from a legal perspective, important.  Any
> process can be considered as a series of inputs to a black box and some
> outputs.  If the inputs are the same (an OSM database and a set of POIs)
> and the output is the same (a map with an overlay of the POIs) then it
> shouldn't matter whether it was achieved using a complex machine or monkeys
> with typewriters.
>

Depending on the rendering, it may not be the same. The placements of name
text can depend on other data so it's not on top of something else, or POIs
can be hidden if there are too many in a given area.

In the first case (or combining layers in the browser), the rendering of
OSM data cannot depend on the location of your hotels, and the rendering of
hotel names can't easily depend on what else is on the map. In the second
case (combining data before rendering) collisions can be avoided or the
resulting map altered.


This was discussed on legal-talk a few months ago, and my opinion was that
it depended on whether you could produce the same output by merging
separately-rendered Produced works. If you can get _identical_ output by
merging layers on the browser side, then it's okay to the merging on the
server side. However if you can't get identical results by merging the
rendered output, then you've obviously combined the databases prior to
rendering.

Having two instances of say Postgres and having one program that reads both
and renders is still creating a derived database, even if it is only in the
memory of the rendering program.



 I am interested in exploring this further with the aim of finding good
>> community norms, nailing down the problem cases, and making the
>> introduction of ODbL for OSM a success.
>>
>
> I'm interested in finding out where the weaknesses in ODbL are and
> ensuring that they are understood.  Version 1 of anything is likely to have
> imperfections and it would be better to find them sooner rather than
> later.  A working version of ODbL is the goal I would aim for.
>

In the discussion a few months ago, not everyone agreed on where the line
is.

-- 
James
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Frederik Ramm]

Hi,

On 11/28/2011 12:55 PM, 80n wrote:

I could render a map from OSM and then render something else on top
of it, say a commercially acquired set of hotel POIs. That would
clearly be a Produced Work; I could point anyone asking for the
source data to the planet file and the rendering rule, and keep the
hotel POIs to myself.


This is an overlay on top of a Produced Work.  Whether it's produced by
layers at the browser end or by compositing two separate images doesn't
seem to be materially different.


I agree that it should not be different, but technically "layers at the 
browser end" is combining two images after disseminating them, and 
"compositing two separate images" happens before disseminating them, so 
any license for which the act of publication triggers something is 
likely to distinguish between the two cases. (It would be interesting to 
find out if there are lawyers who say that publication happens at the 
time when the Javascript in the browser combines several data streams 
into something viewable, rather than when the data leaves our server. If 
that were the case, then several of today's typical uses like overlaying 
transparent non-CC-BY-SA pictures over OSM tiles would cease to work.)



I could also remove all hotels from my OSM copy and add in the
commercial hotels instead, then render a map from it. Unless the
commercial dataset is missing data, the resulting map could look
100% identical to the map from the first process, but this time I
would be required to release the hotel dataset because it is part of
the derived database used to create the produced work.


Leaving aside the step about removing content for the moment, I don't
see how this is materially different from the first example.  You've
simply overlaid your hotels on top of the OSM data.  I don't think the
mechanics of how you achieved this are, from a legal perspective,
important.


I agree that they should not be important but I am pretty sure that they 
are. - Of course, if there are several plausible ways to arrive at the 
same end product then you can always *claim* to have used process A 
rather than B and nobody will be able to prove the opposite.



Any process can be considered as a series of inputs to a
black box and some outputs.  If the inputs are the same (an OSM database
and a set of POIs) and the output is the same (a map with an overlay of
the POIs) then it shouldn't matter whether it was achieved using a
complex machine or monkeys with typewriters.


We don't currently require of users of ODbL-licensed data that they 
demonstrate what processing chain they used to arrive at something 
(though they might do that of their own volition in order not to have to 
release a database). I can imagine, however, certain produced works 
where it is really not plausible if people claim to have created it 
using "monkeys with typewriters" - assume someone makes a map where all 
the roads are coloured according to the number of accidents that happen 
there. If someone were to publish such a map, and upon being asked for 
the source data, were to claim that he was not using a derived database, 
just a regular OSM database where he adds some things ad render time, 
and therefore had nothing to release - I would be skeptical. But I guess 
it is *impossible* to make a map that way (just unnecessarily complex).


I'm not sure what I can do in such a case. I mean even today someone 
could use OSM outright and deny it, in that case my only recourse is in 
the courts; I guess the situation above is similar - if someone claims 
to be using a process that requires them not to release their extra data 
but I believe he has an OSM-derived database where he merged in other 
data, then I might have to sue in order to find out.



Same thing with your reply to my "pencil" example - depending on how
exactly you update your produced work, you might or might not have
to release a database.


If this were to be possible then it would be a very undesirable flaw.
The intent of ODbL was to protect OSMs database and ensure share-alike.
If it can be circumvented then it fails one of its main purposes.


Oh, it does protect OSM's database all right, but drawing lines onto a 
printed-out image is not making a derived database (and frankly I 
wouldn't be all that interested in the geometry of those).


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Eugene Alvin Villar]

On Tue, Nov 29, 2011 at 12:31 AM, 80n <80n...@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 4:17 PM, Eugene Alvin Villar 
> wrote:
>>
>> On Mon, Nov 28, 2011 at 6:00 AM, Ed Avis  wrote:
>> > I see that you and Frederik disagreed here.  (FWIW I think he is right -
>> > a PNG
>> > file can clearly be seen as a database of pixel values.  It is an image
>> > too,
>> > and perhaps even a map or a photograph, but legally it would be hard to
>> > argue
>> > that it *not* a database.)
>>
>> Taking this argument to its logical conclusion, every digital file is
>> a database of bytes and thus everything you create digitally from any
>> ODbL database is a derived database and not a produced work.
>>
>> This seems silly.
>>
>> The European definition of a database is "a collection of independent
>> works, data or other materials arranged in a systematic or methodical
>> way and individually accessible by electronic or other means".
>>
>> Individual pixels comprising a typical image (say a PNG map tile) are
>> not independent works. Each pixel cannot stand on its own and aren't
>> useful unless considered together with its neighboring pixels to form
>> an image.
>>
> Pixels may not be independent works but I think they might be "data or other
> materials", in which case they are covered by that definition.
>
> The nearest thing we've got to a good definition of this is that if you use
> it like a database then it is a database.  Whether the courts would agree
> with that definition remains to be tested, but much discussion here has not
> yet arrived at anything better.

I think the word "independent" also applies to "data" and "other materials".

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[80n]

On Mon, Nov 28, 2011 at 4:17 PM, Eugene Alvin Villar wrote:

> On Mon, Nov 28, 2011 at 6:00 AM, Ed Avis  wrote:
> > I see that you and Frederik disagreed here.  (FWIW I think he is right -
> a PNG
> > file can clearly be seen as a database of pixel values.  It is an image
> too,
> > and perhaps even a map or a photograph, but legally it would be hard to
> argue
> > that it *not* a database.)
>
> Taking this argument to its logical conclusion, every digital file is
> a database of bytes and thus everything you create digitally from any
> ODbL database is a derived database and not a produced work.
>
> This seems silly.
>
> The European definition of a database is "a collection of independent
> works, data or other materials arranged in a systematic or methodical
> way and individually accessible by electronic or other means".
>
> Individual pixels comprising a typical image (say a PNG map tile) are
> not independent works. Each pixel cannot stand on its own and aren't
> useful unless considered together with its neighboring pixels to form
> an image.
>
> Pixels may not be independent works but I think they might be "data or
other materials", in which case they are covered by that definition.

The nearest thing we've got to a good definition of this is that if you use
it like a database then it is a database.  Whether the courts would agree
with that definition remains to be tested, but much discussion here has not
yet arrived at anything better.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Eugene Alvin Villar]

On Mon, Nov 28, 2011 at 6:00 AM, Ed Avis  wrote:
> I see that you and Frederik disagreed here.  (FWIW I think he is right - a PNG
> file can clearly be seen as a database of pixel values.  It is an image too,
> and perhaps even a map or a photograph, but legally it would be hard to argue
> that it *not* a database.)

Taking this argument to its logical conclusion, every digital file is
a database of bytes and thus everything you create digitally from any
ODbL database is a derived database and not a produced work.

This seems silly.

The European definition of a database is "a collection of independent
works, data or other materials arranged in a systematic or methodical
way and individually accessible by electronic or other means".

Individual pixels comprising a typical image (say a PNG map tile) are
not independent works. Each pixel cannot stand on its own and aren't
useful unless considered together with its neighboring pixels to form
an image.

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Jonathan Harley]

On 28/11/11 11:55, 80n wrote:
On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm > wrote:


Yes, I agree it is difficult. I think that it is entirely possible
to arrive at an identical end product through different processes,
where one process has different license implications than the other.

For example:

I could render a map from OSM and then render something else on
top of it, say a commercially acquired set of hotel POIs. That
would clearly be a Produced Work; I could point anyone asking for
the source data to the planet file and the rendering rule, and
keep the hotel POIs to myself.


This is an overlay on top of a Produced Work.  Whether it's produced 
by layers at the browser end or by compositing two separate images 
doesn't seem to be materially different.




I agree. Either it's separate data or it's not. Another example is by 
compositing two separate sources of data in a database, which is catered 
for in ODbL as a Collective Database. Frederik appears to believe that 
if you put your commercial dataset in the same database as some OSM 
data, then your commercial data becomes a derivative database and must 
be released for free. I disagree. If you used your commercial data to 
modify data that's already in OSM, such as correcting the names and 
locations of hotels and their access roads, then *that* would clearly be 
a derivative.




Same thing with your reply to my "pencil" example - depending on
how exactly you update your produced work, you might or might not
have to release a database.


If this were to be possible then it would be a very undesirable flaw.  
The intent of ODbL was to protect OSMs database and ensure 
share-alike.  If it can be circumvented then it fails one of its main 
purposes.




I'd say it's not so much a flaw, as a limitation of the approach; you 
can't govern non-database work such as artwork on top of a map with a 
database license.


I think ODbL protects share-alike just fine, to the extent that it's 
feasible to do so. The intent of ODbL was never to inhibit the use of 
OSM data in commercial environments by saying it can't be used in 
conjunction with any dataset which you can't make available for free. 
The intent, as you say, is to protect OSM (by attribution) and to make 
sure that any useful modification of OSM's own data is shared back, and 
I think it achieves this.



Jonathan.
(IANAL but I have consulted one about ODbL.)

--
Jonathan Harley: Managing Director : SpiffyMap Ltd

Email: m...@spiffymap.com   Phone: 0845 313 8457   www.spiffymap.com
Post: The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[80n]

On Mon, Nov 28, 2011 at 11:25 AM, Frederik Ramm  wrote:

> Hi,
>
>
> On 11/28/11 11:58, 80n wrote:
>
>> That's a very fine line you are trying to draw.
>>
>
> Yes, I agree it is difficult. I think that it is entirely possible to
> arrive at an identical end product through different processes, where one
> process has different license implications than the other.
>
> For example:
>
> I could render a map from OSM and then render something else on top of it,
> say a commercially acquired set of hotel POIs. That would clearly be a
> Produced Work; I could point anyone asking for the source data to the
> planet file and the rendering rule, and keep the hotel POIs to myself.
>

This is an overlay on top of a Produced Work.  Whether it's produced by
layers at the browser end or by compositing two separate images doesn't
seem to be materially different.


> I could also remove all hotels from my OSM copy and add in the commercial
> hotels instead, then render a map from it. Unless the commercial dataset is
> missing data, the resulting map could look 100% identical to the map from
> the first process, but this time I would be required to release the hotel
> dataset because it is part of the derived database used to create the
> produced work.
>

Leaving aside the step about removing content for the moment, I don't see
how this is materially different from the first example.  You've simply
overlaid your hotels on top of the OSM data.  I don't think the mechanics
of how you achieved this are, from a legal perspective, important.  Any
process can be considered as a series of inputs to a black box and some
outputs.  If the inputs are the same (an OSM database and a set of POIs)
and the output is the same (a map with an overlay of the POIs) then it
shouldn't matter whether it was achieved using a complex machine or monkeys
with typewriters.


> Same thing with your reply to my "pencil" example - depending on how
> exactly you update your produced work, you might or might not have to
> release a database.
>

If this were to be possible then it would be a very undesirable flaw.  The
intent of ODbL was to protect OSMs database and ensure share-alike.  If it
can be circumvented then it fails one of its main purposes.


>
> I am interested in exploring this further with the aim of finding good
> community norms, nailing down the problem cases, and making the
> introduction of ODbL for OSM a success.
>

I'm interested in finding out where the weaknesses in ODbL are and ensuring
that they are understood.  Version 1 of anything is likely to have
imperfections and it would be better to find them sooner rather than
later.  A working version of ODbL is the goal I would aim for.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Frederik Ramm]

Hi,

On 11/28/11 11:58, 80n wrote:

That's a very fine line you are trying to draw.


Yes, I agree it is difficult. I think that it is entirely possible to 
arrive at an identical end product through different processes, where 
one process has different license implications than the other.


For example:

I could render a map from OSM and then render something else on top of 
it, say a commercially acquired set of hotel POIs. That would clearly be 
a Produced Work; I could point anyone asking for the source data to the 
planet file and the rendering rule, and keep the hotel POIs to myself.


I could also remove all hotels from my OSM copy and add in the 
commercial hotels instead, then render a map from it. Unless the 
commercial dataset is missing data, the resulting map could look 100% 
identical to the map from the first process, but this time I would be 
required to release the hotel dataset because it is part of the derived 
database used to create the produced work.


Same thing with your reply to my "pencil" example - depending on how 
exactly you update your produced work, you might or might not have to 
release a database.


I am interested in exploring this further with the aim of finding good 
community norms, nailing down the problem cases, and making the 
introduction of ODbL for OSM a success.


I will happily continue a constructive discussion if you share these goals.

Bye
Frederik

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[80n]

On Mon, Nov 28, 2011 at 9:53 AM, Frederik Ramm  wrote:

> Hi,
>
>
> On 11/28/11 10:43, 80n wrote:
>
>> If you cannot reproduce the Produced Work 100% faithfully from the
>> Derived Database in what sense does the Derived Database contain all of
>> the information required to create the Produced Work?
>>
>
> It doesn't, and it doesn't have to. Only in so far as the *database* has
> been augmented to make the produced work does such information have to be
> released. Any other, non-database input (what you seem to call "worthless
> prettyfing" - I guess that members of the trade might disagree!) that
> becomes part of the Produced Work is not affected by the ODbL.
>
> If new information is added at the non-database stage - let's say someone
> prints out a map, paints something over it making the whole thing a work of
> art, then notices a missing road and pencils it in - then that is not the
> making of a derived database and does not have to be shared. If the same
> guy, however, goes back the the data, adds the road, and makes a new
> rendering from it, then it is.
>
>
That's a very fine line you are trying to draw.

What you are saying is that I can create a map, publish it as a produced
work and then update that map as much as I like with impunity.  Technically
I can do that using a pencil as you suggest, or I can do the same thing by
processing the produced work into a digital form and applying "pencil
marks" using an automated process.  But if you allow the latter then you
effectively allow reverse engineering of the produced work.

 Why should a lead pencil be considered ok, but an electronic pencil not be
permitted?

80n
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Frederik Ramm]

Hi,

On 11/28/11 10:43, 80n wrote:

If you cannot reproduce the Produced Work 100% faithfully from the
Derived Database in what sense does the Derived Database contain all of
the information required to create the Produced Work?


It doesn't, and it doesn't have to. Only in so far as the *database* has 
been augmented to make the produced work does such information have to 
be released. Any other, non-database input (what you seem to call 
"worthless prettyfing" - I guess that members of the trade might 
disagree!) that becomes part of the Produced Work is not affected by the 
ODbL.


If new information is added at the non-database stage - let's say 
someone prints out a map, paints something over it making the whole 
thing a work of art, then notices a missing road and pencils it in - 
then that is not the making of a derived database and does not have to 
be shared. If the same guy, however, goes back the the data, adds the 
road, and makes a new rendering from it, then it is.


Bye
Frederik


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Richard Fairhurst]

Frederik Ramm wrote:
> I think that anything said until here will not be disputed by Richard

Indeed not. :)

> the bit that *can* be disputed is whether or not it is permissible 
> to label your resulting image a database and then not release 
> the database behind it.

Yep. I read the EU Database Directive as expressly saying images are not
databases: "an audiovisual, cinematographic, literary or musical work as
such does not fall within the scope of this Directive". But as ever, IANAL.

> That, however, would have the consequence that you have to 
> share the image itself, which would not be the case under the 
> "Produced Works" provision.

Yes.

cheers
Richard



--
View this message in context: 
http://gis.638310.n2.nabble.com/OSM-legal-talk-Copyprotection-for-OSM-based-materil-tp7030609p7038146.html
Sent from the Legal Talk mailing list archive at Nabble.com.

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[80n]

On Sun, Nov 27, 2011 at 11:54 PM, Frederik Ramm  wrote:

>
>
> Whatever you publish could have other ingredients than just data; perhaps,
> a few hundred hours' worth of a cartographer's editing in Illustrator.
> *That* you don't have to release; it is yours to keep.


That can't be right.  If I take a produced work and spend a few hundred
hours adding hundreds of facts to it then it doesn't count as a derived
databse?  How do you judge whether a cartographer's efforts are just
worthless prettifying or the introduction of new information?

If you cannot reproduce the Produced Work 100% faithfully from the Derived
Database in what sense does the Derived Database contain all of the
information required to create the Produced Work?

80n
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Frederik Ramm]

Hi,

On 11/27/2011 11:00 PM, Ed Avis wrote:

I believe I was thinking of this thread:

I see that you and Frederik disagreed here.


[...]


The "access to source data" clause in ODbL expressly applies to both
Derivative Databases and Produced Works. 4.6: "If You Publicly Use a
Derivative Database or a Produced Work from a Derivative Database, You must
also offer to recipients of the Derivative Database or Produced Work a copy
in a machine readable form of (etc.)"


Right, so I guess what Kai Kruger wrote "you only have to share the last in a
chain of derived databases that leads to a produced work, right?" is not so?


1. That's my quote, not Kai's.

2. I still believe it to be correct.

3. I don't think it is a contradiction to what Richard said above.

Maybe is introductory "the 'access to source data' clause applies to 
both..." is a bit misleading but careful reading of the quote 
immediately following that should make it clear:


If you public use a Produced Work, you have to offer the Derivative 
Database used to create it.


If you publicly use a Derivative Database, you have to offer the 
Derivative Database itself. You are not required to release the database 
from which the derivate was made; although you *could* do that along 
with a production rule to satisfy the requirement.


The idea behind this is that if you publish anything based on ODbL 
licensed data, the recipient of that "anything" should have available to 
him the database required to re-produce that.


Whatever you publish could have other ingredients than just data; 
perhaps, a few hundred hours' worth of a cartographer's editing in 
Illustrator. *That* you don't have to release; it is yours to keep. But 
someone else must have the option to get the source database from you 
(er be told by you how to obtain it) and then invest his own few hundred 
cartographer hours.


So yes, you could take an OSM database for London, and pipe it through a 
series of complex database processing steps until for example all that 
remains is, for each point in a 10x10 meter grid, the number of meters 
you have to walk until you reach a street with "a" in its name.


Then you make a nice picture from that - London coloured according to 
distance to nearest street with "a" - and release it. Your obligation to 
share and release now only affects your grid database and not any of the 
intermediate steps, and not the original OSM data either.  (For the 
purpose of this argument let's assume that the base map drawn in your 
final picture was a public domain map that doesn't affect the license 
situation.)


I think that anything said until here will not be disputed by Richard; 
the bit that *can* be disputed is whether or not it is permissible to 
label your resulting image a database and then not release the database 
behind it. That, however, would have the consequence that you have to 
share the image itself, which would not be the case under the "Produced 
Works" provision.


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[80n]

On Sun, Nov 27, 2011 at 10:00 PM, Ed Avis  wrote:

> Right, so I guess what Kai Kruger wrote "you only have to share the last
> in a
> chain of derived databases that leads to a produced work, right?" is not
> so?
>
>
As far as I can see there is no requirement to "show your workings" as long
as you make the Derived Database available under ODbL.

Suppose you transform the OSM database, adding in some non-OSM-content
along the way and produce a table containing three columns: x, y and
colour, where x and y are pixel coordinates for an image and the colour
column specifies the colour value for the pixel.

The result is that you can publish a table and an image that contain
identical information.  The table has to be licensed as ODbL and the image,
being a Produced Work, can be published under any license whatsoever.

So far so good.

Assuming the Produced Work was not published under a friendly license it
can't be used so we can forget about that.

The Derived Database can, however, be transformed into the same (or a
similar) image which can be reincorporated.  How?  By making your own
Produced Work you can license it under an OSM friendly license[1].  You
would, of course, need to hand trace from it to recover the non-OSM-content
but that's easy to do and there's a large army of OSMers who are very
skilled at this task, so that's not a problem.

For any Derived Database it will always be possible to recover the content
by making a liberally licensed Produced Work from it and tracing.

80n

[1] You have to do this step because any unfriendly publisher would block
the use of the ODbL content directly by simply refusing to agree to the
Contributor Terms.
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Ed Avis]

[About requirement to publish source data]

>>I thought that previous discussions on this list had come to the
>>conclusion that you could publish your end product as a derived work
>>under ODbL, too, so it would not be a Produced Work and it would not be
>>necessary to publish the source data.

I believe I was thinking of this thread:



I see that you and Frederik disagreed here.  (FWIW I think he is right - a PNG
file can clearly be seen as a database of pixel values.  It is an image too,
and perhaps even a map or a photograph, but legally it would be hard to argue
that it *not* a database.)

Richard F. wrote:

>The "access to source data" clause in ODbL expressly applies to both
>Derivative Databases and Produced Works. 4.6: "If You Publicly Use a
>Derivative Database or a Produced Work from a Derivative Database, You must
>also offer to recipients of the Derivative Database or Produced Work a copy
>in a machine readable form of (etc.)"

Right, so I guess what Kai Kruger wrote "you only have to share the last in a
chain of derived databases that leads to a produced work, right?" is not so?

-- 
Ed Avis 


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] ODbL and publishing source data

[Richard Fairhurst]

Ed Avis wrote:
> I thought that previous discussions on this list had come to the
> conclusion 
> that you could publish your end product as a derived work under ODbL, too,
> so it would not be a Produced Work and it would not be necessary to 
> publish the source data.

¿Que?

The "access to source data" clause in ODbL expressly applies to both
Derivative Databases and Produced Works. 4.6: "If You Publicly Use a
Derivative Database or a Produced Work from a Derivative Database, You must
also offer to recipients of the Derivative Database or Produced Work a copy
in a machine readable form of (etc.)"

cheers
Richard



--
View this message in context: 
http://gis.638310.n2.nabble.com/OSM-legal-talk-Copyprotection-for-OSM-based-materil-tp7030609p7034970.html
Sent from the Legal Talk mailing list archive at Nabble.com.

___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk

[OSM-legal-talk] ODbL and publishing source data

[Ed Avis]

Richard Fairhurst  writes:

>3. CC-BY-SA indeed does not require that you publish the useful source data.
>(ODbL does.)

I thought that previous discussions on this list had come to the conclusion that
you could publish your end product as a derived work under ODbL, too, so it 
would
not be a Produced Work and it would not be necessary to publish the source data.
It would be good to get a definitive answer.

-- 
Ed Avis 


___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk