JPL Planetary Ephemeris DE405

Post by Hibby
What I'm here to clarify is that I can't see a license for the ascii
files - I'm not sure if this fileset is something that anyone in
debian-legal have come across, or have any advice on what license they
may have been released under? I can't see anything on the JPL FTP server
outside of the CD Notes from the original release [5]. The contact
detailed on them worked at JPL 21 years ago, and I don't reckon the
email address is still active.

There is contact information at the bottom of

https://ssd.jpl.nasa.gov/?planet_eph_export

It references William Folkner. He published a paper in 2014, so he may
still be around.

Cheer,
Walter Landry

Dave Hibberd

2018-02-27 10:04:41 UTC

Walter,

Thanks for the response - I got in touch with Mr Folkner, and I received the following response:

"We consider the ascii and binary ephemeris files the same SPICE kernels that have exactly the same information just in a different format. The ephemeris data are then released for public use under the following conditions;

https://naif.jpl.nasa.gov/naif/rules.html

See especially sections on Kernels Distribution and Kernels Redistribution. The intent is to allow anyone to use or redistribute as long as the files/kernels are not modified."

Under my reading of their terms, it feels like a free license we can distribute the files under - they permit use, redistribution and modification as the user sees fit, and are only looking to limit their liability for support of any modified code.

Can anyone confirm or suggest why I may be wrong in this interpretation?

Thanks in advance!
DH
--
Hibby

Post by Walter Landry

There is contact information at the bottom of
https://ssd.jpl.nasa.gov/?planet_eph_export
It references William Folkner. He published a paper in 2014, so he may
still be around.
Cheer,
Walter Landry

Walter Landry

2018-02-27 17:56:39 UTC

Hi Dave,

The FTP masters are the final judge, but it looks fine to me. It is
basically free distribution with a requirement to change attributions if
modified.

Cheers,
Walter Landry

Post by Dave Hibberd
Walter,
"We consider the ascii and binary ephemeris files the same SPICE
kernels that have exactly the same information just in a different
format. The ephemeris data are then released for public use under the
following conditions;
https://naif.jpl.nasa.gov/naif/rules.html
See especially sections on Kernels Distribution and Kernels
Redistribution. The intent is to allow anyone to use or redistribute
as long as the files/kernels are not modified."
Under my reading of their terms, it feels like a free license we can
distribute the files under - they permit use, redistribution and
modification as the user sees fit, and are only looking to limit their
liability for support of any modified code.
Can anyone confirm or suggest why I may be wrong in this interpretation?
Thanks in advance!
DH
--
Hibby

Post by Walter Landry

There is contact information at the bottom of
https://ssd.jpl.nasa.gov/?planet_eph_export
It references William Folkner. He published a paper in 2014, so he may
still be around.
Cheer,
Walter Landry

Ben Finney

2018-02-27 21:54:09 UTC

Post by Dave Hibberd
[…]
See especially sections on Kernels Distribution and Kernels
Redistribution. The intent is to allow anyone to use or redistribute
as long as the files/kernels are not modified."

That intent explicitly does not permit distribution of modified works.
That permission is needed if the work is to be free software.

Post by Dave Hibberd
Under my reading of their terms, it feels like a free license we can
distribute the files under - they permit use, redistribution and
modification as the user sees fit, and are only looking to limit their
liability for support of any modified code.

I think it is non-free, for the reason above.

If the license conditions also do not permit redistribution of modified
works, the work is not DFSG-free. It cannot be in Debian.

If the license conditions, instead, do permit redistribution of modified
works, the license conditions are contrary to the stated intention,
above. We should consider carefully whether to honour the intent or the
license.

That conflict needs to be resolved, IMO. Do they intend to grant all the
DFSG freedoms to the work's recipient, or not?

Post by Dave Hibberd
Can anyone confirm or suggest why I may be wrong in this
interpretation?

Thank you for continuing to seek an unambiguous grant of free license in
this work.

--
\ “Nothing worth saying is inoffensive to everyone. Nothing worth |
`\ saying will fail to make you enemies. And nothing worth saying |
_o__) will not produce a confrontation.” —Johann Hari, 2011 |
Ben Finney

jonathon

2018-02-27 22:22:48 UTC

Post by Ben Finney
That conflict needs to be resolved, IMO. Do they intend to grant all the
DFSG freedoms to the work's recipient, or not?

My recommendation is to go back to NASA, asking if this will be
relicenced under NOSO 2.0, if/when OSI states that that license is OSI
compliant.

It has been at least four years, and maybe even five, since NASA
submitted that license. I doubt anybody expected approval to take so
long, especially since NASA appears to not know what the issues
triggering the denial are.

When that license was first submitted, my impression was that NASA,
along with sub-contractors, and organisations they work with, were going
to do a wholesale license migration, from the hodgepodge they currently
utilise, to NOSO 2.0, unless otherwise prohibited by law, from so doing.

jonathon

Francesco Poli

2018-02-27 22:39:31 UTC

Post by Ben Finney
That conflict needs to be resolved, IMO. Do they intend to grant all the
DFSG freedoms to the work's recipient, or not?

My recommendation is to go back to NASA, asking if this will be
relicenced under NOSO 2.0

Where can I find the text of the NOSA v2.0 ?

--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE

jonathon

2018-02-27 23:52:09 UTC

Post by Francesco Poli
Where can I find the text of the NOSA v2.0 ?

I was going to suggest
https://web.archive.org/web/20150923151504/https://lists.opensource.org/pipermail/license-review/2013-June/000610.html

but the attachment containing the text was scrubbed.

NASA Open Source Agreement 2.0

I can find copies of NOSA 1.3. (In theory NOSA 1.3 is neither Free (FSF)
nor Open (OSI), but the latter, for some bizarre reason, lists it as open.)

jonathon

Dmitry Alexandrov

2018-02-28 11:42:16 UTC

Post by Francesco Poli
Where can I find the text of the NOSA v2.0 ?

I was going to suggest
https://web.archive.org/web/20150923151504/https://lists.opensource.org/pipermail/license-review/2013-June/000610.html
but the attachment containing the text was scrubbed.

Here it is:

Ole Streicher

2018-02-28 12:17:13 UTC

Post by Francesco Poli
Where can I find the text of the NOSA v2.0 ?

I was going to suggest
https://web.archive.org/web/20150923151504/https://lists.opensource.org/pipermail/license-review/2013-June/000610.html
but the attachment containing the text was scrubbed.

NASA OPEN SOURCE AGREEMENT VERSION 2.0
This open source agreement (“Agreement”) defines the rights of use,
reproduction, modification and redistribution of certain software
released by the United States Government (“Government”) as represented
by the Government Agency listed below (“Government Agency”).

Again, as shown here: this license covers *software*, not *data*.

Data is fundamentally different from software: for example, there is no
"source code" for DE405. There is just no "preferred way to edit" for
such a database -- these database are created from observation and not
thought to be edited by hand.

So, it is just wrong to apply software licenses to databases like DE405.

Best

Ole

Ben Finney

2018-02-28 23:28:33 UTC

Post by Ole Streicher
Again, as shown here: this license covers *software*, not *data*.

That's not a distinction that matters for the question at hand. Any
work, regardless of how you might categorise it, if it is to be in
Debian must conform to the DFSG.

Post by Ole Streicher
Data is fundamentally different from software

Whatever those differences may be, they don't change the required
freedoms to the recipient, for the work to be in Debian.

Post by Ole Streicher
for example, there is no "source code" for DE405. There is just no
"preferred way to edit" for such a database -- these database are
created from observation and not thought to be edited by hand.

The freedoms that the recipients are to be granted, to satisfy the DFSG,
are not limited by what the original distributors imagine.

It does not matter what categories you say the work is in or not in. It
does not matter whether the original distributor can or cannot imagine
why they might want to do that.

If a recipient of Debian gets it into their head, for any reason or no
reason, to modify and re-distribute the work, the Debian Social Contract
promises that they are permitted to do that; so the work's copyright
license must permit that.

Post by Ole Streicher
So, it is just wrong to apply software licenses to databases like DE405.

That's contrary to the position of the FTP masters, and contrary to the
Debian Social Contract §1.

--
\ “I never forget a face, but in your case I'll be glad to make |
`\ an exception.” —Groucho Marx |
_o__) |
Ben Finney

