S3TC For Mesa Is Talked About Some More

[xception]

I don't get why this is such a big issue just because there's a patent defined in the US, just distribute the patented stuff to the rest of the world and leave US without them warning them somehow. Maybe this way the people in the US will finally understand how stupid their software patent laws are and rise against them! If this were any other country there wouldn't even have been any discussion about it. Let them suffer for what they allow to happen to them!

[89c51]

http://worldwide.espacenet.com/publi...5956431A&KC=A#

someone on the mailing list posted this and if its correct it seems to apply in EU also

[rvdboom]

BINGO! That's what we're trying to accomplish for MESA. Having a separate branch for this is a PITA and far from easy.

So in you're opinion, it's easier to be obliged to recompile the whole Mesa to gain a certain feature, than to just install an external librayr that will be dlopened at run time if available?
Sorry, I prefer a thousand times the second option. Look for instance at the libdvdread/libdvdcss stuff : distros can ship libdvdread without any fear of anything and you can just install libdvdcss to be able to read encrypted DVDs, a very small library which is in most repositories.
If Mesa can work this way with the s3tc lib, it's without doubt the most convenient way for end users.

As for floating point textures, this is different, as apparently dlopen cannot be used for them. It seems a compile switch is mandatory there.

[Thetargos]

but isn't S3TC owned by Via now?

Has anybody suggested to Via that maybe the best way they can show they are serious about Open-Source development is to make the S3 patents available to Open-Source developers under an Open-License, or under terms allowing the royalty free usage there-of?

My thoughts exactly. Approaching VIA would be much better in this case, and who knows? Maybe they will agree to a sort of patent covenant with the OSI for its use within OSS and Mesa (yeah, right!).