lkml.org 
[lkml]   [2009]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: CONFIG_VFAT_FS_DUALNAMES regressions
    From
    Date
    On Wed, 2009-07-08 at 11:04 +0100, Alan Cox wrote:
    > > that it should be configurable, but I don't think it leads to the
    > > conclusion that the patch should not be in the upstream kernel at all.
    >
    > I think we already proved it had no use upstream. Vendors will remove
    > the code from their source tree if worried about patents so including it
    > in the base tree is really irrelevant. So I find your argument about this
    > less than convincing.

    You have asserted such, but that's not proof. If your assertion were
    valid, vendors would already have removed all the msdos/vfat code, which
    they haven't.

    Obviously I have no idea what your ex-employer will do. I also can't
    speak for Novell, but very likely what we'll do is leave the decision
    for OpenSUSE up to the OpenSUSE community and likely follow the kernel
    default for SLE.

    > The patch serves no purpose but to confuse users and increasingly it is
    > shown to break systems horribly.
    >
    > There might have been a limited case for a not-quite-vfat-fs "tridgefat"
    > etc if it was both more compatible and if the vendors would use the
    > option. But given its not compatible and vendors won't why bother at all ?
    >
    > I also note you keep talking about vendors. This is an open list yet I
    > don't hear a word from the vendors you claim to represent in support of
    > this patch set, and saying they would enable it. Not one voice seems to
    > have appeared.

    Why would vendors wish to comment? Their position universally is that
    the FAT32 patents are invalid. However, they also recognise that
    trolling with invalid patents is increasingly becoming a nasty problem
    for their customers, and with TomTom Microsoft has shown willing to do
    this, so anything that lowers the risk and potential costs to customers
    would be a good thing for vendors.

    > The decision sequence goes something like this
    >
    > - do we want to ship the feature because of patent concern
    > > do not ship
    > - is it less risk to remove the source from our build tree or
    > configure it out
    > > remove from the tree
    > - is there a functionality difference to the user between
    > removing or unconfiguring it
    > > No
    >
    > At that point nobody managing risk is going to do anything but remove the
    > code that worries them. It's additional risk with no return.

    I think you might be confusing two sources of risk. The risk of
    actually infringing a real patent is what you're covering above. The
    source of risk in this case is the risk of being trolled with an invalid
    patent but have to spend millions of dollars to demonstrate such if it
    goes to trial. The patch mitigates the latter risk by making it
    demonstrable at a preliminary hearing that the invalid patent doesn't
    read upon the kernel implementation.

    James




    \
     
     \ /
      Last update: 2009-07-08 17:31    [W:0.026 / U:91.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site