Re: Non-GPL export of invalidate_mmap_range

[Paul E. McKenney]

On Wed, Feb 18, 2004 at 11:00:55PM +0000, Christoph Hellwig wrote:
> On Wed, Feb 18, 2004 at 02:51:32PM -0800, Andrew Morton wrote:
> > a) Does the export make technical sense?  Do filesystems have
> >    legitimate need for access to this symbol?
> > 
> > (really, a) is sufficient grounds, but for real-world reasons:)
> > 
> > b) Does the IBM filsystem meet the kernel's licensing requirements?
> > 
> > 
> > It appears that the answers are a): yes and b) probably.
> 
> Well, the answer to b) is most likely not.  I see it very hard to argue to
> have something like gpfs not beeing a derived work.  The glue code they
> had online certainly looked very much like a derived work, and if the new
> version got better they wouldn't have any reason to remove it from the
> website, right?

Nice conspiracy theory!  ;-)

It was moved to a different website some time ago:

    http://techsupport.services.ibm.com/server/cluster/fixes/gpfsfixhome.html

The current version is 2.2.0-1.  You will get a tar.gz file, and
the glue code source will be in gpfs.gpl-2.2.0-1.noarch.rpm after
you unpack.

						Thanx, Paul

> > Please, feel free to add additional criteria.  We could also ask "do we
> > want to withhold this symbols to encourage IBM to GPL the filesystem" or
> > "do we simply refuse to export any symbol which is not used by any GPL
> > software" (if so, why?).
> 
> Yes.  Andrew, please read the GPL, it's very clear about derived works.
> Then please tell me why you think gpfs is not a derived work.
> 
> > But at the end of the day, if we decide to not export this symbol, we owe
> > Paul a good, solid reason, yes?
> 
> Yes.  We've traditionally not exported symbols unless we had an intree user,
> and especially not if it's for a module that's not GPL licensed.
> 
> We had this discussion with Linus a few time, maybe he can comment again to
> make it clear.
> 
-
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/