Ole Streicher

2018-03-01 10:29:03 UTC

The freedoms that the recipients are to be granted, to satisfy the DFSG,
are not limited by what the original distributors imagine.

For (scientific) data, they can't: DFSG requires "source code". To take
its definition in the Linux Information Project (just my laziness; taken
from Wikipedia):

| Source code (...) is the version of software as it is originally
| written (i.e., typed into a computer) by a human in plain text (i.e.,
| human readable alphanumeric characters).

Not let's take the detailed measurement data of the earth rotation in
JPL405. Does it meet these criteria? Is it written originially written
by a human?

Clearly not. It is generated.

Is it the preferred form of the work for making modifications (GPL def)?

Clearly not. The preferred form would be to repeat the observations.

So, what could be the "source code"? The data were compiled from a huge
number of observations from many scientific fields (radio astronomy and
satellited observations to name two of them), each of them connected
with a complex analysis. Is the raw data input in each of these
observations the "source code"? Obviously also not. "Raw input" for
radio astronomy may f.e. mean the realtime data stream from the antenna
before applying a filter. Even if you had this and would count this as
input; it would require to repeat the complete analysis chain within
Debian -- something that cannot work at all: we don't have enough
manpower to gather and repeat all those analysis steps ourself, and we
don't have enough machine power. And still then you come to the point
where you can't change the data because you can't repeat a transient
observation.

So: science data has no source code.

Therefore, if we want to have scientific data in Debian, we have to be
"creative" here, and think of a good, pragmatic analogon to "source
code". To formulate it as a test: Imagine that a scientist found a
better way to determine the data. Is he legally and factically able to
replace the data with his own? This would keep us free from a f.e. JPL
lock-in: even when JPL is closed in some future (or does not want to
provide those data anymore), someone else may step in and (with the
required effort) take over.

This would require two things (instead of DFSG §2: Inclusion of source code)

1. it must be legal to replace those data

2. the data must have a form that allows a scientist to replace them
- properly documented
- in a format that is writable for the scientist (with Free Software)

It is, however, not required that the format is ASCII. F.e. an SQLite
database or an (astronomy) FITS file would be fine as well.

Such a rule is harder for the ftp-masters, since they finally need to
trust some expert of whether the data is "properly documented", but I
see no other way to have scientific data in Debian.

We could ofcourse even question if we want to. But if we decide to
generally not include scientific data, we will loose not only a large
number of science applications (and games etc. based on scientific
observations). Also the use of scientific data in "ordinary" software is
strongly increasing.

Post by Ben Finney
If a recipient of Debian gets it into their head, for any reason or no
reason, to modify and re-distribute the work, the Debian Social Contract
promises that they are permitted to do that; so the work's copyright
license must permit that.

Copyright is possible only for creative works.

Science itself is for sure a creative process; however the creative
outcome of science are the papers, and they are copyright protected.

The possibilities to copyright (scientific) data is very limited: data
as such are not copyrightable at all (or who has the copyright on the
electron mass?). Collections of data ("databases") are copyright
protectable in the EU only when their selection or arrangement is
"creative", which excludes scientific databases: their selection and
arrangement there is done by formal criteria, not by creativity. For the
US I don't know; it seems however that there is no database protection
at all.

With no copyright protection, there are no copyright licenses,
independently of what the distributor of a database says.

Post by Ole Streicher
So, it is just wrong to apply software licenses to databases like DE405.

That's contrary to the position of the FTP masters, and contrary to the
Debian Social Contract §1.

It would be great if the ftp-masters could contribute their view to this
discussion. I also don't see why this is contrary to "free redistribution".
Please explain.

Best regards

Ole

Francesco Poli

2018-03-01 18:19:54 UTC

The freedoms that the recipients are to be granted, to satisfy the DFSG,
are not limited by what the original distributors imagine.

I respectfully disagree.

Post by Ole Streicher
DFSG requires "source code".

This is true, but...

Post by Ole Streicher
To take
its definition in the Linux Information Project (just my laziness; taken
| Source code (...) is the version of software as it is originally
| written (i.e., typed into a computer) by a human in plain text (i.e.,
| human readable alphanumeric characters).

This is not a good definition of source code.
I wrote an
[essay](https://www.inventati.org/frx/essays/softfrdm/whatissource.html)
on this topic.

[...]

Post by Ole Streicher
Is it the preferred form of the work for making modifications (GPL def)?
Clearly not. The preferred form would be to repeat the observations.

I don't agree: repeating the observations is the preferred *method*
(not *form of the work*) for *re-creating* the work from scratch.
On the other hand, *making modifications* to the work requires some
form of the work itself.
You have to imagine the desire to alter the data (even in ways that
make the data no longer be an accurate scientific representation of a
phenomenon) and ask yourself: which is the best form I would start
from, in order to make modifications?

I think this is much like digital photographs.
A digital photograph represents a scene with objects and/or living
beings.
But you can modify it to create an image that no longer represents a
real scene (think about special effects in movies).
See the last FAQ in my above-mentioned essay...

Ole Streicher

2018-03-01 19:36:48 UTC

Post by Francesco Poli
I wrote an
[essay](https://www.inventati.org/frx/essays/softfrdm/whatissource.html)
on this topic.
[...]

Post by Ole Streicher
Is it the preferred form of the work for making modifications (GPL def)?
Clearly not. The preferred form would be to repeat the observations.

You are right here.

Post by Francesco Poli
You have to imagine the desire to alter the data (even in ways that
make the data no longer be an accurate scientific representation of a
phenomenon) and ask yourself: which is the best form I would start
from, in order to make modifications?

Sure. And this is not so simple as for source code: It heavily depends
on your goal, and on the data.

Post by Francesco Poli
I think this is much like digital photographs.
A digital photograph represents a scene with objects and/or living
beings.
But you can modify it to create an image that no longer represents a
real scene (think about special effects in movies).
See the last FAQ in my above-mentioned essay...

Citing from there:
| Depending on which format is extracted from the digital camera and on
| which form one starts with when making modifications, the source may
| be in raw format, JPEG, or some other form...

This would be what I call "raw data", so the original measurements,
which were used for the several analysis steps that finally lead to the
ephemeris.

Some use cases where one would like to change the ephemeris:

- I have an improvement in one of the processing steps, and I want to
make use of it

- I have additional data that I want to merge in an early step of the
processing chain

I can't do this, since I don't have the software available that produced
the final data (even when the method is described in a paper). And I
also don't have the raw data available.

The idea that one could legally "just change some numbers" is not
realistic at all: the numbers in the ephemeris data depend on each
other, and changing them by hand will just make the data
inconsistent. Having only this right gives only a formal freedom, but no
real advantage, since you need more information about the inner
structure of the data.

Or to use another part of your essay:

| [...] preferred by whom?
| The person whose preference should be taken into account is the one
| who last modified the version of the work under consideration. If
| he/she prefers to modify the work in a given form, then that form is
| the source code for the work.

If we take JPL, they will probably not just modify the data. They will
regenerate them with modified input. This is at least the case for the
astrophysics databases I am connected with: they don't ever "modify" the
published data, they create a new release with improved analysis: The
Gaia mission provided a data release 1 in 2016 and will publish a new
data release 2 in a month or so, with better accuracy, more stars, and
more data for each star. The (preferred) "modification" is not done in
the final data, but in the data processing chain.

Would you really consider these data releases as "source"?

Best regards

Ole

Francesco Poli

2018-03-17 14:04:59 UTC

[...]

| Depending on which format is extracted from the digital camera and on
| which form one starts with when making modifications, the source may
| be in raw format, JPEG, or some other form...
This would be what I call "raw data", so the original measurements,
which were used for the several analysis steps that finally lead to the
ephemeris.
- I have an improvement in one of the processing steps, and I want to
make use of it
- I have additional data that I want to merge in an early step of the
processing chain
I can't do this, since I don't have the software available that produced
the final data (even when the method is described in a paper). And I
also don't have the raw data available.

If a significant set of possible and reasonable modifications
preferably require these "raw data" and the "processing tools", then...
it really seems that these "raw data" are the source and the
"processing tools" are the build chain.
If one of them (or both) are not available in Debian main (under
DFSG-free terms), then I think the "final data" cannot be in Debian
main, either...

Post by Ole Streicher
The idea that one could legally "just change some numbers" is not
realistic at all: the numbers in the ephemeris data depend on each
other, and changing them by hand will just make the data
inconsistent.

[...]

In order to enjoy full freedom, you should also have the legal
permission to mess with the data and produce an inconsistent result.
Free software is not (only) about reasonable modifications.
Unreasonable ones should also be allowed.

Ole Streicher

2018-03-17 17:54:43 UTC

Post by Francesco Poli
If a significant set of possible and reasonable modifications
preferably require these "raw data" and the "processing tools", then...
it really seems that these "raw data" are the source and the
"processing tools" are the build chain.

Possible modifications are better input data or modifications in the
processing tools; sure.

Post by Francesco Poli
If one of them (or both) are not available in Debian main (under
DFSG-free terms), then I think the "final data" cannot be in Debian
main, either...

This would however prevent us from having almost *any* scientific data
in Debian: Even a simple value as the charge of an electron is based on
some raw data and some processing, which is usually not delivered when
a program provides this number.

And the processing tools themself again contain some "final data", which
again would require (to have them free in your terms) to deliver their
raw data, and their processing chain. Which again will have the same
problem.

This finally would mean that you need (almost) the whole scientific
(physics) history and discussion as an automated processing chain in
Debian.

This is not realistic, and it completely ignores the culture in science:
It is simply impossible to (recursively) repeat any single step to get a
certain result, be it JPL tables or the electron charge. Instead, the
steps must be documented and transparent. The latter is ensured by
peer-reviewed articles (peer review forms a Web of Trust), not by
software. And articles are usually not DFSG free (athough the described
algorithms are), and often not even available electronically.

IMO this difference in culture and history should be reflected by taking
science data differently from software. Effectively, this is already the
case: I had not seen a case that a package was rejected because the raw
data for scientific data (or the processing chain to produce the data)
were missing.

Post by Francesco Poli

[...]
In order to enjoy full freedom, you should also have the legal
permission to mess with the data and produce an inconsistent result.
Free software is not (only) about reasonable modifications.
Unreasonable ones should also be allowed.

For data, it is questionable to think of "change"; one rather replaces
them: Imagine again the electron charge. What would it mean that oneone
publishes an value for it (f.e. extraordinary exact) and then requires
"not to change" it? When I use a value that is different in the 13th
digit, it is just a new value, not a change. When I provide an JPL
compatible table that has one number different, it is not a changed
table but a new one. So what exactly is meant with "modification"?

The other point here is: the legal permission to replace those data is
trivially, but *not enough*. To ensure freedom, one should have
additionally enough documentation to replace them in a useful
manner. This includes a description of the data fields, but also the
algorithms used to create them.

As a rule of thumb: Data that are accompanied by a peer reviewed article
can be assumed to be transparent. Data that have no further
documentation may be suspect. d/u/metadata has a "Reference:" field,
which could be used here. But at the end, there is some trust needed to
the maintainer, since the ftp-master has usually not the required
knowledge to estimate this.

A reference for JPL would f.e. be Folkner et al., Astronomy and
Astrophysics v. 287, pp. 279-289, 1994.

Best regards

Ole

Francesco Poli

2018-03-18 23:19:01 UTC

[...]

Post by Francesco Poli
If one of them (or both) are not available in Debian main (under
DFSG-free terms), then I think the "final data" cannot be in Debian
main, either...

If this is what you meant, then I must have misread your reasoning.
I apologize.

I think that a work that includes data (such as the electric charge of
an electron) *can* be in source form, without the need to ship all the
raw measurements that brought us to the determination of good values for
these data, or to build-depend on the whole analysis process that
brought us to that same determination.

What's good about the definition of source is that it is flexible
enough to cope with many corner cases.
In the "scientific data" case, changing the raw measurements and/or the
analysis process is probably more like taking a new digital photograph
(perhaps with a different camera, or with different camera settings, or
with a changed scene), than like modifying the digital photograph with
some digital "special effect" or "enhancement".
In other words, it is more like recreating the data from scratch, than
like modifying the existing data.

Hence, what we need is probably the freedom to modify the "final data",
if we like to. And also the freedom to replace it with new "final
data" (obtained the way we see fit, possibly with new or additional
measurements and/or new processing).

Source code for the "final data" may well be the "final data"
themselves, as you said.

Ole Streicher

2018-03-19 08:05:51 UTC

Hi Francesco,

Post by Francesco Poli

Post by Ole Streicher
This finally would mean that you need (almost) the whole scientific
(physics) history and discussion as an automated processing chain in
Debian.

I see this differently: The term "source" is misleading when applied to
research data. The base of the usual source definition is that sources
are a creative product, and we try to define the real primary writing as
the source.

In science, this is however differently: The (primary) creative work
here are the research articles, and there is a whole culture around how
to value them and how to ensure freedom of science. Much older,
independently and differently from DFSG: Research articles are usually
not free (as in speech, but often also not as in beer), but there is a
freedom to cite and to critizice, modify, and apply the ideas to own
work.

Research data however are *not* a product of a creative scientific
work. They are either "raw data", produced directly by an observation,
or processed data, made by application of the scientific methods. Both
the data taking and the formal application are not creative; and so data
are not a creative work. Therefore it is useless to think in terms of
"source" here.

Post by Francesco Poli
In the "scientific data" case, changing the raw measurements and/or the
analysis process is probably more like taking a new digital photograph
(perhaps with a different camera, or with different camera settings, or
with a changed scene), than like modifying the digital photograph with
some digital "special effect" or "enhancement".

It may be both: there is the case that one may want to process the same
data with an improved method, or that one may want to apply the same
method to other data.

The difference to your example is that taking a photo is usually a
creative act, while taking research data is not. There are corner cases
like astrophotography: Astronomers take images of the sky, which I would
count as "research data": they are just spacially resolved photon
fluxes. Astrophotographers may even take the same image, but they do
creative work (because they do some kind of art). One may even take a
Hubble raw image and create a "beautiful image" out of it (like PR
images as the "Astronomy Picture of the Day" of NASA); that is creative
(and copyrighted). But preprocessing the same raw for a scientific
analysis is not.

If there is some creativity involved in the process of creation, then we
can speak of a source, and require that this source is included in
Debian. But as discussed, for research data there is no source, and we
should find other means to ensure freedom. As the freedom to replace the
data. Which at least requires that the data are documented (otherwise
you can't replace them in a sensitive way).

Best regards

Ole

Ben Finney

2018-03-19 22:10:15 UTC

Post by Ole Streicher
Research data however are *not* a product of a creative scientific
work.

You may continue to assert that. It doesn't change the facts of how
copyright law works. The Debian Project is bound to work within the
constraints of the current copyright regime.

I support your goal of minimising the reach of copyright, and I hope
that bears fruit. What is fruitless is simply asserting, in this forum,
that you don't think copyright applies.

If you want copyright not to apply around the world to a certain class
of information, your endeavour is not here in this forum; it is with the
lawmakers in those jurisdictions.

--
\ “Some forms of reality are so horrible we refuse to face them, |
`\ unless we are trapped into it by comedy. To label any subject |
_o__) unsuitable for comedy is to admit defeat.” —Peter Sellers |
Ben Finney

Ole Streicher

2018-03-19 22:25:25 UTC

Post by Ole Streicher
Research data however are *not* a product of a creative scientific
work.

You may continue to assert that. It doesn't change the facts of how
copyright law works. The Debian Project is bound to work within the
constraints of the current copyright regime.

It would help in the discussion if you could point to these constraints
(which are applicable to research data), and not just claim that they
may apply in this case.

Best regards

Ole

Ben Finney

2018-03-19 23:23:32 UTC

Post by Ole Streicher
It would help in the discussion if you could point to these
constraints (which are applicable to research data), and not just
claim that they may apply in this case.

That's shifting the burden. Like it or not (for the record: I don't like
this), most Berne signatory jurisdictions assume by default that a fixed
expression is subject to copyright. There are exceptions, but those
exceptions must be positively shown: the burden is on those who would
claim copyright does not apply.

--
\ “Whenever you read a good book, it's like the author is right |
`\ there, in the room talking to you, which is why I don't like to |
_o__) read good books.” —Jack Handey |
Ben Finney

Ole Streicher

2018-03-20 08:45:11 UTC

Post by Ole Streicher
It would help in the discussion if you could point to these
constraints (which are applicable to research data), and not just
claim that they may apply in this case.

The exception used here is that facts are not copyrightable. Positions
and movement parameters of celestial bodies, presented in their natural
form (to keep the use of JPL-DE data as example) are bare facts. And
most of research data is just this: facts.

To bring some citations:

http://downloads.alcts.ala.org/ce/03122014_Copyright_data_Slides.pdf

Slide 3: "Can Date be Copyrighted? Short Answer: NO."

https://www.um.edu.mt/library/oar/handle/123456789/3176

Slide 14: "Not protected: Simply presenting a series of mearurements in
a table"

See also

https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.

A (US) court decision that compilations of facts requires a minimum of
originality to be copyrighted (in that case it was a telephone book; a
time-sorted list of planet positions is the same).

Is this enough material to claim an exception?

Best regards

Ole

Ben Finney

2018-03-20 09:25:01 UTC

Post by Ole Streicher
The exception used here is that facts are not copyrightable. Positions
and movement parameters of celestial bodies, presented in their natural
form (to keep the use of JPL-DE data as example) are bare facts. And
most of research data is just this: facts.

You keep stating this as though it is universally true. It has been
pointed out, in this thread and many times before, that “it's a
collection of facts” does *not* constitute a universal
get-out-of-copyright incantation.

I wish what you assert were true; but it simply is not. For example,
so-called “sui generis” database restrictions recognise copyright in
even collections of brute facts, in many Berne signatory jurisdictions
<URL:https://en.wikipedia.org/wiki/Sui_generis_database_right>.

In jurisdictions like those, where such restrictions are recognised
under law, merely being a collection of facts does not constitute an
exception to general copyright restriction.

Therefore the work is by default restricted by copyright law. Therefore
the work cannot be in Debian without license conditions that satisfy the
DFSG.
Those are, as far as I can tell, statements that *some jurisdictions*
exempt works like these.

That doesn't counter my point, above. There are significantly many
jurisdictions where the work *is* restricted by copyright, that we
cannot assume universal – nor even widespread – exemption from copyright
restriction in this work.

Post by Ole Streicher
Is this enough material to claim an exception?

It may be enough to claim an exemption in the USA. Unfortunately for
your case, Debian recipients in other jurisdictions also need to know
the works in Debian are DFSG-free.

You are IMO correct to argue that such works *should not be* restricted
by copyright. But the fight to make it actually true, needs to be taken
outside this forum and fought in those law-making jurisdictions that
continue to restrict collections of fact under copyright.

--
\ “Airports are ugly. Some are very ugly. Some attain a degree of |
`\ ugliness that can only be the result of a special effort.” |
_o__) —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 |
Ben Finney

Ole Streicher

2018-03-20 11:05:35 UTC

This is *not* copyright. This is a different protection. Please don't
mix the terms here.

Post by Ben Finney
In jurisdictions like those, where such restrictions are recognised
under law, merely being a collection of facts does not constitute an
exception to general copyright restriction.

You may check the EU directive 96/9C as an example: it explicitly states
two distinct types of database protection:

1. copyright protection (which does not apply here),
2. sue generis protection (which is limited in what it protects)

For the JPL-DE databases: they are not protected by sui generis based on this
directive, because

* the sui generis protection is limited to 15 years after publication
(which was in the 70s-90s for JPL-DE)

* they protect only database makers from the EU (which is not the case
for JPL)

* they only protect the effort to collect and organize the database, but
not to collect the data themself. In the JPL case, the effort is
however in collection the data. This is not to compare with
f.e. wikimaps, where a big effort is made to collect and organize the
data. Wikimaps is however no research data.

Post by Ben Finney
Therefore the work is by default restricted by copyright law.

It is not copyrighted, because it falls under the "facts" exception. It
may be protected by other law, but this protection is not copyright (and
therefore you can't assume it is protected by default).

Post by Ben Finney
Therefore the work cannot be in Debian without license conditions that
satisfy the DFSG.
Those are, as far as I can tell, statements that *some jurisdictions*
exempt works like these.

That is US and EU, sure. But the exception that facts are not
copyrightable is universal. Jurisdictions *may* have *additional* forms
of protection (like sui generis), but these are not universal, and you
can't just assume that they are effective by default.

Best regards

Ole

jonathon

2018-03-20 16:54:45 UTC

Post by Ole Streicher
The exception used here is that facts are not copyrightable.

US copyright law has a creativity requirement. Just how much
"creativity" is required is ambiguous.

European copyright law typically has a "seat of the brow" component,
which means under European Copyright law, it would copyright. (That EU
directive doesn't throw out copyright on "sweat of the brow" grounds.)

Post by Ole Streicher
Positions and movement parameters of celestial bodies, presented in

their natural form (to keep the use of JPL-DE data as example) are bare

The creativity here is:
* Which bodies are included;
* How frequently are the co-ordinates listed - hourly, daily, weekly,
monthly, annually, etc.;
* What unit of measurement is used for those co-ordinates;
* What is the starting point of the listings;
* What is the ending point of the listing;

Post by Ole Streicher
A (US) court decision that compilations of facts requires a minimum of
originality to be copyrighted (in that case it was a telephone book; a
time-sorted list of planet positions is the same).

Astrolabe, Inc. v Arthur David Olson and Paul Eggert
Massachusetts District Court 1:2011cv11725
implies that a case to the contrary can be made.

Post by Ole Streicher
Is this enough material to claim an exception?

Nope.

Still doesn't cover those judicial domains in which "public domain" is
not a legally recognised thing.

What is needed is a specific license for the JPL Planetary Ephemeris,
that is congruent with the Debian Social Contract.

I am not a lawyer. This is not legal advice.

jonathon

Ole Streicher

2018-03-20 20:16:32 UTC

Post by Ole Streicher
The exception used here is that facts are not copyrightable.

US copyright law has a creativity requirement. Just how much
"creativity" is required is ambiguous.
European copyright law typically has a "seat of the brow" component,

At least german copyright requires creativity.

Post by jonathon
which means under European Copyright law, it would copyright. (That EU
directive doesn't throw out copyright on "sweat of the brow" grounds.)

It does. It defines an exhaustive list of what is copyrightable (for
databases). Chapter II (Copyright), Article 3:

| 1. In accordance with this Directive, databases which, by reason of
| the selection or arrangement of their contents, constitute the
| author's own intellectual creation shall be protected as such by
| copyright. No other criteria shall be applied to determine their
| eligibility for that protection.

So, no "sweat of the brow" or such (for copyright, suis generis is
different).

Post by Ole Streicher
Positions and movement parameters of celestial bodies, presented in

their natural form (to keep the use of JPL-DE data as example) are bare
* Which bodies are included;
* How frequently are the co-ordinates listed - hourly, daily, weekly,
monthly, annually, etc.;
* What unit of measurement is used for those co-ordinates;
* What is the starting point of the listings;
* What is the ending point of the listing;

This is all not artificially selected.

Astrolabe, Inc. v Arthur David Olson and Paul Eggert
Massachusetts District Court 1:2011cv11725
implies that a case to the contrary can be made.

Astrolabe dismissed the lawsuit, so no court decision was made. In wich
way does this imply that Astrolabe could claim copyright?

Post by Ole Streicher
Is this enough material to claim an exception?

Still doesn't cover those judicial domains in which "public domain" is
not a legally recognised thing.

I don't say it is "public domain". I state that is is not copyrighted.
That is not the same.

Best regards

Ole

jonathon

2018-03-21 15:54:17 UTC

Post by Ole Streicher
Positions and movement parameters of celestial bodies, presented in

This is all not artificially selected.

One hundred percent of it, is an artificial selection.

If you go back to the Feist ruling, had the original list been just odd
phone numbers, or just rural box numbers,the decision would have gone
the other way, because that would have met the "creativity" requirement.
It was only because everything was gulped down, that the decision went
the way it did.

For an ephemeris, the seven points needed to calculate the position of a
body, are facts.

Anything more than that involves an element of creativity.

Going back to my first point: "Which bodies are included", astrologers
have a choice of roughly 1,000 planets which orbit the sun, to choose
from. This is in addition to roughly 1,000,000 asteroids, Kepler
Objects, comets, and other assorted things that either explicitly or
implicitly orbit the sun, or give the appearance of so doing.

Creativity choice # 1: Which objects to include. That you have never
heard of the planet Vulcan, not to be confused with either the planet
Vulkan nor with the planet Vulcanus, both of which have different,
dissimilar orbits around the Sol, the star that the planet Earth orbits,
and none of which are to be confused with either planetoids, asteroids,
Kepler Objects, or minor planets with similar names, does not mean that
the exclusion is not a creative choice.

Post by Ole Streicher
Astrolabe dismissed the lawsuit, so no court decision was made. In which
way does this imply that Astrolabe could claim copyright?

a) Had the EFF not taken the defendant's case pro bona, Astrolabe would
probably have won their lawsuit;

b) With a specific license attached to the content, one can be fairly
confident that one won't be sued for a copyright violation, if one
adheres to the license. Without a license attached to the content, the
only safe assumption is that the content is ARR, and one needs to both
pay royalties, and obtain _written_ permission to use the content. That
automatically make the content in question non-free, and against the
Debian Social Contract.

Post by Ole Streicher
I don't say it is "public domain". I state that is is not copyrighted.
That is not the same.

Technically, you are correct. "Public Domain" and "not copyrighted" are
two different things. Do you really want to go down the road of "it is
not copyrighted", whilst excluding it from the realm of "Public Domain"?
If so, then you have demonstrated precisely why the content in
question can not be included in either Debian Free, or in Debian Non-Free.

I am not a lawyer. This is not legal advice.

jonathon

Francesco Poli

2018-03-24 18:49:16 UTC

On Mon, 19 Mar 2018 09:05:51 +0100 Ole Streicher wrote:

[...]
[...]

Post by Francesco Poli
I think that a work that includes data (such as the electric charge of
an electron) *can* be in source form, without the need to ship all the
raw measurements that brought us to the determination of good values for
these data, or to build-depend on the whole analysis process that
brought us to that same determination.
What's good about the definition of source is that it is flexible
enough to cope with many corner cases.

I see this differently: The term "source" is misleading when applied to
research data.

I don't think we need to define new guidelines for assessing the
freeness of scientific data.
The DFSG and the definition of source may be applied to scientific data
as well. This is possible because of the flexibility of the definition
of source, as I said.

Moreover, there is no clear-cut line between scientific data and works
of authorship. The boundary is blurred, as your example about
astrophotography shows...
Hence, we cannot apply different "rules", depending on this blurred
distinction.

[...]

Post by Ole Streicher
In science, this is however differently: The (primary) creative work
here are the research articles, and there is a whole culture around how
to value them and how to ensure freedom of science. Much older,
independently and differently from DFSG: Research articles are usually
not free

[...]

The fact that many technical-scientific research articles are not
DFSG-free is an issue in itself, in my opinion. But this is another
(long) story...

jonathon

2018-03-01 08:12:32 UTC

Post by Ole Streicher
Again, as shown here: this license covers *software*, not *data*.

As far as copyright law is concerned, there is no difference between
data and software.

For some programming languages, there is no difference between data and
code.

Post by Ole Streicher
Data is fundamentally different from software: for example, there is no "source code" for DE405.

The source code for the ephemeris is physical observations of the stars,
planets, and other bodies in it.

jonathon

Ben Finney

2018-03-01 09:38:12 UTC

Post by jonathon
The source code for the ephemeris is physical observations of the stars,
planets, and other bodies in it.

The physical observations are not a work of expression; likewise, my
physical observation of a mountain is not a work of expression. They may
be the “source of the data” in some sense, but that sense is not
relevant for figuring out the license on a work of expression.

In the mountain example, the mountain is not a work of expression;
a digitally-recorded photograph of that moment at a place and time *is*
a work of expression. It may even be the source form of the work.

The “physical observations of [natural phenomena]” does not describe a
form of the work, so it cannot be the source form of the work.

Rather, the source form of the work is whichever form of the work – in
this case, some specific form of the ephemeris data – which would be
preferred for the purpose of making modifications to the work.

--
\ “Think for yourselves and let others enjoy the privilege to do |
`\ so too.” —Voltaire, _Essay On Tolerance_ |
_o__) |
Ben Finney

Ole Streicher

2018-03-01 10:34:36 UTC

Post by Ole Streicher
Data is fundamentally different from software: for example, there is
no "source code" for DE405.

The source code for the ephemeris is physical observations of the stars,
planets, and other bodies in it.

Source code is an entity, but observation is an activity, so it cannot
be source code.

Cheers

Ole

jonathon

2018-03-01 22:33:11 UTC

Source code is an entity, but observation is an activity, so it cannot be source code.

technically, how the observation is recorded is the source code. But
without that observation, there is no source code.

jonathon

v***@heuserlawoffice.com

2018-03-01 11:50:37 UTC

An expression of which observations may
be subject ot copyright, but the observations themselves,
(i.e., data) are not.

It seems an expression of data or source code
may be subject to protection, but the information
and algorithm are not sunject to copyright.
The latter may have implications the patent area.

102. Subject matter of copyright: In general
(a) Copyright protection subsists, in accordance with this title, in
original works of authorship fixed in any tangible medium of expression, now
known or later developed, from which they can be perceived, reproduced, or
otherwise communicated, either directly or with the aid of a machine or
device. Works of authorship include the following categories:
(1) literary works;
(2) musical works, including any accompanying words;
(3) dramatic works, including any accompanying music;
(4) pantomimes and choreographic works;
(5) pictorial, graphic, and sculptural works;
(6) motion pictures and other audiovisual works;
(7) sound recordings; and
(8) architectural works.
(b) In no case does copyright protection for an original work of authorship
extend to any idea, procedure, process, system, method of operation,
concept, principle, or discovery, regardless of the form in which it is
described, explained, illustrated, or embodied in such work.

103. Subject matter of copyright:
Compilations and derivative works
(a) The subject matter of copyright as specified by section 102 includes
compilations and derivative works, but protection for a work employing
preexisting material in which copyright subsists does not extend to any part
of the work in which such material has been used unlawfully.
(b) The copyright in a compilation or derivative work extends only to the
material contributed by the author of such work, as distinguished from the
preexisting material employed in the work, and does not imply any exclusive
right in the preexisting material. The copyright in such work is independent
of, and does not affect or enlarge the scope, duration, ownership, or
subsistence of, any copyright protection in the preexisting material.

----- Original Message -----
From: "jonathon" <***@gmail.com>
To: <debian-***@lists.debian.org>
Sent: Thursday, March 01, 2018 3:12 AM
Subject: Re: JPL Planetary Ephemeris DE405

Post by Ole Streicher
Again, as shown here: this license covers *software*, not *data*.

As far as copyright law is concerned, there is no difference between
data and software.
For some programming languages, there is no difference between data and
code.

Post by Ole Streicher
Data is fundamentally different from software: for example, there is no
"source code" for DE405.

The source code for the ephemeris is physical observations of the stars,
planets, and other bodies in it.
jonathon

jonathon

2018-02-28 21:27:28 UTC

Post by Francesco Poli
Where can I find the text of the NOSA v2.0 ?

but the attachment containing the text was scrubbed.

Thanks.

jonathon

Walter Landry

2018-02-27 22:34:20 UTC

That intent explicitly does not permit distribution of modified works.
That permission is needed if the work is to be free software.

You are right. I missed that.

Walter Landry

Ole Streicher

2018-02-28 07:30:40 UTC

Post by Ben Finney
I think it is non-free, for the reason above.
If the license conditions also do not permit redistribution of modified
works, the work is not DFSG-free. It cannot be in Debian.

I still think that the DE405 database is not a creative work and
therefore not copyrightable; therefore no license is needed to make use
of it.

Best regards

Ole

Ole Streicher

2018-02-28 07:37:29 UTC

Post by Dave Hibberd
https://naif.jpl.nasa.gov/naif/rules.html
See especially sections on Kernels Distribution and Kernels
Redistribution. The intent is to allow anyone to use or redistribute
as long as the files/kernels are not modified."

This is incomplete. The full paragraph is:

| Redistribution of SPICE kernels distributed by NAIF is permitted as
| long as they have not been modified. If a kernel distributed by NAIF
| has been modified in any way, any embedded or otherwise allied
| attribution of the original kernel producer must be replaced with the
| name and institution of whomever has made the last
| modification. Redistribution of kernels distributed by any other
| entity is subject to the rules on and of that entity.

Cheers

Ole

Ole Streicher

2018-02-23 08:14:32 UTC

Hi Hibby,

I think that these files are public domain: First, they are originated
by nasa.gov, which is a U.S. governmental institution, and so they are
PD by law.

Then (and may be more important): These files are not copyrightable ad
all, since they are natural data; they describe *facts*. As one can't
copyright the distance to the moon, one can't copyright the details of
earth rotation.

I wanted to package these files as well

* http://bugs.debian.org/842931 casacore-data-jplde
* https://salsa.debian.org/debian-astro-team/casacore-data-jplde

but I stopped at some point since I couldn't create the binary database
in the required (casacore) format at the time. I could restart my
approach, and since the sources are identical, we could generate both
binaries from the same source.

What do you think?

Best regards

Ole

Post by Hibby
I am currently packaging wsjtx[1][2] for re-inclusion in Debian.
In the code there is a binary - JPLEPH[3], which looks to be a compiled
version of JPL Planetary Ephemeris[4]. Inspecting the binary, I assume
the tool used was asc2eph, so I'm assuming it's the v405 ascii
ephemerides files that were used. I'm contacting the upstream author to
clarify this. Ideally I'd like to upload the source and build this file
as part of the package build process.
What I'm here to clarify is that I can't see a license for the ascii
files - I'm not sure if this fileset is something that anyone in
debian-legal have come across, or have any advice on what license they
may have been released under? I can't see anything on the JPL FTP server
outside of the CD Notes from the original release [5]. The contact
detailed on them worked at JPL 21 years ago, and I don't reckon the
email address is still active.
Any advice or suggestions you can offer would be greatly received!
Thanks,
Hibby
[1] http://www.physics.princeton.edu/pulsar/K1JT/
[2] https://tracker.debian.org/pkg/wsjtx
[3]
https://salsa.debian.org/debian-hamradio-team/wsjtx/tree/master/contrib/Ephemeris
[4] https://ssd.jpl.nasa.gov/?planet_eph_export
[5] ftp://ssd.jpl.nasa.gov/pub/eph/planets/CDROM.notes

Hendrik Weimer

2018-02-23 17:28:54 UTC

Post by Ole Streicher
I think that these files are public domain: First, they are originated
by nasa.gov, which is a U.S. governmental institution, and so they are
PD by law.

This is only true within the United States. Internationally, U.S. govt
works are still protected and distribution requires a valid license.

Hendrik

Roberto

2018-02-23 22:24:51 UTC

Post by Ole Streicher
Then (and may be more important): These files are not copyrightable ad
all, since they are natural data; they describe *facts*. As one can't
copyright the distance to the moon, one can't copyright the details of
earth rotation.

A collection of facts can have a copyright even if the facts themselves
can not. This is known as the Directive 96/9/EC on the EU.

http://www.esa.int/About_Us/Law_at_ESA/Intellectual_Property_Rights/Copyright_and_databases

Ole Streicher

2018-02-23 22:41:37 UTC

A collection of facts can have a copyright even if the facts themselves
can not. This is known as the Directive 96/9/EC on the EU.

That is generally not true for scientific databases: When the entries
are selected by objective criteria (which is the common case for such
databases), the database is not copyrightable.

Best

Ole

Roberto

2018-02-24 11:14:49 UTC

Post by Ole Streicher
That is generally not true for scientific databases: When the entries
are selected by objective criteria (which is the common case for such
databases), the database is not copyrightable.

That's open to the interpretation of the judges. Search for previous
cases and you'll be surprised. A company that I've worked for was one of
such victims.

Ole Streicher

2018-02-24 13:03:44 UTC

That's open to the interpretation of the judges. Search for previous
cases and you'll be surprised. A company that I've worked for was one of
such victims.

Sure; law is always open to be interpreted by the court. This is
generally true and not specific to this case.

Best regards

Ole

Roberto

2018-02-24 14:57:37 UTC

Post by Ole Streicher
Sure; law is always open to be interpreted by the court. This is
generally true and not specific to this case.

Yes but, what I want to say is that, in this particular case, I don't
think it's safe to assume that a collection of facts can't have
copyright, not even when it's entries are selected by objective
criteria. Let's quote the Directive No. 96/9/EC:

Article 7
Object of protection

Member States shall provide for a right for the maker of a database
which shows that there has been qualitatively and/or quantitatively a
substantial investment in either the obtaining, verification or
presentation of the contents to prevent extraction and/or re-utilization
of the whole or of a substantial part, evaluated qualitatively and/or
quantitatively, of the contents of that database.

[...]

Notice that database creators can argue that they have made a
"substantian investment in verifying the contents" to justify their
database protection. It's not needed to have made an effort in manually
selecting entries (yes, that's another way to have a database protected,
but not the only one). I'm worried that this is not taken seriously
because it has been used plenty of times already, and the way the
directive is written is quite biased toward creators of databases as far
as I can tell in my opinion. The only exceptions given are those in the
Article 6, in short: for private, scientific research, or non-commercial
purposes.

Ole Streicher

2018-02-24 21:51:55 UTC

Post by Ole Streicher
Sure; law is always open to be interpreted by the court. This is
generally true and not specific to this case.

Yes but, what I want to say is that, in this particular case, I don't
think it's safe to assume that a collection of facts can't have
copyright, not even when it's entries are selected by objective
Article 7
Object of protection
Member States shall provide for a right for the maker of a database
which shows that there has been qualitatively and/or quantitatively a
substantial investment in either the obtaining, verification or
presentation of the contents to prevent extraction and/or re-utilization
of the whole or of a substantial part, evaluated qualitatively and/or
quantitatively, of the contents of that database.
[...]

This is not copyright, which is handled in Chapter II. Article 3:

| 1. In accordance with this Directive, databases which, by reason of
| the selection or arrangement of their contents, constitute the
| author's own intellectual creation shall be protected as such by
| copyright. No other criteria shall be applied to determine their
| eligibility for that protection.

This is exhaustive ("no other criteria...").

I read that article 7 that you cited as: the maker of a database has the
right to protect it -- which however needs him to be active (which is
not the case for the JPL).

Best regards

Ole

Roberto

2018-02-24 23:13:41 UTC

Post by Ole Streicher
I read that article 7 that you cited as: the maker of a database has the
right to protect it -- which however needs him to be active (which is
not the case for the JPL).

Okay, feel free to include databases of facts in Debian if you think
it's safe, I'll feel free to blacklist those packages, and everyone is
happy.

In this particular case, it may be safe, I don't know the JPL database,
and it seems that it cames from the US. My email was to disagree with
your statement that a collection of facts can't be copyrighted. The
Directive is a document that members of EU need to comply by modifying
their local laws (usually by amending copyright laws), which, to make
things more complicated, the exact terms vary between each EU member. If
you are still convinced that it can't be copyrighted and they are safe,
well, there is nothing more that I can say, go ahead and use them. For
my part, I've seen a case of copyright sucesfully applied to a
completely automated list of facts, and that's enough for me to be
convinced of the opposite.

I still think that recommending them for inclusion in Debian without
properly analyzing each case and the author intents,

It seems that you know the directives in EU (I though at first that you
were not aware of them), and you still defend that they are safe, which
is fine, you are free to have your opinion. I'm still thinking that not
taking seriously the database laws, and including them in Debian without
properly analyzing each case and author intents is quite unfortunate,
though.

Ole Streicher

2018-02-25 12:47:51 UTC

Post by Roberto
In this particular case, it may be safe, I don't know the JPL database,
and it seems that it cames from the US. My email was to disagree with
your statement that a collection of facts can't be copyrighted.

My argument here is that (most) *scientific* data collections are not
copyrightable, since they rely on an objective selection (or no
selection at all).

Your other argument (with article 7) has nothing do do with copyright:
even when this article applies to a database, it is still not
(necessarily) copyright protected. Article 7 just claims that the maker
of a database *may* protect his work; but as long as he does not do
this, there are no restrictions. This is the opposite to copyright,
where the default is restrictive and the copyright owner may grant you
rights. And it also is possible only for 15 years.

Post by Roberto
The Directive is a document that members of EU need to comply by
modifying their local laws (usually by amending copyright laws),
which, to make things more complicated, the exact terms vary between
each EU member.

That is true, ofcourse.

Post by Roberto
I'm still thinking that not taking seriously the database laws, and
including them in Debian without properly analyzing each case and
author intents is quite unfortunate, though.

Sure. My statement was just a rule of thumb for *scientific*
databases. I am biased f.e. by astronomical catalogues: No creativity in
selection, no creativity in arrangement, and no content protection by
the maker.

Best regards

Ole

Roberto

2018-02-25 21:48:18 UTC

Post by Ole Streicher
even when this article applies to a database, it is still not
(necessarily) copyright protected. Article 7 just claims that the maker
of a database *may* protect his work; but as long as he does not do
this, there are no restrictions. This is the opposite to copyright,
where the default is restrictive and the copyright owner may grant you
rights. And it also is possible only for 15 years.

I'm not sure if I'm not understanding what you mean correctly. The
Directive is not a modification to copyright, but EU member countries
modify their copyright laws to include those protections.

Each country have its local laws. In Spain, the copyright law it's not
even called "copyright", it is called the LPI, but the word "Copyright"
is still recognised for compatibility with the Berne Convention. The
declaration has many differencies with the US definition of copyright,
for example, definition of "fair use" is not compatible, the "public
domain" concept doen't even exist (though it is usually considered safe
to import and use public domain works from countries which do define
it), and thousands of other differences. So, it's easier to refer to the
text of the Directive directly rather than to individual copyright
declarations for each country under their own legal jurisdiction. I
think that's what is confusing you into thinking that it is nothing to
do with Copyright (or maybe I'm not understanding your point, I'm not
sure). I hope it's more clear now.

