[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

License compatibility with GPLv3


I have some small problem with Gnash that might be extensible to other
packages, so I'm asking here to find out if anyone else has had that
problem too and how did they manage it.

Gnash is GNU's free Flash player. It is now licensed under GPLv3 (it
was previously GPLv2 or above). It has a really huge list of build

dpkg-dev (>= 1.13.19), debhelper (>= 4.0.0), quilt, autoconf, dh-buildinfo,
automake1.9 | automake, libtool, libltdl3-dev, help2man, libxmu-dev, dejagnu,
autotools-dev, libboost-dev, libboost-thread-dev, libxml2-dev, libjpeg-dev,
libpng12-dev | libpng-dev, libagg-dev, libgstreamer0.10-dev, libkonq4-dev,
libpango1.0-dev | pango-devel, libgtkglext1-dev, libmad0-dev, libdirectfb-dev,
libcurl4-gnutls-dev | libcurl3-gnutls-dev | libcurl4-openssl-dev |
libcaca-dev, libboost-date-time-dev, libavcodec-dev, libavformat-dev,
libming-util, mtasc, libgstreamer-plugins-base0.10-dev,
libboost-serialization-dev, python, base-files (>= 4.0.1)

All these dependencies already have their own list of dependencies
too, right now I'm concerned about libkonq4-dev and Qt being GPLv2
only. Even though all of these packages might be GPLv3 compatible, it
is not guaranteed that their dependencies are, like:

Package A (GPLv3) depends on package B (GPLv2 or above)
Package B (GPLv2 or above) depends on package C (GPLv2 only)

Both dependencies would be OK on their own, but I'd be effectively
linking A (GPLv3) with C (GPLv2 only) which are not compatible.

As you can imagine, the work of checking all the dependencies by hand
would be enormous. I could check the dependencies of the resulting
binary packages instead, but I'm not sure if that would be enough (or
I should check their dependencies too), would it be?

Any ideas?


Reply to: