Bugzilla Bug 199451

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.