Re: Bug#220464: gimp: LZW patent is still valid in Europe and Japan
On Wed, Nov 12, 2003 at 01:57:55PM -0800, Ben Gertzfield wrote:
> Ah. I parsed it as (patents that make their distribution problematic)
> or (other issues that make their distribution problematic).
>
> Maybe we need more operator precedence in English..
>
> In any case, I've brought this up to upstream several times, and each
> time they've given a very uncaring attitude back. I suppose all that we
> can do is to constantly remove the code from the .orig.tar.gz for every
> version for the future, but we need replacement gif and tiff plug-ins.
>
> Still, it's very unclear exactly which countries have to have patents on
> an algorithm to make it go into non-free. Do we care, as a silly
> example, if China or Uzbekistan have patents on printing "Hello,
> world"? Would we have to put GNU hello into non-free because people in
> China then couldn't legally distribute Debian?
I'll give my take on the issue of removing the source code vs patching
it out and then point you to a thread about a year ago about this very
issue and you can read for yourself what the determination was then.
I'll also give some thoughts on dealing with upstream on this issue.
>From the standpoint of patent law, my understanding is that distributing
source code which implements a patented algorithm doesn't violate the
patent. Using that source code to follow that algorithm is (i.e.
compiling, distributing and using the resulting binary). Source code in
and of itself is a description of a method. Patents do not restrict the
dissemnitation of the description of the method. In fact the concept of
the patent is to encourage the dissemnation in exchange for a period of
restricted use.
As a result, it is not necessary to remove the source code from the tar
ball. But rather simply to ensure it is not compiled and used in the
resulting binary. A simple conditional compilation flag (e.g. #ifndef
NOLZW) would be sufficient to avoid the patent issue.
gimp is licensed under the GPL, so the patent poison pill comes into
play here:
"If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations, then
as a consequence you may not distribute the Program at all. For
example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies directly
or indirectly through you, then the only way you could satisfy both it
and this License would be to refrain entirely from distribution of the
Program." - Section 7 of GPL version 2.
While on first glance it would seem that this would require you not to
distribute source code that is encumbered by a patent, I don't think it
really does. It only says if you cannot meet obligations outside of the
license you cannot distribute the program. It does not preclude you
from using your modifcation rights (which the clause doesn't remove from
you) to make the program simply not build that section of code
(conditional compilation).
The question then becomes if the code is free enough to meet the DFSGs.
If this is an issue depends on how you want to interpret the Derived
Works clause.
"The license must allow modifications and derived works, and must allow
them to be distributed under the same terms as the license of the
original software."
The question is, do all possible modifications have to be allowed? If
so a simple modification of turning that code back on would not be
allowed to be distributed under the terms of the GPL and therefore would
mean the license violates the DFSG. Would this be any different from
removing the code and then someone putting it back? I'd guess we have
to accept that some modifications would fall outside the scope of the
license, otherwise we could never accept the GPL (with the poison pill)
as meeting the DFSG.
So in my IANALHO all that is necessary is to modify the app to simply
not build the LZW code. I'm sure someone will disagree with me. The
interpretation of source code in and of itself not violating a patent is
contraversial and untested. If that assumption proves to be wrong all
the rest falls apart and it would be necessary to remove the offending
code completely. So the completely safe thing to do is to remove the
source code, no matter how inconvienient that may be. If it's necessary
is up for debate.
In fact this very issue came up on this list about a year ago:
http://lists.debian.org/debian-legal/2002/debian-legal-200210/msg00244.html
and a related thread:
http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00132.html
The final decision seemed to be it was prudent to remove but unclear if
it was necessary.
As far as dealing with the upstream. I'd say they should do one or both
of the following:
a) Provide a conditional compilation option (configure time) that would
disable the LZW code.
b) Provide a make dist-nolzw that would create a tarball without the
offending code and the conditional compliation option set by default to
avoid any issues with the code being missing.
I can't imagine why they wouldn't accept these improvements if someone
spent the time to submit them and I would imagine it would be beneficial
to the maintainer in the long run to do that.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
Reply to: