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

Re: I've got a bad feeling about this...



Joel Baker wrote:
On Tue, Oct 15, 2002 at 12:45:56AM -0500, Chris Lawrence wrote:

On Oct 14, Joel Baker wrote:

Er. Given that 'libc' is under the 4-clause license, if this is true... or
does that not apply to 'system' libraries? NetBSD certainly has a fair bit
of GPLed code, including dist/gnu in the source tree.

Hmm.  This could get ugly quickly; my gut feeling is that since NetBSD
uses GPLed code linked against its libc, it's OK by the FSF.  But it
does set a bad precedent with us using the "system libraries"
exemption as a magic wand to get rid of GPL incompatibilities - Debian
hasn't done that in the past.

Ugh. Yes.

IMHO, Debian does need to examine this closely, and come to an agreement with the FSF. Particularly since this seems to be one of the vague areas of the GPL, and subject to interpretation. What I would like to see is a compromise saying that linking against base/required (ok, maybe essential would be better) packages is ok - provided they are DFSG-free. This would be practical, and much less than the exemption applied to say, Solaris or AIX.

This would solve most of our problems with OpenSSL, for example. It would not, and should not, solve problems like the KDE+Qt license issue from the past.

(Personally, I've always had certain doubts about the applicability of the GPL when linking against shared libraries, but I guess it's a legal thing, so it doesn't have to make sense...)

Still, as long as it's DFSG-free... what are the practical implications
of using it as a core? Do we have to provide an advertising clause in our
releases, et al, as NetBSD appears to?

I can work on trying to untangle the strands of which license applies to
what part of the NetBSD source tree, but I need to know what I should do
about the copyright file and whether anyone else needs to be aware...

Well, you definitely need to preserve the copyright file etc; if it's
a massive boilerplate with all the contributors' names, I'd put it in
the kernel package in /usr/share/common-licenses/NetBSD so
debian/copyright in other packages can refer to it.

It's the INSTALL.txt file, not a copyright file. I have not (yet) been able
to find a copyright or license file that directly applies to the sources
in CVS, either on the website or in CVS itself. Anyone who knows where the
heck the thing is hiding, do tell. :)

FreeBSD doesn't seem to have one at all. It looks like they've been mostly ignoring the need to list all the advertising clauses somewhere. :(

The bottom line, though, is that -legal is going to have to figure
this out.  You may have to comb every file in the source tree to
figure out what license applies to what :-(.

This is what I fear (though it may be limitable; we don't care about a
lot of the third-party cruft, and I'm looking to see how hard it will be
to trim it out of the sources completely, and simply put a note into the
copyright file saying 'check the NetBSD Project CVS if you want the full
tree').

In the kernel, I wouldn't worry about it. Just don't distribute a kernel with ext2 support compiled in. On FreeBSD, at least, it's GPL'ed, and conflicts with all the other licenses on the kernel.

(Practically Debian/FreeBSD may be in a better position here since
they're using GNU libc, which will avoid some of these issues.  But
they still have to worry about attribution requirements, etc.)

FreeBSD supposedly dropped clause 4 from all (C) FreeBSD code a few years
back; at least, the comments by GNU folks on the GNU website list this as
an example of happy co-existance.

Yes, for code copyrighted by the FreeBSD Foundation. They haven't cleaned up all the third-party stuff, and I'm fairly certain they've added some since.

The big problem I have here is in kernel headers, and with libcam. cdrecord needs to link to libcam, and that's a problem because it's GPL, and libcam has advertising clause. Which is a shame, because the code that libcam uses that has the clause is old, crufty stuff for backwards compatibility. Rather unfortunately, I can't simply remove it without breaking camcontrol. :(

I'm not even sure what, if any, meaning a license could possibly have over a #define, some struct's and a few typedefs.

I dread posting to -legal until I can sort at least some of the mess out,
though. I want to know what we're looking at first. Maybe time to post to
the NetBSD lists and ask the core group.

I can understand that.

	---Nathan



Reply to: