Most important is the license change to GPL 3, which is proplematic wrt. binary distribution of GPL-2 licensed software linking to it. http://www.gnu.org/software/gsl/NEWS List of packages using it, needing some bindist magic (in case they're GPL-2 licensed): dev-lang/gdl dev-python/pygsl dev-ruby/ruby-gsl mail-filter/bogofilter media-gfx/asymptote media-gfx/kst media-sound/kwave media-sound/snd media-sound/sonik sci-astronomy/orsa sci-calculators/orpie sci-chemistry/coot sci-chemistry/eden sci-libs/itpp sci-mathematics/octave-forge sci-mathematics/pspp sci-physics/root sci-visualization/labplot sci-visualization/qtiplot sci-visualization/spectromatic virtual/cblas
Hi Carlo, Thanks much for the note! I apologize for my ignorance in this matter and I would greatly appreciate if somebody could educate me on what exactly the issue with GPL 3 code linked against GPL 2 code is when it comes to binary distribution. Also, - many sci packages depend on a range of versions of gsl not version 1.10 alone. How do we handle this case? - gsl is one of the providers of virtual/cblas, hence all packages in the tree that require this virtual could potentially link against gsl. Thanks, Markus
Since 1.10 is already in the tree, what is the status of this bug? Should we close it? Should we do something wrt the binary distribution of the packages listed by Carlo?
Sorry, that I didn't reply earlier... (In reply to comment #1) > Thanks much for the note! I apologize for my ignorance in this > matter and I would greatly appreciate if somebody could > educate me on what exactly the issue with GPL 3 code > linked against GPL 2 code is when it comes to binary > distribution. The GPL (2 or 3) allows you to do with the code whatever you want (even link it to some proprietary in-house application), but is far more restrictive wrt. distribution. In the process of reaching compatibilty with some other open source licenses, it was decided to change the GPL 3 in a way so it is incompatible with the GPL 2 and distributing GPL 2 and 3 code linked together is therefore a license violation. See http://www.gnu.org/licenses/licenses.html for more information. There are lots of open source licenses incompatible with either the GPL 2 or both GPL 2 and 3, e.g. Apache, MPL and their derivates, I(BM)PL, CPL - even the dead old incompatible four clause BSD license you'll sometimes find in code where you didn't expect it. > Also, > > - many sci packages depend on a range of versions of gsl not version > 1.10 alone. How do we handle this case? A possibility is bindist? ( sci-libs/gsl ) ! bindist? ( <sci-libs/gsl-1.10 ) and keep 1.9 around as long as there are GPL 2 licensed applications linking to it, in the tree. You could also try to convince the authors of gsl to switch to LGPL 3, which is a good idea for widely used libraries anyways and would spare us a lot of work. > - gsl is one of the providers of virtual/cblas, hence all packages in the > tree that require this virtual could potentially link against gsl. So we have to look at them, too. (In reply to comment #2) > Since 1.10 is already in the tree, what is the status of this bug? Should we > close it? Should we do something wrt the binary distribution of the packages > listed by Carlo? As distributors we have the responsibililty to abide to the licenses of code we make accessable, more than everyone else, I'd say. We might even run into distributing a live cd, infringing a license ourselves, when we don't take it seriously to assure some safety in this regard for whoever actually wants to distribute binaries based on Gentoo. This is annoying, but not optional stuff, I'm afraid.
Eh, the example should of course be DEPEND="!bindist? ( sci-libs/gsl ) bindist? ( <sci-libs/gsl-1.10 )"
Uh, I have to correct myself wrt. asking the authors of gsl to use the LGPL 3. From gnu.org: > Please note that LGPLv3 is not compatible with GPLv2 by itself. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well. When this is the case, you can use the code under GPLv3 to make the desired combination. Unfortunatly we do not even distinct between "GPL 2" and "GPL 2 and later" in our lisence handling. There was even a thread on gentoo-dev once, iirc, but nothing happened.
Here's some intial progress 1) sci-libs/itpp Most recent version in portage does not depend on gsl any more. 2) sci-mathematics/octave-forge The part of octave-forge that needs gsl will soon be replaced by octave-forge-gsl which is GPL-2 or later. So we we can drop this one. 3) sci-mathematics/pspp Fixed by adding bindist magic. Thanks, Markus
Some more notes: 1) sci-physics/root: root is LGPL-2.1 hence we should be fine 2) sci-vizualisation/labplot: has bindist Thanks, Markus
sci-visualization/qtiplot sci-visualization/spectromatic now both have bindist. Currently, we are left with dev-lang/gdl dev-python/pygsl dev-ruby/ruby-gsl mail-filter/bogofilter media-gfx/asymptote media-gfx/kst media-sound/kwave media-sound/snd media-sound/sonik sci-astronomy/orsa sci-calculators/orpie sci-chemistry/coot sci-chemistry/eden virtual/cblas Markus
* sci-astronomy/orsa Is licensed GPL-2 or later, so we should be fine. * sci-calculators/orpie * sci-chemistry/eden added bindist
dev-python/pygsl dev-ruby/ruby-gsl media-gfx/kst media-sound/kwave media-sound/sound are checked and fine, so we're down to dev-lang/gdl mail-filter/bogofilter media-gfx/asymptote media-sound/snd sci-chemistry/coot virtual/cblas
dev-lang/gdl mail-filter/bogofilter media-gfx/asymptote (now gpl-3) sci-chemistry/coot (now gpl-3) should be fine. > media-sound/snd > virtual/cblas not sure what to do with these two. Do we really need to do this? Many other libs are switching to gpl-3 and may have similar issues. Reading license changes and fixing compatibilities is very boring. Also, gsl-1.9 may be buggy (bug #260851) with gcc-4.3, fixed in later versions.
I guess qtiplot (at least version 0.9.7.11) is unaffected. Although source tarbal include GPL-2 text, sources I've checked are marked with: * This program is free software; 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. * Also qtiplot/src/lib (at least now) has gpl-3.0.txt (I'll add to licenses with bump). So... with qtiplot 0.9.7.11 I'm going to drop bindist.
removed from tree.
Are there still some open or could this bug be closed?
Has anybody managed to emerge Coot? I´ve reported a bug in guile-lib, which is a Coot dependency. Has the gentoo-science herd died?
(In reply to comment #15) > Has anybody managed to emerge Coot? I´ve reported a bug in guile-lib, which is > a Coot dependency. Has the gentoo-science herd died? What ever your problem is, you just reported the guile lib bug and it is not reproducible here. And it doesn't has to do something with licenses. If you have more problems with packages, please file bugs. BTW coot emerges fine.
BTW did we fix all licenses?
Please reopen if there are still packages missing.
