Yes. That's not a subtlety, that's the entire freakin' point. Devs aren't put at risk of "infringement" for distributing the source code. Put the code behind a switch-wall and you're out of risk of "enticing infringement", too, as the FreeType project demonstrates.
Originally Posted by drag
Only in places where the patents apply. Which is the reason people are p**sed - if China bans IM clients that enable encryption and prevent them from policing on its citizens, is Ubuntu, fedora etc. going to pull any OTR-enabled client from its repos? Of course not. At best, they'd put up a warning that software available may run afoul of local regulations and ensuring compliance is the user's responsibility, which it is. Why do YOU want to cripple the mesa experience for millions of users around the world just because some of them may be in jurisdictions that prohibit this?
I'll give you a simple example: MP3.
Mp3 format requires patented concepts for compatibility. There exists many pieces of software that implement the concepts. A big one is LAME.
The author programming MP3 support is fine. The author actually using it is illegal. Shipping a product using it is illegal. You using it is illegal. Unless you obtain a patent license.
Yes, that's what everyone wants. Why is this a problem?
Yes. So they would be forced to remove s3t support if they want to ship it and still allow people to use it as open source software.
It's what ffmpeg, x264 and just about every codec project does - put the patented tech in a container (switch-wall, separate lib/package, whatever) and put a huge Caveat emptor warning, saying, essentially: This code is covered by the usual license and we grant you all freedoms as usual. Do note however, that functionality in this code is covered by several patents in some countries which we do not hold and obtaining a license for these allowing your desired use is your responsibility.
By shipping Mesa with s3tc enabled by default it is creating a legal landmind for users. It would be the same as if the developers through up their hands and said:
"You may get sued if you use this software, but it's not our problem."
Does that sound responsible to you?
BINGO! That's what we're trying to accomplish for MESA. Having a separate branch for this is a PITA and far from easy. Upstream adoption would allow easier enabling of these features by any user who cares. Mesa-float and mesa-s3tc packages in repos like medibuntu ensue.
Also notice that while the patented features of freetype actually do exist, they are not shipped on by default. You have to recompile it.
No. From TFA (emphasis mine):
Just like how Mesa allows for s3tc if you add a external library. It's actually easier (when you have good drivers) to use Mesa with s3tc as you don't even need to recompile.
The dispute is whether or not s3tc support is _shipped_ enabled by authors or distributions, not that it exists.
The push there was for mainlining the S3TC and OpenGL floating point support but to not build it by default if not using the hidden --enable-patented option.
Not as an optional part of mesa from a development POV. Any commits that would break s3tc would go into mesa without problems and without anyone noticing until trying to build s3tc. As for FP, it's a completely separate branch so it's inherently lagging behind the mainline mesa, and if your distro included any tweaks to mesa for their version, you're left to trying to shoehorn the FP into the distro version, or shoehorn the distro's patches into the FP branch. The average user is pretty much screwed.
Mesa support exists and it has for a long time.
The dispute is whether to put floating point textures behind a switch-wall or leave it in a separate branch. I haven't read a good reason why the former is not an option. In the spirit of "the beatings will continue until morale improves", these ramblings will continue until we get an answer to this question:
Why can't you do fp-textures like FreeType and be done with it?