3 ms·

CDDL is not compatible with GPL. So this won't work.

by mkesper 11y ago

ithkuil 11y ago
Not sure it wouldn't work. Imagine you have a small GPL program, that all it does is to load plugins, e.g. with dlopen and invokes some function, let's call it "main". It clearly doesn't care what license the binary loaded that way has. What i does is to load a binary in memory, locate an address and transfer control to it. If the GPL didn't allow this kind of thing to happen, then the GPL linux kernel couldn't possibly load any proprietary program. Now, let's allow those "plugins" to do something more interesting: request some action by the plugin host. The "main" function receives a function pointer that serves as an entry point for "system calls". Again, it's perfectly legal to invoke such a function, regardless of whether you can see this as "dynamic linking", you can also see this as "providing an operating system system call". If you're not convinced, let's call this "plugin host" an novel operating deepcloudstrumpfkernel operating system. Now, this is a pretty hard to use interface. You probably want a library linked to your "plugin"/"program" that provides a more natural interface on top of this basic "syscall" interface. This library and it's headers will contain functions, constants etc. This library doesn't have to be licensed with GPL; any license compatible with your "plugin" will do. Let's make it CDDL (or MIT). Now, it would be very useful that this library, or parts of it (e.g. constant definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel; No problem again, whoever owns the copyright for this library can release it with both MIT and GPL license. You can use the same trick to implement a loadable kernel module that doesn't violate the GPL. However there is a lot of work. In order to properly abide by the GPL rules, you must be able to build a fully working kernel module without touching any line of GPL code (except header files and library objects provided by the compiler and your OS "primary interface"). This last part is what is tricky. If you want to create a kernel module, you need to include some helpers. If linux had a stable "driver API", somebody else could write a library that helps you build a compliant kernel module, but in order to be more agile, IIRC the linux kernel module subsystem is designed to be source compatible and not binary compatible between releases and the layer exposes a lot of linux internals, which are part of the kernel and it would be very hard to duplicate all this without being caught in a copy paste. jbooth's suggestion was to write such a dummy layer that bridges the linux VFS interface with something else; thus not requiring the kernel module to use the internal linux API. However there is more to it than the VFS API: you also need the bare minimum to make your kernel module actually loadable by the kernel not depend on any GPL library that helps you adhere to that ABI.

CDDL is not compatible with GPL. So this won't work.

by mkesper 11y ago

CDDL is not compatible with GPL. So this won't work.

Not sure it wouldn't work. Imagine you have a small GPL program, that all it does is to load plugins, e.g. with dlopen and invokes some function, let's call it "main". It clearly doesn't care what license the binary loaded that way has. What i does is to load a binary in memory, locate an address and transfer control to it. If the GPL didn't allow this kind of thing to happen, then the GPL linux kernel couldn't possibly load any proprietary program. Now, let's allow those "plugins" to do something more interesting: request some action by the plugin host. The "main" function receives a function pointer that serves as an entry point for "system calls". Again, it's perfectly legal to invoke such a function, regardless of whether you can see this as "dynamic linking", you can also see this as "providing an operating system system call". If you're not convinced, let's call this "plugin host" an novel operating deepcloudstrumpfkernel operating system. Now, this is a pretty hard to use interface. You probably want a library linked to your "plugin"/"program" that provides a more natural interface on top of this basic "syscall" interface. This library and it's headers will contain functions, constants etc. This library doesn't have to be licensed with GPL; any license compatible with your "plugin" will do. Let's make it CDDL (or MIT). Now, it would be very useful that this library, or parts of it (e.g. constant definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel; No problem again, whoever owns the copyright for this library can release it with both MIT and GPL license. You can use the same trick to implement a loadable kernel module that doesn't violate the GPL. However there is a lot of work. In order to properly abide by the GPL rules, you must be able to build a fully working kernel module without touching any line of GPL code (except header files and library objects provided by the compiler and your OS "primary interface"). This last part is what is tricky. If you want to create a kernel module, you need to include some helpers. If linux had a stable "driver API", somebody else could write a library that helps you build a compliant kernel module, but in order to be more agile, IIRC the linux kernel module subsystem is designed to be source compatible and not binary compatible between releases and the layer exposes a lot of linux internals, which are part of the kernel and it would be very hard to duplicate all this without being caught in a copy paste. jbooth's suggestion was to write such a dummy layer that bridges the linux VFS interface with something else; thus not requiring the kernel module to use the internal linux API. However there is more to it than the VFS API: you also need the bare minimum to make your kernel module actually loadable by the kernel not depend on any GPL library that helps you adhere to that ABI.