Re: MIT Licensed code in LD_PRELOAD?

[Ole Streicher]

Marc Haber  writes:
> I am planning to package a small bit of code that is MIT licensed and is
> intended to be used via LD_PRELOAD to overload and inflience the bind()
> syscall regarding source address selection.
>
> Is the MIT License sufficiently compatible to the (L)GPL to allow this
> use? The code interfaces both with the (arbitrary) application issueing
> the bind() call and the glibc. Is that a linking issue?

As far as I understand, the LGPL does not limit the use of a program.

And when you create or distribute a package, you are only bound to the
license conditions of the code pieces that you use to create it.  As
long as your binary package is not a derivative of an (L)GPL program,
its license conditions cannot be influenced by (L)GPL.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>
>> Paul Jakma  writes:
>>> On Wed, 20 Mar 2019, Ole Streicher wrote:
>>>> #include 
>>>> int main(void) { zlog_rotate(); return 0; }
>>>>
>
>> This work is completely based on my own, there is no intellectual
>> property of someone else in my source code.
>
> Except for the big "zlog_rotate" there that you're building on,
> provides all the functionality, and which must be understood to
> understand what this programme does.

I do not build on anything. I wrote two lines of code. I even didn't
check whether it compiles.

*If* you are building a program out of that (compiling, linking with GPL
code), then the program should be under GPL, undoubtly.

But this is not what I did. I just wrote some source code, without using
external intellectual property. So, I am free to distribute that code
under any license I want. I did not use GPL code to write my example, so
I can't be bound to its conditions when I distribute my writing.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>> #include 
>> int main(void) { zlog_rotate(); return 0; }
>>
>> is not an adaption of any GPL code. It is fully written by my
>> own.
>
> It is written by you, and you have copyright in it (in some way, I
> have the vague idea there can be complex legal details in that).
>
> However, assuming this "zlog_rotate" function is non-trivial and a
> copyrightable work, then the holder of the copyright in "zlog_rotate"
> /also/ has copyright in your work. For your work is based upon the
> "zlog_rotate" work - it /is/ an adaptation of it.

This work is completely based on my own, there is no intellectual
property of someone else in my source code.

Only the compilation step incorporates other code (via the #include
statement, and, when linked, the library), but this does affect only the
object and executable files.

>> Otherwise you must point to a certain code file and prove that it
>> contains code which is a modified copy of an GPLed file. Which you
>> not did yet.
>
> I have given examples of files where the legal advice is that they are
> derived works of the GPL code.

To comply with section 2, they must be "modified copies". So, please
show the files, the original files, and the modification.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:

>> GPLv2, section 2 explicitly allows aggregation:
>>
>> | In addition, mere aggregation of another work not based on the Progra
>
> How can this apply to a derived work, which is based on the GPL work?

The FRR code is not "derived work". It is not a modified copy of any GPL
code. Instead it aggregates the (changed? unchanged?) GPL code with code
that is written on its own. This code is not a modified copy of any GPL
code, therefore they can give any license to it.

"Modified copy" is the term which is used in GPL, and you should prove
that the code in question is a modified copy.

Again, I can put my mini-2-liner under any license, unaffected by the
GPL. Since it is not a modified copy of anything.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

David Given  writes:
> - I can't use this library in closed source code, and distribute the
> result as an aggregate --- because there is no license which can meet
> the terms of the GPL and my closed source license.
>
> - I can use this this library in closed source code, and distribute
> the library and the closed source code seperately --- because they're
> not being distributed together it's not an aggregation, and both sets
> of licensing terms are being met independently.

GPLv2, section 2 explicitly allows aggregation:

| In addition, mere aggregation of another work not based on the Program
| with the Program (or with a work based on the Program) on a volume of
| a storage or distribution medium does not bring the other work under
| the scope of this License.

Therefore, I would think that one *can* distribute both source codes
together, even when part of it is closed source.

Best

Ole

Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)

[Ole Streicher]

Giacomo Tesio  writes:
> The current construct is a violation of the GPL term as that code is
> derivative of GPL code for all intents and purposes. So much that it
> cannot even compile without the GPL code.

For the license of source code, it is not required that it compiles.

And, taking out a portion of the code (a single algorithm or so) that
does not depend on GPL code and to re-use it elsewehere is a normal and
intended use for an open source program. It is one of the goals of
having a program open source.

And if the code is a modified copy (this is what the GPL actually
protects), you should prove that: show the code in question, show the
original (GPL) code and show how it was modified.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>
>> Those files do not use GPL code; they just refer to it. No line of that
>> code was originated in GPL licensed code.
>
> Ah, you're in the "copyright only protects literal copying" camp, and
> you don't acknowledge the concept of derived works.

In the GPL case, it protects /modified/ code copies.

|  2. You may modify your copy or copies of the Program or any portion
| of it, thus forming a work based on the Program, and copy and [...]

The example I brought, was written from scratch, it was therefore not a
"modified copy".

> Copyright gives authors of works not just the right not to just
> control literal copying, but also a controlling right in any
> adaptations of their work (amongst other things).

My example

#include 
int main(void) { zlog_rotate(); return 0; }

is not an adaption of any GPL code. It is fully written by my
own. Therefore, I don't need to respect the GPL to distribute it. The
same is true for the FRR code as far as I have seen it.

Otherwise you must point to a certain code file and prove that it
contains code which is a modified copy of an GPLed file. Which you not
did yet.

Best

Ole

Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>
>> A downstream could remove the GPL dependencies (for example by
>> replacing it with a [dummy] re-implementation, or by removing any
>> references) and legally redistribute the result under a non-GPL
>> license.
>
> I advised the people, who are now FRR, that this would be one way
> forward, *many years* ago - before this mess was in full bloom. It
> would have taken time, but it would have been possible (I'd not have
> spent my time doing this for free or on a low-wage though).
>
> They rejected taking this approach.

They don't need to do that themself, but they may want to keep that path
open for downstream. And so their license allows that.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>
>> This does not match section 1, which allows the distribution of
>> unmodified files along with the proper license information.
>
> What unmodified files are you referring to?

Section 1 handles the case of unmodified files, and this is what I
referred to.

> I have explained several times now that this concerns files which were
> created outside of Quagga [...]
>
> Those files are derived works of the GPL code and must be distributed
> according to the conditions of the GPL licence, if they are to be
> distributed lawfully.

Those files do not use GPL code; they just refer to it. No line of that
code was originated in GPL licensed code.

If someone compiles the code, then the compiler merges the GPL licensed
header, creating an object file that drives from GPL (and must be
distributed as such). But this applies to the object file, not to the
source.

> The GPL licence requires appropriate copyright notices in Section
> 1. Section 1 applies to unmodified files, and it also applies to
> modified files and derived works (see Section 2).

