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 <[EMAIL PROTECTED]> http://ben.reser.org "Conscience is the inner voice which warns us somebody may be looking." - H.L. Mencken
