Name restriction and forced acknowledgement OK?

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:

License of binary packages

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

Re: License of binary packages

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

How to open-source a program?

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

GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: GPL + question

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

Re: How to free US governmental code

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

How to free US governmental code

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

Re: Source files

Á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

Re: Source files

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

Re: Source files

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

Source files

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

Re: Source files

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

Re: Source files

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

Re: Source files

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

Re: Debain licensing

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

Re: [Individual|Corporate] Contributor License Agreement

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

No-Copyright?

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

Re: BSD license type?

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

BSD license type?

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

Re: BSD license type?

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

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

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

Re: JPL Planetary Ephemeris DE405

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 dist

Re: JPL Planetary Ephemeris DE405

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 da

Re: JPL Planetary Ephemeris DE405

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 th

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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 a

Re: JPL Planetary Ephemeris DE405

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*

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

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 documen

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

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

Re: Does Debian itself have a license?

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.

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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.

Re: JPL Planetary Ephemeris DE405

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.

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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 wor

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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

Re: JPL Planetary Ephemeris DE405

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.

Re: FRR package in Debian violates the GPL licence

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

Re: FRR package in Debian violates the GPL licence

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 unmod

Re: FRR package in Debian violates the GPL licence

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

Re: FRR package in Debian violates the GPL licence

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 i

Re: FRR package in Debian violates the GPL licence

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 completel

Re: FRR package in Debian violates the GPL licence

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

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

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 &

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

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

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

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

Re: FRR package in Debian violates the GPL licence

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

Re: FRR package in Debian violates the GPL licence

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 &

Re: FRR package in Debian violates the GPL licence

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

Re: FRR package in Debian violates the GPL licence

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 -

Re: FRR package in Debian violates the GPL licence

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 co

Re: MIT Licensed code in LD_PRELOAD?

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?