Richard Stallman <[EMAIL PROTECTED]> 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 from scratch. 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 -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
