Re: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

[Theodore Tso]

On Mon, May 04, 2009 at 09:30:20AM -0700, Eric W. Biederman wrote:
> Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx> writes:
> 
> > That's for the maintainers to decide.  If they agree it has worth, maybe
> > it's a good idea to answer "How".
> 
> Al and Christoph said essentially the same thing and they generally
> are considered the general area filesystem maintainers.

Ultimately the folks that is will be primarily making this decision is
Ogawa Hirofumi-san, as the FAT/VFAT maintainer, and Linus Torvalds, of
course.  So I'm not sure this thread is actually all that productive,
unless we can move it back to talking about the technical issues.

> When all of the pieces are public how can having secret veiled reasons
> make sense?

Legal reasoning and strategy often needs to be kept confidential.  It
may not make a lot of sense, but in the real world, lawyers can do a
lot of harm (and good) and in their area of expertise, I tend to defer
to their judgement, just as I defer to an airplane pilot on how to
safely fly me from Boston to Amsterdam.

I will observe (again) that Digital Camera manufacturers, and the
folks who came up with the DCIM standard, have for the last 10+ years
explicitly used a scheme where their cameras do not need to create
anything other than 8.3 filenames.  So at least for those folks, the
FAT Long Filename support is bloat which they don't need or want.
Furthermore, their decision to avoid anything other tghan 8.3
filenames goes back far before any patent lawsuits or settlements that
people have alleged as being related to the "why" of the patch.  Every
single digital camera does not need long file names; they all use 8.3
filenames *only* in accordance with the DCIM standard.  Is bloat
avoidance for digital cameras manufacturers who want to use Linux a
good enough reason for you?

Note: We don't always ask people for the reason behind why they want,
say, cgroups to control I/O throttling for example.  They may have a
secret business case for how they will be able to leverage that
technology with some application stack to make tons and tons of money
--- and we don't require that deep motives be revealed in those cases.
If the "what" and "how" of the patch makes sense, there is at least
one valid use case for the "why", that's often enough.  And we ought
to consider whether or not the needs of digital camera manfactuers who
might have firmware bloat requirements and who have decided over a
decade ago that 8.3 filenames were just fine for writing images to
flash cards, is a good enough reason.  Think of it as a bloatwatch
exercise, if that makes you happy.  :-)

> And if secret magic consultations with lawyers are going to be invoked
> I expect we should have a Signed-off-by from those lawyers.

That certainly wouldn't make any sense.  The lawyers didn't originate
the patch, and the code didn't pass through their hands.  Maybe a
reviewed-by or an acked-by, though.  :-)

On Mon, May 04, 2009 at 02:53:41PM -0600, Chris Friesen wrote:
>
>> Or that patent is believed to be invalid and faught, and there was
>> absolute no reason to remove it except for companies doing as part of a
>> settlement and they could do it in their privat trees.
>
> What about the scenario where a patent is valid in certain parts of the  
> world but not in others?  It seems possible that in this scenario there  
> may be valid reasons to have a config option.

Quite possibly.  

Or possibly it's because it is believed that it could be invalidated,
which is why OIN is requesting prior art even though the last time to
invalidate the patent through prior art was denied by the patent
office.  (And note, if a patent is challenged, and survives the
challenge, it gets stronger by receiving more deference from the
courts; and if it survives a second change, it gets even stronger, and
can for all practical purposes, become unchallengeable --- which is
why you don't challenge patents lightly; so I would imagine the OIN
will tread very, **very** carefully before submitting a second
challenge to the USPTO --- which is probably why the OIN *has* made a
public appeal for as much prior art as people can find; even if they
do have some good stuff, you want as much ammunition as you can,
potentially since the USPTO has refused to admit they were wrong the
first time around.)

And in the meantime, perhaps there is a desire not to fuel any FUD as
well as not wanting removing very useful functionality that desktop
users might care about over bogus patent(s), but at the same time make
it easier for companies who might not have the multiple millions of
dollars that it takes to defend against a patent lawsuit, whether or
not the patent is bullsh*t or not.

					- Ted

P.S.  Ob.Disclaimer: The above is my opinion only, and and doesn't
necessarily represent IBM or the Linux Foundation's positions,
strategies, or opinions.  I have not privately discussed this issue
with any IBM employee, contractor, or lawyer (i.e., not besides
reading the public e-mails on LKML and reading the public Ars Technica
articles on the subject).  Most of what I know about patents from an
semester-long class taught at the MIT Sloan School of Business which
covered, quite extensively, Intellectual Property Law.  Unfortunately,
it's a very good thing for a programmer to be understand; perhaps that
says something about the society we live in.
--
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/