cvs commit: src/lib/libdwarf Makefile _libdwarf.h dwarf.h dwarf_abbrev.c dwarf_attr.c dwarf_attrval.c dwarf_cu.c dwarf_dealloc.c dwarf_die.c dwarf_dump.c dwarf_errmsg.c dwarf_errno.c dwarf_finish.c dwarf_form.c dwarf_init.c dwarf_loc.c ...

M. Warner Losh imp at
Fri May 23 17:04:09 UTC 2008

In message: <4836F649.9050006 at>
            "Bruce M. Simpson" <bms at> writes:
: Peter Wemm wrote:
: > The next point is that the Linux folks (including Linus) seem to
: > consider that making calls to the linux kernel causes your driver to
: > be a derivative, unless the API you're calling has been blessed as a
: > public interface.  (To be fair, I can see the point for their specific
: > circumstances, but their interpretation of copyright seems to be quite
: > a stretch to me).
: >   
: I wonder if the "netlink" API constitutes such a set of calls to the 
: Linux kernel. I raise this matter because we've just grown multiple 
: route table support, and it looks like we could use an API for that. If 
: we can gain compatibility with other systems, that widens our appeal.

Again, API isn't comprightable.  It is the use of code, distributed
and linked into the Linux kernel that would cause the contamination.

: Given that its developers had an informational RFC published, under the 
: auspices of "an interface to IP service modules", I think that somewhat 
: weakens the case that implementing an API constitutes a "derivative work".

No, it isn't a derived work.  Standard interfaces aren't
copyrightable.  The Linux folks themselves have used this arguments
against the SCO Monster :-).  Implementing them would be safe from a
copyright perspective.

: Such an interpretation of copyright seems equivocal, when one considers 
: that the same group criticise Microsoft for not opening their APIs: "We 
: want everyone to be able to play together, but only by our new set of 
: rules".

Good thing such an interpretation doesn't square with copyright law.
Nor have I seen them make such a direct argument.

Let's keep in mind that the GNU folks and the Linux kernel folks have
differing views on how aggressively to apply their license to others.
There's also many side 'gentlemen's agreements' that don't have the
force of law, but are practices that are tolerated (cf use of NDA to
restrict gnu toolchain code, for example).


More information about the cvs-src mailing list