On Mon, 19 Mar 2018 09:05:51 +0100 Ole Streicher wrote:
[...]
> Francesco Poli writes:
[...]
> > 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
On 03/20/2018 08:16 PM, Ole Streicher wrote:
>>> 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
jonathon writes:
> On 03/20/2018 08:45 AM, Ole Streicher wrote:
>
>> 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
On 03/20/2018 08:45 AM, Ole Streicher wrote:
> 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
Ben Finney writes:
> Ole Streicher writes:
>
>> 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
Ole Streicher writes:
> 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
Ben Finney writes:
> Ole Streicher writes:
>
>> 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
Ole Streicher writes:
> 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),
Ben Finney writes:
> Ole Streicher writes:
>
>> 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
Ole Streicher writes:
> 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
Hi Francesco,
Francesco Poli writes:
>> This finally would mean that you need (almost) the whole scientific
>> (physics) history and discussion as an automated processing chain in
>> Debian.
>
> If this is what you meant, then I must have misread your reasoning.
> I
On Sat, 17 Mar 2018 18:54:43 +0100 Ole Streicher wrote:
> Francesco Poli writes:
[...]
> > 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
Francesco Poli 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.
On Thu, 01 Mar 2018 20:36:48 +0100 Ole Streicher wrote:
> Francesco Poli writes:
[...]
> > 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
On 03/01/2018 10:34 AM, Ole Streicher wrote:
> 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
Francesco Poli writes:
> I wrote an
> [essay](https://www.inventati.org/frx/essays/softfrdm/whatissource.html)
> on this topic.
>
> [...]
>> Is it the preferred form of the work for making modifications (GPL def)?
>>
>> Clearly not. The preferred form would be to
On Thu, 01 Mar 2018 11:29:03 +0100 Ole Streicher wrote:
> Ben Finney writes:
> >> 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
.
- Original Message -
From: "jonathon" <jonathon.bl...@gmail.com>
To: <debian-legal@lists.debian.org>
Sent: Thursday, March 01, 2018 3:12 AM
Subject: Re: JPL Planetary Ephemeris DE405
On 02/28/2018 12:17 PM, Ole Streicher wrote:
Again, as shown here: this li
jonathon writes:
>> 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
Ben Finney writes:
>> 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
jonathon writes:
> 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
On 02/28/2018 12:17 PM, Ole Streicher wrote:
> 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.
> Data is
Ole Streicher writes:
> 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.
> Data is
On 02/28/2018 11:42 AM, Dmitry Alexandrov wrote:
>>> Where can I find the text of the NOSA v2.0 ?
>> but the attachment containing the text was scrubbed.
> Here it is:
Thanks.
jonathon
Dmitry Alexandrov <321...@gmail.com> writes:
>>> 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.
>> 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:
NASA OPEN SOURCE AGREEMENT
Dave Hibberd writes:
> 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
Ben Finney writes:
> 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
On 02/27/2018 10:39 PM, Francesco Poli wrote:
> 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.
On Tue, 27 Feb 2018 22:22:48 + jonathon wrote:
> On 02/27/2018 09:54 PM, Ben Finney wrote:
> > 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
>
Ben Finney writes:
> Dave Hibberd writes:
>
>> […]
>> 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
On 02/27/2018 09:54 PM, Ben Finney wrote:
> 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
Dave Hibberd writes:
> […]
> 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
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
Dave Hibberd writes:
> Walter,
>
> Thanks for the response - I got in touch with Mr
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
On Mon, Feb 26, 2018 at 10:16:49AM +0100, Ole Streicher wrote:
> 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
On Mon, Feb 26, 2018 at 09:03:56AM +0100, Ole Streicher wrote:
> 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
>
Ole Streicher writes:
> 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
|
Roberto writes:
> On Sun, Feb 25, 2018 at 01:47:51PM +0100, Ole Streicher wrote:
>> 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
On 02/25/2018 09:48 PM, Roberto wrote:
> 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
On Sun, Feb 25, 2018 at 01:47:51PM +0100, Ole Streicher wrote:
> 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*
Roberto writes:
> 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*
On Sat, Feb 24, 2018 at 10:51:55PM +0100, Ole Streicher wrote:
> 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
Roberto writes:
> On Sat, Feb 24, 2018 at 02:03:44PM +0100, Ole Streicher wrote:
>> 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
>
On Sat, Feb 24, 2018 at 02:03:44PM +0100, Ole Streicher wrote:
> 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
Roberto writes:
> On Fri, Feb 23, 2018 at 11:41:37PM +0100, Ole Streicher wrote:
>> 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.
On Fri, Feb 23, 2018 at 11:41:37PM +0100, Ole Streicher wrote:
> 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
Roberto writes:
> On Fri, Feb 23, 2018 at 09:14:32AM +0100, Ole Streicher wrote:
>> 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
On Fri, Feb 23, 2018 at 09:14:32AM +0100, Ole Streicher wrote:
> 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.
Ole Streicher writes:
> 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
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
Hibby writes:
> 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
Hi all,
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
53 matches
Mail list logo