The modification of Spanish copyright declaration was published on
"BOE", which is the official document that informs about those changes.
It was recorded in BOE-A-1998-5568, it's in Spanish but if you feel
interested you can search it online at http://www.boe.es/ and translate
it (hopefully the translator don't mess too much with it, law articles
are writen in a very specific form). All requirements of the database
directive has been included into the Spanish copyright law. So well, I
don't understand why you say that it has nothing to do with copyright,
sure it does.

If you read the Spanish LPI with its modifications, you'll see that a
database or collection of things can now be copyrighted (and actually it
is automatically copyrighted and protected like any other work). The
copyright law is extended so it includes all those provisions required
by the database directive, including the protection of collections of
works that are factual, non-artistic, non-creative, when the creator of
the colletion has invested time and/or effort in the validation process,
etc... I personally think that the choosen wording provides even more
than required by the database directive, which makes easier to claim
copyright for trivial things wrapped into databases, unfortunately. Yes,
there had been opposition, specially at first, but time has passed and
the modified copyright law is still being used (and abused).

It seems that you don't believe me when I say that I've seen databases
of trivial things beign enforced, and that's fine, not trusting random
persons over the Internet is OK. Writing in English takes a long time
for me so please excuse me if I don't continue to explain how copyright
works in my country. If you want to research and see it by yourself, you
are welcome.

