Re: [Mldonkey-users] GPL compliance, debian package

[Goswin Brederlow]

MLdonkey <address@hidden> writes:

> >  The files are part of the mldonkey-1.16 binary thats under GPL. They
> >  fall under the GPL or you violated the GPL in the first place.
> 
> Yes, in some sense, we violated the GPL in the first place. It was not
> what we wanted: I wanted mldonkey to be as free as possible, but I
> didn't want to allow users to abuse the edonkey network. 
> 
> It was a mistake to choose this license, instead of the LGPL. Now, the
> licence will be changed a bit: the core will be LGPL, and the other
> parts will stay GPL. These licence problems are a pain for the

>From LGPL-2.1:
  When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library.  The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom.  The Lesser General
Public License permits more lax criteria for linking other code with
the library.

As long as you have one GPL file compiled into the binary also
containing the secret files your in trouble.


Maybe it was a mistake, maybe not. Other P2P networks actually benefit
from open source. My opinion is that you can't stop misuse by having
closed source. That might even make it more of a challenge.

> >  The problem is that you can't distribute a mldonkey client with donkey
> >  support under GPL. That would make the secret files GPL (as they
> >  are for any released binary) and you really don't seem to want
> >  that.
> 
> If the core is LGPL, it can be linked to the secret files. 

But no GPL code can then link the core.
If you mean the complete mldonkey (not mldoneky-gui) source by core
that could work, otherwise not.

> >  Since its unlikely that you can get written permission from everyone
> >  that wrote some lines of code for mldonkey you also can't change the
> >  license.
> 
> Not true. The core has been written by myself, with the help of zoggy
> for the communication with the GUI. Other developpers worked only on
> the plugins (mainly the server). Changing the licence of the core from
> GPL to LGPL would be OK. Moreover, I don't think they would care about
> that. Personnally, I didn't care about the licence until Savannah

Not caring and being legal are two things and people can be strict
there.

KDE was kept out of debian for a long time for similar problems.

> asked us about it. I don't care about my files being used by anybody
> in a proprietary software, as soon as I can continue to use them to
> make mldonkey work. If someone wants to make a better version of
> mldonkey under another name, he can, and I will use his version if it
> is better than mine. 

> >  You might not care about it and just distribute a mldonkey with donkey
> >  support but Debian wouldn't risk it. So there would be no donkey
> >  support in Debian.
> 
> Debian has an ideological/political position: it is too
> strict. Helping free software is good, forcing it is bad, and a medium
> position would be great. Anyway, I don't really see the risk for them;
> at least, I can ensure them that they will not get sued by the
> mldonkey team :)

Debian as a project can't risk being shutdown because of some small
unimportant (sorry, blown out of reality to make a point) package that
isn't even realy part of debian (non-free is not debian).

They could shutdown all debian mirrors worldwide with something like
that and thats just not worth the risk.

You can risk it, because the worst that happens is that they shutdown
mldonkey and/or force you to release source. Your offline for a day, a
week. No big deal.

> >  One way around would be building modules for the different protocols
> >  that can be loaded at runtime or building libraries and providing a
> >  free donkey-dummy library that does basically nothing but sattisfy the
> >  linker and a closed source donkey library based on the donkey.lam
> >  file (like libungif and libgif or libsvgalib-dummy).
> >  
> >  I would probably choose the later because its easier to do, but thats
> >  from my experiences with c/c++. How easy is it to load a module with a
> >  given signature at runtime?
> 
> Currently, dynamic linking of modules is not possible with
> Objective-Caml. Moreover, it is not very portable.
> A LGPL core would solve this problem, at least for distributions that
> don't care about the complete sources.
> 
> >  PS: I'm assuming you have full copyright over the secret files. No
> >  patches from third persons under GPL in there?
> 
> No, I wrote every line of these files. Only one patch was integrated
> into mldonkey (another was added and removed) until now, and it was a
> bug-fix on two lines of C for portability.

Thats good. So the problem could/should be resolved bevor you loose the
capability to change the licence.

MfG
        Goswin