Ross Walker <rswwal...@gmail.com> wrote: > > If a shell script may be dependent on GNU 'cat', does that make the shell > > script a "derived work"? Note that GNU 'cat' could be replaced with some > > other 'cat' since 'cat' has a well defined interface. A very similar > > situation exists for loadable modules which have well defined interfaces > > (like 'cat'). Based on the argument used for 'cat', the mere injection of > > a loadable module into an execution environment which includes GPL > > components should not require that module to be distributable under GPL. > > The module only needs to be distributable under GPL if it was developed in > > such a way that it specifically depends on GPL components. > > This is how I see it as well. > > The big problem is not the insmod'ing of the blob but how it is distributed. > > As far as I know this can be circumvented by not including it in the main > distribution but through a separate repo to be installed afterwards, ala > Debian non-free.
I've seen these arguments over and over but they are wrong. 1) The OpenSource definition http://www.opensource.org/docs/definition.php section 9 makes it very clear that an OSS license must not restrict other software and must not prevent to bundle different works under different licenses on one medium. 2) given the fact that the GPL is an aproved OSS licensse, it obviously complies with the OSS definition. 3) as a result, any GPL interpretation that is based on the assumption that a separate distribution would fix problems is wrong. There is a simple rule: - If you modify a GPLd work by your own, so that all you add was written by you for this modification only, then you created a "derivative work" and you need to put your modifications under GPL. - If you add another independent work to a GPLd work, you create a so called "collective work". This is permitted by the GPL. In this case, the GPL only applies to the GPLd part and the license for the other work applies to the other work. You need to respect the sum of all claims from all licenses in this case. Such a collective work can only be distributed if the claims from the licenses are not contradicting. If one license e.g. permits redistribution on Mondays only and the other permits redistribution on Wednesdays only, you cannot publish the collective work. ZFS is an independent work with respect to the Linx kernel. It was not written for or with the Linux kernel. - If like to you add ZFS to the Linux kernel, you first need to create a derivative work from ZFS and another derivative work from the Linux kernel in order to allow both to work together. You later create a collective work from the combination of the derivative works mentioned before. The modification in the ZFS code (in case they appear in files that come with ZFS) need to be put under CDDL, the modifications in the Linux kernel need to be put under GPL. Note: the GPLv3 tries to disallow most collective works, so be careful with GPLv3. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de (uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