jonathon

2018-02-25 22:28:01 UTC

In Spain, ... the "public domain" concept doesn't even exist

Spain is not the only country to have no concept of "public domain".
Which is precisely why one needs to how the JPL Planetary Ephemeris is
licensed.

jonathon

Ole Streicher

2018-02-26 08:03:56 UTC

I'm not sure if I'm not understanding what you mean correctly. The
Directive is not a modification to copyright, but EU member countries
modify their copyright laws to include those protections.

The directive is about database protection, not (only) about
copyright. It mainly shows *two* independent possibilities how database
are protectable:

1. Copyright protection: By accounting the creativity to produce the
database; this is article 3, and this is done by applying a
copyright. The article actually *limits* the reasons why a database can
be copyright protected, by specifying an exhaustive list (selection and
arrangement). Every database that does not follow this rules is not
copyright protected according to the directive.

2. "Sui Generis Right": By accounting the investment to create the
database. The directive allows (resp. requests from the EU countries to
allow) to protect this investment. This protection is however *not*
copyright protection. A database that was created with substantial
investment but without creativity in selection or arrangement is still
not protected by copyright, even when the maker decides to protect it
under article 7.

Post by Roberto
Each country have its local laws. In Spain, the copyright law it's not
even called "copyright", it is called the LPI, but the word "Copyright"
is still recognised for compatibility with the Berne Convention. The
declaration has many differencies with the US definition of copyright,
for example, definition of "fair use" is not compatible, the "public
domain" concept doen't even exist (though it is usually considered safe
to import and use public domain works from countries which do define
it), and thousands of other differences. So, it's easier to refer to the
text of the Directive directly rather than to individual copyright
declarations for each country under their own legal jurisdiction. I
think that's what is confusing you into thinking that it is nothing to
do with Copyright (or maybe I'm not understanding your point, I'm not
sure). I hope it's more clear now.

