On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin Simpson wrote:
Since neither you nor Andrew are lawyers, I would kindly ask that you refrain from attempting to provide legal advice. :3
If you know I'm not a lawyer (and my nick should be the first clue) then it isn't an issue is it? As for Andrew you'll have to ask him that yourself. Since it's also clear I'm not a mesa3d developer you assume no legal responsibility for what I say either and you are under no responsibility to listen. Which is all irrelevant anyway because proposing to create a new invention is not legal advice; it's an engineering suggestion. I describe the patent claims and Andrews interpretation of patent law only to emphasise things that a hypothetical new invention should *not* do.
The scant legal advice that *has* been obtained suggests that the current course of action, wherein S3TC is not advertised without the aid of an external library or a configuration option force-enabling it, is the best course of action. I for one would prefer to have firsthand legal advice before making any changes, although I am not a lawyer and cannot provide legal advice.
Solves nothing other than push the legal burden onto someone else (distributions) who further push the burden to the end-user. All of which makes it harder to use. As far as I can tell the official site of the "external project" claims the project is unmaintained and at any rate it's rather unpopular with certain distributions for reasons that should be obvious. I'm certainly not sugesting that knowingly infringing material be added to mesa3d. What I'm suggesting is that some resources be made available to write a new *non-infringing* decompressor and that it seems likely the community may have overestimated the difficulty of the task. I often wonder if the OSS community isn't becoming a victim of its own FUD. If we need lawyers before writing code then we can't write ANY code and we might as well all do something else. I want to reiterate that it is my belief (as in non-legal opinion) that the s3tc patent does not cover the s3tc format itself, or even specific algorithms. What it covers appear to be specific methods that can be used to encode it and some steps that can be used to decode it. The issue is whether those claimed steps are the ONLY way of achieving an acceptable result and I honestly don't think they are. You are free to form your own opinion on that point. Then again if the community plays ostrich and assumes the problem is now solved - and worse concludes that any discussion of it is heresy - then how can a new invention be developed (at least collaboratively)? Unfortunately I lack the indepth knowledge of mesa3d internals and s3tc processing requirements required to invent such a thing myself.
At any rate, since Spring is open-source, I would heavily advise the Spring team to remember that OpenGL extensions that are not part of a core version are not guaranteed to be available, and in this case, there is a trivial workaround for when the extension is not present, so you guys could (and should!) include an uncompressed texture path and ship uncompressed textures.
Unfortunately Spring is an engine, not a game. The issue is that people writing games which use the engine typically use DDS textures due to various community members bandying the format about like it's the second coming. At any rate other than not supporting DDS at all (which would be an extremely unpopular and unworkable decision) there isn't much I can do to guarantee Spring games don't depend on proprietary drivers until a non-infringing s3tc decoder exists. SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org