mldonkey-users
[Top][All Lists]
Advanced

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

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


From: MLdonkey
Subject: Re: [Mldonkey-users] GPL compliance, debian package
Date: Fri, 30 Aug 2002 13:33:12 +0200 (CEST)

>  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
developpers: we have constraints (preventing abuses) that are not
taken into account by the GPL licence, and FSF gurus often have an
ideological position, and don't want to understand that some code
could be free, without being mutable, to enforce some "laws" (respect
of other users) on a network. Such a problem would have been solved if
they had agreed to keep these files as a caution of freedom, but hide
them from end users.

>  So I _could_ do whatever I want with them (within the bounds of the
>  GPL).

Yes, of course, you could. That's the difference between trust and
law. GPL is a law, and people can do whatever they want inside the
law, even hurting other people, and they will not feel guilty because
they did respect the law. Trust is different: if you agreed for
something, you have to think before breaking the agreement about the
fact that your decision could be bad, even if it respects the law.

That is why the "secret" files of mldonkey are distributed under some
kind of "trust" licence. I think the FSF position in the mldonkey case
is too ideological: they believe open-source is always good, and they
don't care about the fact that, in some cases, it can be bad. Is the
benefit of open-source always greater than the disavantages ? I cannot
reply to this question, and I think nobody can. And I don't want
mldonkey to be an example or a counter-example for this question, I
don't want to be "the guy who killed edonkey" for the pleasure of
saying "open-source" is always good. Because some people are happy
with edonkey, because some guys worked hard to make it work, and I
respect their work.

As you said, you could do whatever you want. In some sense, you are
the guaranty for other users that mldonkey is free, as you could
distribute its complete sources :)

>  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. 

>  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
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. 

As an example, I wrote a Divx movie player for Linux a few years
ago. It has been used a lot for some time, and suddently, mplayer
appeared. Now, I'm pleased to use mplayer, because it is better, and
it can play many other movie formats. I don't care about the source I
wrote for my player. The final goal was achieved: having a good movie
player for Linux.

For mldonkey, it is the same: I don't care about who will use its
source files, I only want to have a good client under Linux for p2p
networks. 

>  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 :)

>  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.

For me, this debate is a waste of time. As I already wrote it, I don't
care about the licence, about the use of mldonkey code in other
applications, as it would not hurt me nor anyone else. This code is
free, even more free than stated in the GPL.  I only care about
malicious clients that could be build from the complete sources, and
these clients would hurt much more people.

- MLDonkey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]