No. Article 3 is very clear about for which reasons a database is
copyrigh protectable. The phrase

| No other criteria shall be applied to determine their eligibility for
| that protection.

is there for a reason. Also, the article 7 is not in Chapter II
"Copyright", but in Chapter III "Sui Generis Right". In this article,
they very carefully did not use the words "author" or "creator", but
"maker" of a database.

Best regards

Ole

Ole Streicher

2018-02-26 09:16:49 UTC

Post by Ole Streicher
2. "Sui Generis Right": By accounting the investment to create the
database.

One thing to add here is article 11:

| Beneficiaries of protection under the sui generis right
|
| 1. The right provided for in Article 7 shall apply to database whose
| makers or rightholders are nationals of a Member State or who have
| their habitual residence in the territory of the Community.
|
| 2. Paragraph 1 shall also apply to companies and firms formed in
| accordance with the law of a Member State and having their registered
| office, central administration or principal place of business within
| the Community; however, where such a company or firm has only its
| registered office in the territory of the Community, its operations
| must be genuinely linked on an ongoing basis with the economy of a
| Member State.
|
| 3. Agreements extending the right provided for in Article 7 to
| databases made in third countries and falling outside the provisions
| of paragraphs 1 and 2 shall be concluded by the Council acting on a
| proposal from the Commission. The term of any protection extended to
| databases by virtue of that procedure shall not exceed that available
| pursuant to Article 10.

As far as I know, there is no extension agreement with the US. So, JPL as
the database maker cannot protect the database by article 7.

Also, the protection in article 7 expires after 15 years (article
10). The databases DE200 and DE405 are however created 1981 and 1998; so
they cannot be protected on this base.

Best regards

Ole

Roberto

2018-02-26 11:59:17 UTC

Post by Ole Streicher
As far as I know, there is no extension agreement with the US. So, JPL as
the database maker cannot protect the database by article 7.
Also, the protection in article 7 expires after 15 years (article
10). The databases DE200 and DE405 are however created 1981 and 1998; so
they cannot be protected on this base.

This is indeed a useful response that I was expecting, thanks.

Roberto

2018-02-26 11:44:03 UTC