Re: Direct i/o changes break all non-GPL file systems

[Anton Altaparmakov]

Hi Alan,

I don't really want to get into this discussion due to the likelihood of people using it as an excuse to start a flamewar which we can really do without.

Linus has previously stated that he is happy for binary kernel modules to exist and I believe that a kernel module calling EXPORT_SYMBOL() functions is the equivalent of a user space program executing system calls.  I do not believe this has even been decided in court so let us please not start a flamewar on the subject!  I am sure both points of view have their merits but unless they are tested in court there is no point in wasting everyones time discussing the subject to death.  That has been done many times before ad nauseum.

Can we please let this sort of debate be and just focus on the question whether this breakage for non-GPL modules was intentional or accidental and if the latter whether the author, namely Christoph, would be willing to reconsider his choice and allow the symbols to become generically exported, in which case we can return to the state we had before by exporting the two symbols to all modules.

Thank you (and apologise for top posting).

Best regards,

	Anton

On 8 Feb 2012, at 00:15, Alan Cox wrote:

> On Wed, 8 Feb 2012 00:07:15 +0000
> Anton Altaparmakov <anton@xxxxxxxxxx> wrote:
> 
>> Hi Linus, Andrew, Christoph,
>> 
>> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.
> 
> I'm advised by my lawyer that when this occurs that I should always
> inform the other party the following
> 
> "For a Linux kernel containing any code I own the code is under the GNU
> public license v2 (in some cases or later), I have never given permission
> for that code to be used as part of a combined or derivative work which
> contains binary chunks. I have never said that modules are somehow
> magically outside the GPL and I am doubtful that in most cases a work
> containing binary modules for a Linux kernel is compatible with the
> licensing, although I accept there may be some cases that it is."
> 
> 
> 
> So unless your code is remarkably non-derivative I don't see that
> anything has changed.


-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

--
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/