> As a linux maintainer, you know we try very hard to encourage vendors > not to carry long lived out of tree patches because of the complexity it > causes for everyone. For the non kernel cases with patent questions this isn't the pattern you see. And for good reasons. A US patent compliant version of mplayer is probably a jpeg viewer. It would be very harmful to the rest of the world to gut the main package in that case. For the kernel case the reality is this If we include no patch the people concerned will remove the code from their distributed source tarball If we include a config option, the people concerned will *STILL* remove the code from their distributed source tarball. so the debate about out of tree patches is not as relevant as might at first seem obvious. The simple problem is that the GPL says if you give me the binaries I can ask for the sources which produced them. If those sources contain the source to an algorithm where there are claims of possible patent problems then the lawyers will prefer to play as safe as possible and pull the sources that concern them before they even permit anyone to type "make". A quick look at some packages from big US based vendors will show you that is happening all the time to pull out stuff as varied as mp3 playing and the openssh decss crypto mode. [Other bits cut, conspiracy case point noted and its why you should not post to linux-kernel with a fever temperature ;) ] > > There is a clear end user expectation that vfat means "microsoft fat with > > extended names". By all means add support for "not vfat" but don't call > > it "vfat" as that is misleading an interface breakage. > > The Microsoft FAT32 standard only says files with long names *may* be > visible on 8.3 FAT systems, it doesn't say *shall*. Therefore, my > reading is that this patch is fully compliant with the FAT32 standard, > and thus *is* definitely what we call vfat in Linux. Or are you > claiming that we've somehow extended the definition of vfat to mean > complies with FAT32 + makes 8.3 names available as well? I'm simply of the viewpoint that users expect certain behaviours and compatibilities and that therefore it would be best if the new filesystem variant had a new name. I'm not saying cp -r fs/foo fs/bar, just a new mount name. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