Files written from scratch are not derived works. When I write the
following lines:

#include 
int main(void) { zlog_rotate(); return 0; }

then this is my own code, not derived from any GPL code. I can
distribute this code under any license I want, even when it is meant to
be used with the Zebra log implementation, and even when it has no
meaning outside of this.

The created *object* file must be under GPL, if zebra's log.h was used
to create it -- since log.h is GPL.

Best

Ole

Re: no need to keep non-copylefted files that way in a copylefted project. (was Re: FRR package in Debian violates the GPL licence)

[Ole Streicher]

Giacomo Tesio  writes:
> While they are distributing the whole as GPL (which is correct) they
> are actively stating that people can take a part of it that can only
> be used as GPL and use it under a different license, while whoever do
> so automatically terminates their own license on the whole FRR.

A downstream could remove the GPL dependencies (for example by replacing
it with a [dummy] re-implementation, or by removing any references) and
legally redistribute the result under a non-GPL license.

The current construct allows this, and this seems to be the intention of
the copyright owners of the questioned code. You may not like it, but
since the code writers do not derived from GPL code when they wroteg
their source (the GPL code is only used when it is compiled/linked),
they are free to do so.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Giacomo Tesio  writes:
> On 20/03/2019, Ole Streicher  wrote:
>> This does not match section 1, which allows the distribution of
>> unmodified files along with the proper license information.
>>
>> Again: Could you please point to the section in the GPL that is
>> violated?
>
> The "with the proper license" part. ;-)

As far as I checked, all unmodified GPL licensed files keep the short
GPL statement in the file, and are accompanied with a copy of the GPL in
the project's root directory. To cite the relevant section from GPL:

| 1. You may copy and distribute verbatim copies of the Program's source
| code as you receive it, in any medium, provided that you conspicuously
| and appropriately publish on each copy an appropriate copyright notice
| and disclaimer of warranty; keep intact all the notices that refer to
| this License and to the absence of any warranty; and give any other
| recipients of the Program a copy of this License along with the Program.
|
| You may charge a fee for the physical act of transferring a copy, and
| you may at your option offer warranty protection in exchange for a fee.

This all is respected, for each unchanged file. I don't see a violation
here.

Best

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Tue, 19 Mar 2019, Ole Streicher wrote:
>> Paul Jakma  writes:
>>> b) They are not complying with Section 1.
>>
>> In GPLv2, section 1 allows the distribution of unmodified source code,
>> if the license information is distributed unmodified as well.
>
>> Which unmodified GPL source code do they distribute without the
>> licensing information?
>
> They are distributing files which were created outwith of Quagga,
> which explicitly refer to, make use of and rely upon facilities
> provided by GPL code obtained from Quagga (which obtained code from
> GNU Zebra before it).

This does not match section 1, which allows the distribution of
unmodified files along with the proper license information.

Again: Could you please point to the section in the GPL that is
violated?

Best regards

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> On Tue, 19 Mar 2019, Ole Streicher wrote:
>
>> Paul Jakma  writes:
>>> The people involved in (3) - Linux Foundation, Cumulus Networks,
>>> 6WIND, Big Switch Networks, etc. - refuse to acknowledge the legal
>>> reality that the code of (3) is covered by the GPL licence of the code
>>> of (2), and refuse to honour the conditions required by the GPL - see
>>> David Lamparter's mail.
>>
>> And which statement of the GPL do they violate in your opinion?
>
> a) They are very clear they are /not/ distributing the source code under
>the GPL licence.
>
> b) They are not complying with Section 1.

In GPLv2, section 1 allows the distribution of unmodified source code,
if the license information is distributed unmodified as well.

Which unmodified GPL source code do they distribute without the
licensing information?

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

Paul Jakma  writes:
> The people involved in (3) - Linux Foundation, Cumulus Networks,
> 6WIND, Big Switch Networks, etc. - refuse to acknowledge the legal
> reality that the code of (3) is covered by the GPL licence of the code
> of (2), and refuse to honour the conditions required by the GPL - see
> David Lamparter's mail.

And which statement of the GPL do they violate in your opinion?

Ole

Re: FRR package in Debian violates the GPL licence

[Ole Streicher]

David Lamparter  writes:
> We expressly acknowledge that FRR binary packages must be distributed in
> their entirety under GPLv2 or newer, and this is what I thought is
> indicated in the Debian package too.

Debian does not attach *any* license to a binary package. It just
documents the licenses of the sources. There is however no way (except
carefully going through the [documented] build process) to find out,
under which conditions a binary files can be used/(re)distributed/modified.

Best

Ole

Re: Does Debian itself have a license?

[Ole Streicher]

Ben Finney  writes:
> My understanding is that the entire operating system is delivered as
> packages, and each package declares its copyright information in its
> ‘/usr/share/doc/$PACKAGENAME/copyright’ document.

This however covers only the *source* of the package, not the binary
packages. There is no way to find out the license of the binary packages
without checking very carefully the sources and the way the package is
created. So, the end user does not know what he is allowed to do with a
certain (binary) Debian software package.

Best

Ole

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

jonathon <jonathon.bl...@gmail.com> 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 typically has a "seat of the brow" component,

At least german copyright requires creativity.

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

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

This is all not artificially selected.

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

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

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Ben Finney <bign...@debian.org> writes:
> Ole Streicher <oleb...@debian.org> 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 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>.

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

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

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

> Therefore the work cannot be in Debian without license conditions that
> satisfy the DFSG.

>> To bring some citations:
>
> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Ben Finney <bign...@debian.org> writes:
> Ole Streicher <oleb...@debian.org> 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), 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.

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Ben Finney <bign...@debian.org> writes:
> Ole Streicher <oleb...@debian.org> 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 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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

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.

> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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.

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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 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 are right here.

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

> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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 observation is an activity, so it cannot
be source code. 

Cheers

Ole

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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

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

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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.
>
> Here it is:
>
> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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
therefore not copyrightable; therefore no license is needed to make use
of it.

Best regards

Ole

Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?

[Ole Streicher]

Mihai Moldovan <io...@ionic.de> writes:
> * On 02/26/2018 10:28 PM, Ole Streicher wrote:
>> The LGPL-2.1 starts with
>> 
>> | Everyone is permitted to copy and distribute verbatim copies
>> | of this license document, but changing it is not allowed.
>> ^^
>> 
>> I am therefore wondering whether the IUPAC/... license text violates
>> itself the LGPL license conditions and cannot be distributed in Debian
>> at all?
>
> IANAL: they have not changed LGPL-2.1, but copied it and released it under a
> different name.

Since the license text itself if copyrighted, its usage (and possible
modification) has to follow the license conditions.

> As far as I understand, it would only be violating LGPL-2.1, if the text was
> changed, but the original name retained (since in such a case, naturally, 
> you'd
> be getting something that isn't LGPL-2.1 under the LGPL-2.1 name).

The license explicitly forbids the change, independent of whether the
result is distributed under the same or under a different name.

Best

Ole

Re: IUPAC/InChI-Trust Licence DFSG-Compliant ?

[Ole Streicher]

Francesco Poli  writes:
> This "IUPAC/InChI-Trust InChI Licence No. 1.0" appears to have been
> created starting from the GNU LGPL v2.1, by the following steps:

The LGPL-2.1 starts with

| Everyone is permitted to copy and distribute verbatim copies
| of this license document, but changing it is not allowed.
^^

I am therefore wondering whether the IUPAC/... license text violates
itself the LGPL license conditions and cannot be distributed in Debian
at all?

Cheers

Ole

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Ole Streicher <oleb...@debian.org> 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
| 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Roberto <robe...@zenvoid.org> 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 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.

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.

> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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

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

> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Roberto <robe...@zenvoid.org> 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
> 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.
>
> [...]

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Roberto <robe...@zenvoid.org> 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.
>
> 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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

Roberto <robe...@zenvoid.org> 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 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.

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

Re: JPL Planetary Ephemeris DE405

[Ole Streicher]

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

Hibby  writes:
> 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

Re: Is there a list contains all debian packages and it's license ?

[Ole Streicher]

Simon McVittie  writes:
> On Sat, 23 Sep 2017 at 10:25:33 +0200, to...@tuxteam.de wrote:
>> Not a readymade solution, but perhaps a lead to follow: package copyright
>> info is supposed to be in a file debian/copyright within the package source
>> archive[1]. I don't know at the moment whether this info percolates to
>> the package binary when building.
>
> It does, and Debian Policy says it must. That information ends up in
> /usr/share/doc/${binary_package}/copyright where ${binary_package} is the
> binary package.

That is so only in theory. In practice, the machine readable copyright
file documents all copyrights of the sources, but does not have a
mechanism to tell which sources are at the end used for a specific
binary. It even documents source files that do not end up in any binary
package at all. And it does not document files that are not in the
source package but affect the copyright (unless one writes that in a
free-form comment).

For example, if you have a source licensed under BSD, and link it to
GPL, the resulting binary must be licensed under GPL (because it is a
derived work in the meaning of the GPL), but this is not documented in
the machine readable source file: there is just no place for such
information.

So, if you want to know, under which license a specific binary is
distributed, the realistic answer is: This is usually undocumented, one
has to check the licenses of the build dependencies, the license of the
source package, and the specific build process. Since build dependencies
are binary packages, this is recursive.

Best regards

Ole

Re: BSD license type?

[Ole Streicher]

Hi Ben,

Ben Finney  writes:
> What purpose would that serve?

Show where it comes from. In the specific case, this is not unimportant,
since from the first reading it looks like a BSD-2-Clause, so the quick
reader may think that I was just not aware of the match and therefore
may take the wrong thing.

> I'm advising to make that much clearer by using a name that (correctly)
> implies a custom license that is not widely known in its effects.

Sorry, but I still find it quite clear that a "simplified-XY" or a
"XY-alike" is *not* XY, but something modified.

Best regards

Ole

Re: BSD license type?

[Ole Streicher]

Ben Finney <bign...@debian.org> writes:
> Ole Streicher <oleb...@debian.org> writes:
>
>> Change from the original BSD-3-Clause is that the originally second
>> condition is merged/simplified with the first, and the third is
>> renamed.
>>
>> What short name should I assign to it?
>
> I would advise that the name should not invite confusion with the
> existing license texts that actually are published prominently for the
> Berkeley Standard Distribution.
>
> In other words, if this is not identical with an existing widely-known
> BSD license text, don't use BSD in the name.
>
> You could instead choose a short name that is specific to that work.
> e.g. “License: CISCO-CSA”.

Wouldn't it be better to show somehow the relationship in the name? IMO
it is already clear that it is not identical to a BSD license if I use a
(slightly) different name, like "Simplified-BSD-3-Clause" or
"BSD-3-Clause-alike".

If the text is identical, one would use the predefined short names;
reversely that means that if it is not a predefined short name, that it
is not the identical text.

Best regards

Ole

BSD license type?

[Ole Streicher]

Hi,

I just stumbled upon a kind-of "simplified BSD-3-Clause", and I am
wondering whether this is a kind of standard one:

--8<-
Copyright (C) 2000-2008 Pavel Sakov and CSIRO

Redistribution and use of material from the package `csa', with or without
modification, are permitted provided that the following conditions are 
met:

   1. Redistributions of material must retain the above copyright notice, this
  list of conditions and the following disclaimer.
   2. The names of the authors may not be used to endorse or promote products
  derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS'' AND ANY EXPRESS OR IMPLIED 
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
--8<-

https://github.com/sakov/csa-c/blob/master/csa/LICENSE

Change from the original BSD-3-Clause is that the originally second
condition is merged/simplified with the first, and the third is renamed.

What short name should I assign to it?

Best regards

Ole

No-Copyright?

[Ole Streicher]

Hi,

one (Java) source file of an ITP package (jcdf) has the following comments:

 * The code for the Huffman and Adaptive Huffman decompressing stream
 * implementations in this class is based on the C implementation in
 * "The Data Compression Book" (Mark Nelson, 1992), via the code
 * in cdfhuff.c from the CDF source distribution.
 *
 * On the topic of intellectual property, Mark Nelson
 * http://marknelson.us/code-use-policy;>says:
 * 
 * It is my intention that anyone who buys the book or magazine be free
 * to use the source code in any form they please. I only request that
 * any use that involves public reproduction include proper attribution.
 * any use that involves public reproduction include proper attribution.
 * I assert that in no case will I initiate or cooperate with any attempt
 * to enforce the copyright on the source code, whether it belongs to me
 * or a publisher.
 * 
 * And I even bought the book (MBT).

https://anonscm.debian.org/cgit/debian-astro/packages/jcdf.git/tree/BitExpandInputStream.java

What is this? No-enforce-copyright with an attribution requirement?
Upstream itself uses LGPL-3.

Best regards

Ole

Re: Debain licensing

[Ole Streicher]

Ian Jackson  writes:
> Rahul Mohan G writes ("Debain licensing"):
>> Can you please let me know whether this license information is of
>> the original package? If so, what could be the license information
>> of the debian package?
>
> This licence information is of the Debian version of the package.  The
> licence information covers both the licence of the origin package, and
> of the Debian modifications (and the Debian packaging additions).

For the binary package, there is however a danger that comes with its
(build) dependencies: For example, if you have a package with an
executable that is linked to a GPL library, then the resulting program
is a dervived work according to the GPL and therefore it must be
licensed under GPL as well. 

Generally, there is no simple way to get the correct license of a
binary package.

Best regards

Ole

Re: [Individual|Corporate] Contributor License Agreement

[Ole Streicher]

Hi Frederic,

these agreements seem to cover how one may contribute the code back
upstream. I think that upstream is free to put any rules here -- there
are upstreams that completely reject outside contributions, and other
require a transfer of the copyright. Everyting is fine here.

So, I would not see any reason why these rules would make the license
non-DFSG.

Cheers

Ole

Frederic Bonnard  writes:
> Hi everybody,
> I'm wondering if an agreement meets the DFSG during the packaging
> process of a library called libvecpf. It's under GPLv2.1+ but there are
> 2 additional files which are agreements.
> Depending if you are an individual contributor or a corporate one :
> - https://github.com/Libvecpf/libvecpf/blob/master/ICLA.txt
> - https://github.com/Libvecpf/libvecpf/blob/master/CCLA.txt
>
> I see amongst some problems with :
> - contributor must fill, sign and send the agreement
> - reveal his identity
> - notify the Libvecpf Maintainer of any facts or circumstances of which You
>   become aware that would make these representations inaccurate in any 
> respect.
>
> Can anybody confirm those points ? (maybe others ?)
> If so, what could be changed to make it DFSG compliant ?
> Thanks for any help.
> Regards,
>
> F.

Re: Source files

[Ole Streicher]

Ángel González  writes:
> On 15/10/15 00:50, Riley Baird wrote:
>> On Wed, 14 Oct 2015 23:47:02 +0200
>> Francesco Poli  wrote:
>>
>>> The alternatives you propose are vague at best.
>>>
>>> For further details on what I think about the definition of source,
>>> anyone interested may read my essay:
>>> http://www.inventati.org/frx/essays/softfrdm/whatissource.html
>> That's a good essay! Hopefully, something like that will become the
>> reference that Debian actually uses in the future.
> Yes, good work, Francesco.

Yes, this is a nice summary. Thank you very much; would it be possible
to add it somewhere to Debian (Wiki or so?) And (unrelated to Debian)
may it be possible to submit to the FSF for inclusion? It actually would
help much for discussion with some upstream about what they are required
to release.

>> I have some concerns, though:
>>> The preferred form of a work for making modifications to it.
>> This fails to address the issues raised earlier in this thread:
>> What about CVS headers?
> Well, the file with the CVS headers is probably what you would use
> for making modifications.

To actually change the CVS header, "one" (in the definition of Fancescos
FAQ) would prefer to commit the file, which makes this line a
non-source -- here the source is the RCS file in the CVS repository
(which is usually not distributed).

>>> 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.
>> Company A writes a program A* in C++ and gives binaries away under a
>> free license to Person B. Person B has excellent knowledge of how to
>> edit binary executables and changes it to create program B*. It
>> would follow that the binary executable
>> is source.
> Yes. The source for B* is the binary. The source for A* is the C++ files.
> (I added the names above for clarification)
>
> However, that shouldn't lead to the that compiling a program and
> changing two bytes with an hex editor makes the original files no
> longer be “source”.
> In most cases, we should also look at the source of A* when working
> with B*, at least if B* is expected to be free software.

Changing generated files is not so rare and IMO would really cause a
problem. I have a case, where the file still has the header "This file
is generated! Do not edit!" but was edited by upstream, and I am afraid
that this will cause "some" confusion when I upload it to NEW.

>>> One completely different thing is when nobody has some form of
>>> the work any longer. That form cannot be preferred for making
>>> modifications, since it no longer exists. In this case, the actual
>>> source is the preferred form for making modifications, among the
>>> existing ones.
>> I write a program in C++ and release the binaries under a free license.
>> The binaries are not the source form. But five years later, when I lose
>> the USB which contained the only copy of the C++ code, the binaries
>> become source.
> I'm most worried about authors falsely claiming «I lost the source» as
> an excuse for not disclosing them.

Often one sees whether a file is re-generated in the next release or if
it was edited by hand, which would then prove of disprove the author's
claim. I would, however, extend the group who needs "prefers" the
current form of a file towards "the author and other people with enough
knowledge".

I still think that the definition given there is not applicable to data
(the photography example there), but this is a different story.

Best regards

Ole

Re: Source files

[Ole Streicher]

Am 13.10.2015 um 22:23 schrieb Walter Landry:
> Ole Streicher <oleb...@debian.org> wrote:
>> Walter Landry <wlan...@caltech.edu> writes:
>>> Ole Streicher <oleb...@debian.org> wrote:
>>>> What are the general guidelines here? Somewhere in written form? The
>>>> DFSG does not contain a hint here.
>>> The rule of thumb that I have seen applied is that 'source' is the
>>> preferred form of modification for the people making modifications.
>>> If a person really prefers editing 1400 character lines, then that is
>>> the source.  However, you can not just state that you prefer that.
>> I'd prefer just to ignore the line: it is a comment line that is not
>> needed for the functionality, so I see no reason to touch it at all. The
>> only reason to touch it for me would be to delete it.
> Sorry, I had not noticed that it was a comment.  I am confused as to
> why it is there.  Do you know why?  Could you get upstream to delete
> this seemingly useless line?  That would solve your immediate problem
> and clean up the code.

Upstream included the code on my request as an external source. I think
it would be not a good idea to ask them for the removal of the line,
since then their version would deviate from the original source.

I am not a specialist at all for Javascript, and all I try is just to
keep a Python package (with a very responsive upstream!) in a good
shape. Unfortunately, nobody with Javascript experience and also nobody
from the Lintian team (who wrote the heuristics to identify this file as
non-source, and also underlined that they still claim the file to be
non-source) took part in the discussion here so far. It looks a bit
weird for me that they create a Lintian "error" and seem not to have a
(even preliminary and discussable) "source" definition. So, I think that
the lintian tag in question is more a "wild guess" and should be marked
as such.

Best regards

Ole

Re: Source files

[Ole Streicher]

On 14.10.2015 10:35, Bastien Roucaries wrote:

Le 14 octobre 2015 08:51:16 GMT+02:00, Ole Streicher <oleb...@debian.org> a 
écrit :

I am not a specialist at all for Javascript, and all I try is just
to keep a Python package (with a very responsive upstream!) in a
good shape. Unfortunately, nobody with Javascript experience and
also nobody from the Lintian team (who wrote the heuristics to
identify this file as non-source, and also underlined that they
still claim the file to be non-source) took part in the discussion
here so far. It looks a bit weird for me that they create a Lintian
"error" and seem not to have a (even preliminary and discussable)
"source" definition. So, I think that the lintian tag in question
is more a "wild guess" and should be marked as such.


Next Lintian version will count ; and ne more clever.

However line > 512 will be tagged due to regex récursion problèm and
it is totally insane.


What I meant here is that you should explain a bit what you consider a 
source and what not -- here for the discussion, and in the lintian tag 
documentation for the help of the users. Just experimenting some random 
heuristics without a proper definition (at least a working one) is not 
enough to qualify the tag for something other than "experimental", IMO.


Best regards

Ole

Re: Source files

[Ole Streicher]

Ben Finney <ben+deb...@benfinney.id.au> writes:
> Ole Streicher <oleb...@debian.org> writes:
>> However, it contains one line
>> /*globals $, jQuery,define,_fnExternApiFunc,[...]
>> which is ~1400 characters long and may be automatically inserted.
>
> I would say the test of whether a file is source is whether it can be
> described as “the preferred form of the work for making modifications to
> it”.
>
> If the preferred form for making modifications is to edit some *other*
> file, then re-generate, the generated file is no IMO source for the
> purpose of the DFSG.

This is the case for the CVS/RCS $ Id: $ line, which is actually
generated by committing the edited file to an RCS (,v) file (which is
/different/ from the actual file).

>> The "preferred" in the definition is a bit ambitious -- some people
>> may prefer a different form than others.
>
> Do you mean “ambiguous”? If so, I agree. But that ambiguity does not
> prevent the definition from being quite useful for deciding cases like
> this.

I meant ambigous, sorry. In this case (as in the case of the CVS/RCS Id
line), it is not helping, since some people may prefer not to edit this
line at all: I f.e. would just ignore the line in the Javascript
source, since it does not have a functional influence, and I do not care
about the line at all. Others would like to keep the consistency, as I
would like to do in the case of the CVS/RCS Id. Who is right then?

>> If someone copies a files from somewhere else, and then patches is to
>> fits the local needs: Is the patched file a "source"?
>
> Patching results in a *different* work (and, according to your described
> provenance, the patches result in a derived work of the prior one).
>
> Is the resulting file still one which would be preferred for making
> modifications to that new work?

Not in all cases. One use case would be to bring the file in sync with
the current developments of the original file. For this, I would prefer
patches instead of just the changed file.

> If so, that file is the source for whatever automatically-generated
> form of the work (e.g. compiled binaries) they then produce from that
> source.

The example is not about whether the changes were made manually or
automatically, but about what is preferred to work with. And there are
use cases which would require to have the patches separated (being them
manually generated or not), so by the GPL definition the patched file is
not a source.

>> Someone would probably prefer to have the original file and the patch
>> instead
>
> That would not be the source form of the later (derived) work. You have
> created, in this scenario, two separate works, each of which has a
> distinct source form.

Anyway, I have a use case for the derived work where I would prefer to
have the modifications in form of patches -- which makes the derived
work itself a non-source (since for this use case it is not the
preferred form of modification).

>> What are the general guidelines here? Somewhere in written form? The
>> DFSG does not contain a hint here.
>
> You're right. They're guidelines, and (as you know) the DFSG doesn't
> actually refer to the GPL's definition of source.
>
> The current state of copyright law doesn't allow firm, clearly-defined
> specifications of what is or is not legal; the law is in many ways
> incoherent from a logical perspective.

The question here is not about what is legal, but about what we accept
in Debian. If a file is licenses by BSD, it does not matter whether it
complies to a specific "source" definition to obey this copyright.

Best regards

Ole

Re: Source files

[Ole Streicher]

Walter Landry <wlan...@caltech.edu> writes:
> Ole Streicher <oleb...@debian.org> wrote:
>> What are the general guidelines here? Somewhere in written form? The
>> DFSG does not contain a hint here.
>
> The rule of thumb that I have seen applied is that 'source' is the
> preferred form of modification for the people making modifications.
> If a person really prefers editing 1400 character lines, then that is
> the source.  However, you can not just state that you prefer that.

I'd prefer just to ignore the line: it is a comment line that is not
needed for the functionality, so I see no reason to touch it at all. The
only reason to touch it for me would be to delete it.

> So if a file is generated mechanically, whatever scripts that generate
> the file are the 'source'.  However, if someone actually edited the
> 1400 character line, then it could become 'source'.

Similarly, one could patch a binary executable with a  hex editor :-)

> I have not seen the example of CVS status lines before.  I think
> Debian generally ignores that kind of technical violation because
>
> 1) CVS is free software
> 2) Those lines are not critical to functionality.
> 3) The lines are very short and not difficult to modify.

If you want to keep consistency, it is actually difficult to impossible:
The $ Id: $ line is created from the RCS file from the CVS server which
is usually missing in the sources. Generally, one would "prefer" not to
touch this line at all, but to interact with the CVS server -- which is
not possible since the CVS tree is not included.

So, there is no difference to the long line from the questioned file:
without keeping consistency, editing is simple (and both have no
influence on the functionality), but if you want to keep the consistency
(and some people would *prefer* that), it is difficult to impossible.

So, strictly speaking, CVS (or RCS, or SVN) autogenerated lines are not
source and should not exist in Debian sources, right?

Best regards

Ole

Re: Source files

[Ole Streicher]

Charles Plessy  writes:
> Maybe the long line was machine-generated at the beginning, but it does not
> matter anymore.

Why not? If I take the GPL definition, the question is not whether it is
actual (and, BTW, also not whether it is automatically generated) but
what "is preferred" (holy passive) for modification.

> And by the way, while anybody is free to disbelieve that a file is a real
> source file, the only persons whose judgement really matter on that subject 
> are
> the members of the FTP team.

I would guess that the FTP team should have guidelines here, which would
be nice to presented in this discussion.

> So you are free to disagree with random bug reporters, and they are
> free to escalate it if they are not convinced by your arguments,

 which is one of the purposes of this discussion.

> but in the meantime, Debian's point of view is that the file is source
> unless the contrary has been demonstrated, given that it has passed
> the screening of the FTP team when it entered our archive.  You can
> also add Lintian overrides if the Lintian maintainers are uncooperative.

Sure. Actually, I added an overrides here. However, lintian sets some
standards, and they need to be discussed.

Best regards

Ole

Source files

[Ole Streicher]

Hi,

For one of my packages (python-astropy), I got a Lintian error that it
would contain a non-source file jquery.dataTables.js. This is mainly
discussed in a bug report

https://bugs.debian.org/798900

however it seems that the problem is more general. The python-astropy
package indeed contains a file jquery.dataTables.js, which for me,
however, looks like a good source: It is well readable, it contains
comments, etc.:

https://sources.debian.net/src/python-astropy/1.0.4-1/astropy/extern/js/jquery.dataTables.js/

However, it contains one line

/*globals $, jQuery,define,_fnExternApiFunc,[...]

which is ~1400 characters long and may be automatically inserted. This
line is now taken by lintian as indication that the file is not a source
file. Aside from the question whether this heuristics is too simple, I
am now curious on how a "source" is defined in the Debian context. Is it
f.e. required that every single character was inserted manually? Or that
at least some of the content was created manually?

Is it acceptable that a line (or several lines) are automatically
handled by the editor (Emacs could do that, f.e.)?

Is it acceptable that a line (or several lines) are handled by external
scripts? What about the signature lines, for example in
debian/changelog? They are usually handled by dch, not by a human -- are
they to be considered as non-source?

What about lines that hare handled by CVS? 

/* $Id: capi.h,v 1.4.6.1 2001/09/23 22:25:05 kai Exp $

is obviously not added manually.

Can a generated file be a source at all?

The only definition I know about what is a source is from GPL:

| The “source code” for a work means the preferred form of the work for
| making modifications to it.

This says nothing about manually created or generated.

The "preferred" in the definition is a bit ambitious -- some people may
prefer a different form than others. And, autogenerated lines (like the
CVS Id, or the signature in debian/changelog) are preferred not not be
changed at all by a third party. Would that make these files non-source?

If someone copies a files from somewhere else, and then patches is to
fits the local needs: Is the patched file a "source"? Someone would
probably prefer to have the original file and the patch instead -- or at
least the source file additionally to the patched one. I have, however,
a few packages which contain a modified file, and where the original one
is not available anymore (since it is >15 years old). At least, I would
strongly prefer to have this in the form "original file + patch", since
then I could see what was changed, and possibly replace these files with
the package where they come from, or at least update them to the current
version. Are these modified files to be considered as non-source, and
therefore the package undistributable?

Finally the question is how one can decide whether a file is "source":
Even if it is completely autogenerated, if the maintainer finds the file
as usable for modifications, why should it then not be marked as
"source"? Shall he hunt of whether a piece of code was inserted by a
non-human? Shall he require that all original (unchanged) files are
included as well?

What are the general guidelines here? Somewhere in written form? The
DFSG does not contain a hint here.

Best regards

Ole

Re: How to free US governmental code

[Ole Streicher]

Walter Landry wlan...@caltech.edu writes:
 Ole Streicher oleb...@debian.org wrote:
 | Copyright 1992, The Regents of the University of California. This
 | software was produced under U.S. Government contract (W-7405-ENG-36)
 | by Los Alamos National Laboratory, which is operated by the University
 | of California for the U.S. Department of Energy. The U.S. Government
 | is licensed to use, reproduce, and distribute this software. Neither
 | the Government nor the University makes any warranty, express or
 | implied, or assumes any liability or responsibility for the use of
 | this software.
 What are the experiences with this kind of copyright: are there any
 chances to make it free?

 Looking around the ftp site
   http://idlastro.gsfc.nasa.gov/ftp/
 there is a top level file LICENSE dated 2014 that looks like a
 simple BSD license for Wayne Landsman. 

As far as I understand the history of idlastro, Wayne collected parts of
the lib from other sources, and I am afraid that he did not really take
care of the individual license of each file he touched and included.
Otherwise he probably would have changed the license statement to BSD.

 Since Wayne is also listed as a contributor to eqpole_grid.pro, he
 should be sympathetic to relicensing.  A Google search for Wayne
 Landsman Astronomy turns up a likely contact at GSFC.  You should ask
 Wayne directly.  He would then contact the legal department at UC,
 though that would involve some work on his end.

I asked him, and I also found the (probable) original author and
contacted him.

 Also, are you planning on distributing
   http://idlastro.gsfc.nasa.gov/ftp/pro/misc/blkshift.pro
 That and a few other files have a non-commercial use license.

Yes, but they look much less formal -- One author made already parts of
his software free (mpfit: under a non-standard ISC-alike license), and
the other already responded that he will help me to get his sources
free. The license above was just the one where I didn't know what to do
best.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytz7fqmk3dl@news.ole.ath.cx

How to free US governmental code

[Ole Streicher]

Hi,

In one of the packages I am currently working on (idlastro [1]), some
files have the following license [2]:

| Copyright 1992, The Regents of the University of California. This
| software was produced under U.S. Government contract (W-7405-ENG-36)
| by Los Alamos National Laboratory, which is operated by the University
| of California for the U.S. Department of Energy. The U.S. Government
| is licensed to use, reproduce, and distribute this software. Neither
| the Government nor the University makes any warranty, express or
| implied, or assumes any liability or responsibility for the use of
| this software.

Surely, this makes the code non-free. However, I have no idea whom to
ask to change to license to something DFGS-compatible.

What are the experiences with this kind of copyright: are there any
chances to make it free?

Best regards

Ole

[1] http://idlastro.gsfc.nasa.gov/
[2] http://idlastro.gsfc.nasa.gov/ftp/pro/astro/eqpole_grid.pro


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzk2umkj26@news.ole.ath.cx

Re: GPL + question

[Ole Streicher]

Charles Plessy ple...@debian.org writes:
 If it were me, I would give the benefit of the doubt to the upstream
 author of missfits, and trust him that if he added a GPLv3+ header, it
 is because he modified the files, as he says in the README.

When I adopted the first package from this author (sextractor), I asked
him per E-mail about this subdirectory -- more since a newer version of
the library in question (wcslib) is already in Debian, and I wanted to
avoid using a convienience copy. He convinced me then that his version
is slightly changed and therefore not just linkable with the original.

I didn't ask for his other packages (missfits, scamp, swarp, psfex; some
of them are already in Debian, others are now in NEW), but since they
all follow the same structure, I am quite sure that his arguments are
valid there as well.

 In that case, the license to be indicated in debian/copyright should
 be GPLv3+.

I re-uploaded the package with a (hopefully) clarifying comment in
debian/copyright; let's see how he decides now.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9quebju@debian.org

GPL + question

[Ole Streicher]

Hi,

I just had a discussion with an ftp-master who rejected one of my
packages. The package in question is missfits. It contains a
directory, src/wcs/ with files that were originally released by Mark
Calabretta under LGPL-2+, but changed by the upstream author (Emmanuel
Bertin) and released in the package under GPL-3+.

debian/copyright currently mentions only GPL-3+ for the whole package.

The ftp-master now asked me to add GPL-2+ for these files to
debian/copyright. But I think that this would be wrong, since the files
under src/wcs are not distributable under GPL-2+ (because they contain
GPL-3+ code from Emmanuel Bertin).

Do I miss an important point here?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzmw0nn8jn@news.ole.ath.cx

Re: GPL + question

[Ole Streicher]

Maximilian maximil...@actoflaw.co.uk writes:
 and this seems to imply that the end user can choose which licence
 suits them.

Not only the end user -- also (in our case) the upstream author. So, he
can choose to redistribute the files under GPL-3+. Being them modified
or not.

 However, if Emmanuel Bertin's code is specifically licensed as GPLv3
 only then it needs to be made clear that this is the case where
 applicable - the fact that this code is GPLv3 only ought not affect
 the fact that the other original files may be GPLv2+.

True. However, the original files are not in the upstream tarball and
therefore do not need to be documented in debian/copyright.

This is even the case if original and redistributed filed differ only by
their license.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytza8wnmsm1@news.ole.ath.cx

Re: GPL + question

[Ole Streicher]

Paul Tagliamonte paul...@debian.org writes:
 On Fri, May 29, 2015 at 09:32:12AM +0200, Ole Streicher wrote:
 Hi,
 
 I just had a discussion with an ftp-master who rejected one of my
 packages. The package in question is missfits. It contains a
 directory, src/wcs/ with files that were originally released by Mark
 Calabretta under LGPL-2+, but changed by the upstream author (Emmanuel
 Bertin) and released in the package under GPL-3+.

 Upstream authors can't change licensing of any files, under any
 conditions, ever.

Generally spoken, this is wrong (or please point me to the source). For
example, I can give you a file saying do what you want with it, then
this is the license.

However, do what you want with it includes that you can republish the
file as GPL.

For GPL. GPL-2+ contains a statement

| you can redistribute it and/or modify it under the terms of the GNU
| General Public License as published by the Free Software Foundation;
| either version 2 of the License, or (at your option) any later
| version.

which means: the upstream author is allowed to redistribute the (changed
or even unchanged) files under version 2, or also under version 3.

Since he redistributed them under version 3 or later, the license of
these files is GPL-3+. The statement above explicitely allows him to do
so.

 If I say a file is GPLv2+, it is forever GPLv2+

Could you strengthen this with a reference?

 even if it's combined with a GPLv3 work, in that case the *files* are
 still GPLv2+,

The files are modified. The author of the modification applied GPL-3+ to
the changed file. He has the right to do so (see above), and since
original and change are glued together (neither the change nor the
original are separately distributed by upstream), the modified file
cannot be distributed by GPL-2 anymore.

 debian/copyright currently mentions only GPL-3+ for the whole package.

 Yeah, debian/copyright isn't what the binary is distributed under, it's
 what the source licenses are.

I speak about sources.

 The ftp-master now asked me to add GPL-2+ for these files to
 debian/copyright. But I think that this would be wrong, since the files
 under src/wcs are not distributable under GPL-2+ (because they contain
 GPL-3+ code from Emmanuel Bertin).

 Nah, it's wrong because you said LGPLv2+, adding it sounds right.

It is wrong. The files in src/wcs are not distributable under GPL-2,
since they contain changes that are GPL-3+.

 Only the copyright holder can change what a *work* is licensed as.
 Anyone can distribute a derived work inline witht he terms of their
 license. That may also contains other terms as well.

If the original license allows, then anyone can redistribute the files
under a different license. And (L)GPL has a paragraph that allows this
under certain conditions (namely LGPL - GPL, and version upgrades).

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytziobbmtsw@news.ole.ath.cx

Re: GPL + question

[Ole Streicher]

Paul Tagliamonte paul...@debian.org writes:
 On Fri, May 29, 2015 at 10:41:58PM +1000, Riley Baird wrote:
 But there are multiple works being combined into the one file. So some
 parts of the file are GPLv2+ and other parts of the file are GPLv3. The
 file as a whole can only be distributed under GPLv3.
 I don't see the point in adding LGPL, *IFF* the works *ARE* modified
 and derived works. Not just straight copy-paste. I'd be interested
 in what changes took place, I don't see any marking of it.

Same for me. However: the (L)GPL allows even an unmodified
redistribution under a later license. It is up to upstream to decide
whether he chooses the original or a later one. And since I take these
files from upstream, not from the original author, I am bound to his
decision, independently whether the files are modified or not.

Therefore, if he chooses to redistribute the files in src/wcs/ under
GPL-3+, than this is the license for these file, and it should be
documented as such under debian/copyright. And in this case, the
redistribution under a GPL-3+ is clear (by adding the according
statement to the file headers).

 This doesn't appear to be the case, this looks like LGPLv2.1+ files were
 modified by someone licensing their changes under GPLv3+, which is
 legit. I believe treating this file as GPLv3+ is fine / good enough.

The reason here is not modification (although it makes this case clear),
but redistribution. Upstream has chosen to redistribute the files under
GPL-3+, and if we want to use these files, we have to respect this.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytzeglzmsxd@news.ole.ath.cx

Re: GPL + question

[Ole Streicher]

Paul Tagliamonte paul...@debian.org writes:
 No, you may redistribute it under different terms, *not* relicense. You may
 *use* GPLv2+ as GPLv3+, *BUT* the original work is *STILL* GPLv2+, since
 you can't relicense works.

Sorry, but I still think release under the terms of the General Public
License v3+ means that the file has the license GPLv3+.

 To relicense implies you hold copyright, since only the copyright
 holder can license their works, even copylefted works.

Again: please provide a reference for this. The copyright holder has
surely the initial right to license his work, but I don't see a reason
why he can't transfer this.

It is also wrong for the changed case that we have: If only the
copyright holder (Mark Calabretta) had the right to change the license,
then the files in question could not have been modified and distributed
under the GPL-3+ license by the upstream author (Emmanuel Bertin) --
since even the modified files are still copyrighted by Mark, so the
Emmanuel alone could not change their license. This is, however, against
the idea of the + in the GPL versions.

Therefore, please show a proof that only the copyright holder can change
the license.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twuve7vz@debian.org

Re: GPL + question

[Ole Streicher]

Miriam Ruiz mir...@debian.org writes:
 So in my opinion, if you modify a code which was released under GPL2+
 and you license your modifications as GPL3+, the resulting work has to
 also be GPL, and the terms or conditions that apply are those of the
 version 3 of the lincense, or later, but you're not effectively
 relicensing the code that is not yours, so that part would be still
 licensed as GPL2+ by the author and copyright holder.

I may give to others the permission to use the modified/redistributed
file under GPL-3+. This permission is what is usually called License.

In that sense, the license is changed.

 So if you later removed the part of code that was covered by a
 different license, the resulting code would be still under the
 original license,

The license is usually granted to a file as a whole, not to specific
lines. If got got a changed file from me, and you revert my changes,
then you are still bound to the conditions that we agreed about when you
got the file -- these conditions are the license. If we agreed on
GPL-3, then you are bound to GPL-3.

 because you were never the copyright holder, and you never had
 permission to relicense it. I seriously doubt that any judge would
 rule otherwise.

Just again this example:

http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/msg.h

This is a file that is initially copyrighted by Daniel Boulet (and
licensed under BSD-2-Clause). However, without any other change, it also
has the header

| Copyright (c) 2000-2007 Apple Inc. All rights reserved.
| [...]
| This file contains Original Code and/or Modifications of Original Code
| as defined in and that are subject to the Apple Public Source License
| Version 2.0 (the 'License'). You may not use this file except [...]

So, Apple puts another license to this file, probably without having the
permission of Daniel Boulet.

Would you accept such a file in Debian? It is clearly not BSD-licensed,
even if an unchanged BSD-licensed version exists.

When trusting the Apple Lawyers a bit, then this contradicts your
argumentation.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87pp5je701@debian.org

Re: GPL + question

[Ole Streicher]

Paul Tagliamonte paul...@debian.org writes:
 I don't know any jurisdiction where I can take a work of yours and now
 claim I have the rights to it under a different license.

Apple did, as I have shown. I think they have good lawyers.

Best

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhg7e6ee@debian.org

Re: GPL + question

[Ole Streicher]

Paul Tagliamonte paul...@debian.org writes:
 On Fri, May 29, 2015 at 03:09:34PM +0200, Ole Streicher wrote:
 Same for me. However: the (L)GPL allows even an unmodified
 redistribution under a later license.
 This is key -- redistribution. It doesn't change the license.

It does. Just look into the license (resp. the header, for simplicity):

| you can redistribute it and/or modify it under the terms of the GNU
| General Public License as published by the Free Software Foundation;
| either version 2 of the License, or (at your option) any later version.

So, redistribution may change the license.

 If I get this file after you say it's GPLv3, it's still LGPLv2.1+ to
 me if I remove it from other works that change the distribution terms

No: We got the files from upstream, and upstream granted us certain
permissions for them (this is what the license actually does). Then we
are bound to this conditions.

We could, ofcourse, get the same files from somewhere else (f.e. from
the original author), and these files then can be used under his
conditions. But this is a different story.

For example, I can give you a file that I got under MIT license, and ask
you not to distribute this file -- then you are bound to this,
independently whether the file is MIT licensed or not. The only thing
you could to is to take the same file from somewhere else and distribute
that.

Or, as an other example (which is closer to Debian): when I packaged
eso-midas, I found that it contained a file sys/msg.h that is
originally from NetBSD (with the appropriate license). The specific file
in the upstream tarball, however, was relicensed by Apple with the APSL
(DFSG incompatible) [1]. Even if the file was the same as the free
version, I think that I did it right to remove the file from the tarball
and replace it with the original version.

 I originally thought there was a different question being asked; sorry
 about that (the terms used and not looking at the source didn't help :))

In my case, the files are modified; so I think there is no doubt that
the files are under src/wcs are GPL-3+.

 Unmodified, the license of the works is unchanged, even if we
 *distribute* under a different one.

Could you put a reference on this?

Best regards

Ole

[1] http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/msg.h


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ytz617bmq9v@news.ole.ath.cx

How to open-source a program?

[Ole Streicher]

Hi all,

within the number of packages that would be nice to see in Debian, one 
important piece is the program Daophot, written by Peter Stetson. 
Unfortunately, this program is not Open Source yet, but getting its source code 
requires to sign an NDA. The NDA gives as main reason the control over the 
software and the credits.

However, the program is *very* old, and parts of it already leaked out 
(rewritten in other programming languages) in some Open Source packages, 
(astrolib [IDL] and IRAF) -- legally or not.

I asked the author whether the program could be made open source, but he stated 
that the lawyers in Ottawa would forbid him to do so. One would need to query 
the National Research Council in Ottawa, Canada to discuss this.

Has anyone already went through such an exercise and could assist me in writing 
a nice E-mail? Or are there better ways to proceed?

Best regards

Ole

(Sorry for spamming 3 lists: I am not sure where to put this. For the 
discussion, we can restrict to one of them)


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54d5ecfe.1060...@liska.ath.cx

Re: License of binary packages

[Ole Streicher]

Francesco Poli invernom...@paranoici.org writes:
 I am not aware of any update on the matter: I suppose the determination
 of the effective licenses of binary packages is still something to be
 done manually.

 I hope this answers Ole's question, although maybe in a disappointing
 way...

I am not sure if this is legally so simple: As far as I understand
licensing, it is the way to allow others to use the product (sorry for
unprofessional wording here; I am not at all a specialist in that).

That means, that as long as we don't allow someone to use a binary
package, he is neither allowed to copy it, nor to use it in any way. We
(Debian) must grant him some rights.

Currently, I don't see that we do that anywhere. debian/copyright refers
only to sources, not to binaries.

Also, the license of the binary is not (always) an unambigious result of
the source packages: a BSD only licensed source file may also end up in
a GPL licensed binary. or the binary of a GPL-2+ source could itseld
licensed as GPL-3+. Generally, Debian may add additional restrictions to
a binary, as long as they are conform to the source license(s) and the
DFSG. My personal understanding of Debian liberalism is that we don't,
but I couldn't find a definitive statement for that.

So, I think, of we offer binary packages, we must clearly define the
conditions of this offer Otherwise the offer is not (legally) valid. Or
am I too naive here?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx22p51v@news.ole.ath.cx

License of binary packages

[Ole Streicher]

Hi,

I asked this question already some months ago in debian-mentors, but
didn't get an answer:

How is the license of a binary Debian package determined?

The file debian/copyright only contains the license of the sources;
however the binary license may differ -- f.e. when a BSD source is
linked to a GPL library. Also there is usually more than one license
used in the sources.

Since Debian is a binary distribution, I am wondering if there is any
canonical way to get the license of a (binary) package?

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4rfoy8b@news.ole.ath.cx

Name restriction and forced acknowledgement OK?

[Ole Streicher]

Dear list members,

I intent to package the ANSI C library of IAU-SOFA
http://bugs.debian.org/659639, which has a non-usual (?) license
agreement http://www.iausofa.org/tandc.html.

Especially, I worry about two points:

1. Not allowed to use the original names in changed code:
-8-
3. You [...] may [...] adapt its code [...] That portion of your
   distribution that does not consist of intact and unchanged copies of
   SOFA source code files is a derived work that must comply with the
   following requirements:
 [...]
 c. The name(s) of all routine(s) in your derived work shall not
include the prefix iau.
-8-

2. Forced acknowledgement:
-8-
4. In any published work or commercial products which includes results
   achieved by using the SOFA software, you shall acknowledge that the
   SOFA software was used in obtaining those results.
-8-

Are these conditions acceptable to meet the DFSG? Following them in
http://www.debian.org/social_contract, I couldn't find a statement
against it; I just want to be sure.

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f38d588.9000...@liska.ath.cx