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

Re: hypothitical nonfree question



>>>>> "Fabrice" == Fabrice Gautier <gautier@email.enst.fr> writes:

Thanks for your inputs. I have been hired to fix up software in order
to make in releasable to the public under a non-free license ("so
nobody can profit from our work"), but I suspect the authors may not
understand the restrictions that are in the GPL license.

However, I don't want to upset anybody, but I want to get my facts as
clear as possible (ie. as clear as mud <grin>) before I confront the
authors. Hence, I don't wont to directly connect the name of
functionality of the program with this discussion. (the same problem
could potentially occur elsewhere to).
 
    Fabrice> Imagine if gnupg was composed of a GPL library and a
    Fabrice> command line frontend. You would probably like to use the
    Fabrice> library directly, but you won't be able under the GPL
    Fabrice> terms. You could see the Vidomi/VirtualDub case as an
    Fabrice> example of the complexity of the problem.

That was my opinion too, although I suspect it will be a very
controversial point.

>>>>> "Ethan" == Ethan Benson <erbenson@alaska.net> writes:

    Ethan> only if the patch is GPLed in its entirety. or well its a
    Ethan> bit more complicated, if your not distributing gnupg with
    Ethan> the patch your fine there, but if the patch is not GPLed it
    Ethan> can't be used without violating the GPL.  Some think you
    Ethan> can get around this by making the user do all the patching,
    Ethan> building and violating themselves in which case so long as
    Ethan> they never distribute the result there probably isn't a
    Ethan> problem, but this violates the spirit of the GPL and may
    Ethan> not really be allowable anyway.

    Ethan> regardless it would be a very obnoxious thing to do since
    Ethan> even if one didn't have a problem with using the non-free X
    Ethan> (thats confusing...)  it would be a pain in the arse for
    Ethan> them to do so since they either have to figure out how to
    Ethan> build a local patched version of gnupg.deb, and do that
    Ethan> every time there is an update, or give up debian packaging
    Ethan> and install gnupg in /usr/local.  both are rather annoying

Not only that, but I forgot something: the patched version of gnupg
requires a *.a library from the non-free program X! Although there are
plans to split up the library into a separate source *.tar.gz file, so
it could potentially have a different license.

    Ethan> and inconvenient.  it would be better for all to release
    Ethan> the patch as GPL and get it merged upstream (assuming its
    Ethan> useful for other things then this non-free program).

The patch in question probably wouldn't be useful elsewhere, but if
this program was GPLed I would consider sending the patches upstream
all the same.

So I will just tell the authors, in a tactful way, that while some
people might disagree, the general feeling is that:

a) program X (including patches) is a derivative work of the GPLed
program.

b) The GPL prevents any derivative work to from containing more
restrictions.

c) that if they license the program under the GPL, I think it still
prevents anybody profiting from their work, eg. because of (b)
above. What other reasons can I provide?
-- 
Brian May <bam@debian.org>



Reply to: