[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: JPL Planetary Ephemeris DE405



Francesco Poli <invernomuto@paranoici.org> writes:
> 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.

> 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.

>> 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.

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


Reply to: