Re: Please open sysfs symbols to proprietary modules

[Kyle Moffett]

On Feb 02, 2005, at 23:08, Jonathan A. George wrote:
> As an observation:
>
> The Linux kernel appears to contain the GPL copyright notice.  This
> appears to explicitly releases the right to alter anything in a copy
> written work which shares that copyright notice.  Therefore,  all
> exported symbols would appear to carry equal weight; thus making the
> GPL_ prefix a notation of dubious value.

The EXPORT_SYMBOL_GPL is a license statement to binary module developers
that they are not allowed to use the code in question (by the author).
Changing those is logically similar to changing the license header in
a GPL licensed file from "Licensed under the GNU GPL v2 only" to
"Licensed under the BSD license found here: http://somewhere/";.  It
just plain isn't legal to change those without the agreement of all
contributors.

> Furthermore, it seems as if that the copyright might allow changing
> the GPL_ prefix notation to anything including
> BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL_ instead.

You could legally change it as long as you document that the symbol
"EXPORT_SYMBOL_BSD_HOOK_FOR_PORTING_DRIVERS_TO_THE_LINUX_KERNEL"
really means that it's licensed under the GPL despite the confusing
name, although even then you are at risk of the author calling foul.
It also doesn't change the licensing restrictions on the symbols.

> It would seem just as surprising if the U.S. courts were to stop
> considering history of enforcement in copyright law as it would if
> they were to start considering in cases of patent law.

One other thing, it technically _isn't_ legal to link any kind of
binary module with the Linux kernel.  The GPL actually indicates
that "linking" *DOES* make a derivative work.  However, Linus and
basically all of the contributors have agreed that the current
"EXPORT_SYMBOL" functions are ok for use by non-GPL modules, but
they refuse to have hooks specifically there for closed-source
modules, and usually require that most new innovative interfaces
are "EXPORT_SYMBOL_GPL"ed instead.

> A paranoid approach it to develop your driver targeted at FreeBSD,
> and then develop a glue layer abstraction for porting to other OS's.
> Then you simply might GPL your glue layer code as a module using
> any symbols you want for your GPL copy written code per the
> observations earlier in this email.

The one major stumbling block is that any code that imports symbols
that are exported via "EXPORT_SYMBOL_GPL" can only legally _export_
symbols using the same, for the reason I stated above.

> In this way you will have created a work with no intrinsic
> dependencies on the Linux kernel which avoids presenting your work
> as an obvious target for those who prefer to spend their time
> looking for targets. :-)

If it's a non-GPL module it _cannot_ legally use EXPORT_SYMBOL_GPLed
symbols, either directly or indirectly, under any circumstances.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/