Date:	Thu, 9 Jul 2009 11:20:40 +1000
From:	tridge@...ba.org
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Martin Steigerwald <Martin@...htvoll.de>,
	Jan Engelhardt <jengelh@...ozas.de>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Theodore Tso <tytso@....edu>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Pavel Machek <pavel@....cz>, john.lanza@...ux.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>, corbet@....net,
	jcm@...masters.org, James.Bottomley@...senpartnership.com
Subject: Re: CONFIG_VFAT_FS_DUALNAMES regressions

Hi Alan,

 > The vendors can only talk to one another with lawyers present, so this is
 > an irrelevant argument to the public kernel. We've proved that already in
 > the fact you can't even discuss implementation details with the list.

We have discussed implementation details on this list. We've shown the
code, and a FAQ on how the code works. 

The situation is much more subtle with regard to what can be publicly
discussed than what you make out. Think of it like the media training
that many engineers get in companies these days. You need to learn
what words can and cannot be used. I think it is perfectly possible to
have public discussions of patents such as we are having right now. 

I grant you that it is very unusual to do this, but I would like to
see that change.

 > > You talk about media players and other software being crippled in the
 > > US and other countries as though this is a good thing. You talk about
 > > vendors ripping out large slabs of functionality as though you want it
 > > to happen.
 > 
 > It is what the vendors will do regardless.

no, when the vendors are given a clearly non-infringing way of
implementation then I think they will go for it. The proof is that
they still ship Samba, which includes patent workarounds, and I'm sure
there are plenty of other free software packages which similarly have
patent workarounds and that are shipped with distros all the time.

 > This misses the fact that if the vendor thinks sueing you is a business
 > opprtunity they will do so anyway. Why should they care if the patent is
 > valid - its not relevant to most of the legal process so it still has the
 > desired slowdown and expend money approach

you are mixing up "validity" and "non-infringment". If my argument was
in any way based on a patent being "invalid" then you would be right,
because a court is required to start from the assumption that a patent
is valid. Trying to fight a patent based on invalidity is really
really hard.

The court is not required to start with the assumption that a piece of
code infringes a patent - quite the opposite in fact. If the defendent
can show a clear argument as to why it is not infringing then the
patent holder quickly loses.

Do you know of any example where a defendent had a really good
non-infringment argument and still lost a case?

 > If you wanted reliable working approach surely tridgefat should read long
 > names but only create new short names ? That keeps you in spec, as I
 > understand it avoids the alleged possible patent infringement and works
 > for all devices ?

'works' for all devices, except that any Linux users copying a file
with a long name to the device get an error. That is not my idea of
'works'.

My patch in May proposed that solution because of it's simplicity, not
because it was the best solution. It was the first solution I thought
of, and I'm sure others thought of it too, but it loses so much
functionality that it would be a very painful solution for Linux
vendors.

The dualnames patch achieves a much higher degree of functionality for
a much wider number of users. It isn't perfect, but I think it is much
better.

 > Many of the things removed are not patent related. Patents are only one
 > issue. Stuff gets removed for many reasons including a few cases of "they
 > sue everyone who does this regardless of validity so we don't XYZ"

again, this is validity, not non-infringment. I am not advocating a
"you're patent is invalid" argument, as that is not certain enough. I
am advocating a "we don't implement that" approach.

 > I've spent over ten years doing that. Those ten years have taught me
 > 
 > - if you give in to a patent thug they will simply try to bully you
 >   further

and what did TomTom do on these patents? They had to give in, because
they didn't have a workaround. What has that taught the patent holders
of the world?

I'd like to teach patent holders that if you assert a patent against a
free software implementation of any bit of technology that you will
have a huge group of engineers working on stomping all over your
patent, thus threatening the nice little revenue stream you have from
other proprietary licensees.

We need to be seen as the guys with the big club who even the bullies
don't mess with. 

The great thing about this is that it works even better with patent
trolls. Their sole purpose in life is to derive revenue from their
patents. If we become known as the guys who threaten that income then
the trolls will give us a wide berth. 

This is an advantage that only the free software community has. If a
proprietary vendor finds a patent workaround then they will keep it
secret, as they don't want the other proprietary vendors to be able to
avoid the license fee. That means the trolls lose just one victim if a
proprietary vendor finds a workaround. With the free software
community our open code means that the trolls will be risking their
entire revenue stream from the patent by attacking any vendor based on
free software. That puts us in a uniquely strong position in the
patent world.

 > - if you limit functionality silently or in an unreliable way the blame
 >   falls on the software supplier not the patent holder or the governments
 >   who made the bad laws (or the judges of course as software patents
 >   in many states aren't really of political origin but judicial
 >   over-reach)

And if we make it so that copying files to a FAT filesystem return
-1/ENAMETOOLONG then what will that do to users? You really think
users will have sympathy with the situation then?

 > - if you delete stuff from base packages you hurt people in the rest of
 >   the world unneccessarily

that impacts only what the default should be, not whether the patch
should be in at all.

 > - patents are a tiny part of the process anyone shipping any software
 >   commercially on a scale worth lawsuits goes through reviewing.

so? For all the other parts of the process there are ways to manage
it. For patents, the solution of removing large amounts of
functionality is non-workable for many packages.

 > The patches you've proposed break stuff. It's mildly funny that MS is
 > trying to force us into a workaround that randomly crashes MS boxes but
 > that doesn't make it a good idea to merge such a change. Nor is it a good
 > idea to call something vfat which is not vfat.

and how is your preffered 'return -1/ENAMETOOLONG' for valid long
names 'vfat'? A new filesystem name could be used, but I think that is
largely cosmetic. How many Linux users, other than developers,
actually type:

  mount -t vfat .....

I think nearly all users just rely on the auto-detection of the fs
type. 

 > So instead of regressions can we be a little bit less clever and a little
 > bit more reliable and do "FAT which reads and honours existing longnames"
 > and give it a name other than vfat.
 > 
 > That would give us absolute on media compatibility, accessibility from
 > all devices (which is the important bit) but some naming limits for new
 > file creation.

It is the 'some naming limits' bit which is the problem. As was
pointed out when I posted the patch that did this in May, those limits
impact a whole lot of normal use cases.

Cheers, Tridge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists