Re: The old DFSG-lemma again...
Richard Stallman <firstname.lastname@example.org> wrote:
> Not quite--because you have to check that it really IS licensed
> properly and clearly under the GPL. Sometimes the developer *says*
> this, but when you scan the source files, you see one of them was
> copied from another package and has an incompatible license, maybe
> even a non-free license.
conversd (sort of like an irc server for hamradio operators) had exactly
this problem. It had GPL, BSD, none at all, 'free for hamradio operator
use', 'free from commercial use' statements in it.
The horrible mishmash that is conversd licensing is an extreme example,
but I nearly introduced non-free code into the kernel accidently in
1994. It is easy to get it wrong. A couple of email exchanges to GNU
cleared things up and I abandoned the work, writing a GPLed driver
My point is that licensing is often quite difficult to get right, so you
cannot assume that just because someone sticks in a COPYING file all is
well. You still need to check.
That is not to say "software licensing is hard, documentation licensing
should be too". Some guidelines would be welcome and I'm glad work is
moving to getting these together.
Just like (roughly) GPL means DFSG free but lack of GPL does not mean
automatically non-free. Perhaps the guidelines could have some sufficient
but not neccessary conditions.
A FDL document with no optional features passes, but one with optional
features of type X will also pass. The point is that there doesn't have
to be only one license (or variation of license) used. If you have a
license that is neither it doesn't mean an automatic failure but it
might mean it needs closer examination.
This all happens now anyway with software licenses. The concept just
needs to be extended to the documentation ones.
Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/ <email@example.com>
MIEEE <firstname.lastname@example.org> Debian developer <email@example.com>