Since other folks clarified that the suit needs to be about patents that are claimed to be essential for implementing W3C specifications, it just remains to fill out point 1 and swap A and B in your point 4:
1. Entities A, B..Z implement a W3C standard, in the process receiving a royalty-free license for some implicated technology from Entities A, B...Z.
4. B sues A on a related matter, for example they claim a patent on some essential W3C technology
As a result:
5. A sends B their new license terms for the assorted patents they hold, plus a request for prompt payment of fees or removal of product from distribution
6. B considers whether they can pass this cost on to their customers and still remain competitive with C..Z who still get A's patent claims royalty free.
The only reason for a company to comply and relinquish their legal rights would be altruistic. When is the last time that happened?
Which - relinquishing their rights or being altruistic? Because contrary to your assertion, altruism (while being possible) is not the sole reason. Limiting their liability to patent infringement lawsuits is one big, sound reason. The people that designed the specification (remember, W3C designs these specs it does not just rubber stamp them) are the ones most likely to hold patents on them. If they all sign up to an RF working group, in advance, then that removes a big source of financial risk (not the only source, but the most credible and likely one).
Another reason is to grow the market. Four or five companies each pushing their own proprietary format or protocol results in four or five tiny niche markets. But four or five companies that collaborate to make a freely implementable format or protocol, in the expectation that they can make good products or services that use them, also results in a bigger market and more opportunities to make money.
Altruism is good, but altruism with the chance to make a bigger profit is a business case;-)
Possibly 95% (seems a little high, please post your source) of the desktop computer market. Desktop computers whose sales growth has slackened off to pretty much flat over the last couple of years.
Compare this with the handheld PDA and mobile phone markets, whose growth is accelerating and whose lower cost and lower complexity make them more availabile to the populatrion at large.
Add a strategy to ensure we have just one Web - no more 'this is the handheld site' nonsense - people still get to share URLs without asking what brand of computer or phone you are using - and that percentage share rapidly goes below 50%.
Ta-da, instant relevance for standards-compliant content.
You are missing some important points here. Possibly you are confusing royalty free licensing with open source software.
There is plenty of scope for innovation - just, not at the expense of interoperability. Implementors are free to make things faster, more robust, easier to use, and so forth (including using any patented techniques that they own or have licensed). Which can of course generate the ching ching - better products get better reviews and sell more copies. And there can be open source implementations too and gasp these interoperate with the commercial ones...
So your binary choice between good (but licensed for fee) and crap falls wide of the mark.
At first sight, this a great comment. Why add all those new features if SVG 1.0 is not implemented 100% ?
But then reality strikes. SVG 1.1 adds not a single new attribute, element or method. It modularises SVG 1.0, is all.
SVG Tiny and SVG Mobile are profiles (subsets) of SVG. They are mainly intended for the Mobile industry - SVG Tiny on cellphones, SVG Basic on PDAs. And there are five Tiny and three basic implementations that I am aware of.
But these profiles also give a series of steps that new SVG implementations can take in turn. Instead of releasing a first version of an implementation that implements some random selection of features based on change or best guesses, a first implementation can go for SVG Tiny. Then in the next version it can add stuff like gradients and opacity and scripting and go for SVG Basic before finally biting off the rest of the stuff like complex filters andf going for SVG 1.1 Full, which is the exact same as SVG 1.0
So, the first step in not getting ahead of ourselves is to take a glance at the actual specs before commenting....
About the CPU power - in the SWF format from macromedia, there is a fixed frame rate. So, your desktop gives you only that framerate (though it could do better) and the high end PDA gives you that framerate and the low end PDA or cellphone would presumably curl up in smoke or dump core or take eight times as long to play it in agonising slomo, or something. In SVG, the animation is declarative so you can play it at the best framerate that your device can give (like video games, the better your machine the smoother the animation).
There does need to be some way to throttle back the animation though, I agree, just like the difference in a video game between 100fps and 500fps would be better spent doing something else.
Anonymous Coward wrote: It could be months before it gets to that stage
The stages in the lifecycle of a Standards Track W3C specification are:
first working draft
second, etc, working drafts
Last Call working draft (where it gets widespread review)
Candidate Recommendation (where it gets implementation experience)
Proposed Recommendation (last check, for about six weeks)
Recommendation
So it is being discussed because Proposed Recommendation means it has exited last call - which means there are multiple interoperable implementations and a test suite. Which means you can use it, now.
The thing with rumours is that, like sex, you should check past history before sharing with someone new.
Short verson SVG is Royalty Free
Longer verson SVG is Royalty Free and here is why...
The SVG Working group is chartered to be a Royalty Free working group. It was the first one at W3C, in fact. That did mean, though, that we asked all members of the working group for their license terms on patents that they might not even know they had;-) which scared some people at the time of the Big RAND Wars which slashdotters will remember... its seems that reading "company X has US patent 12345 and gives the following royalty free license" or "company Y has no patents and gives a RAND license to them" etc was too confusing.
So we simplified and clarified. In the SVG 1.1 and Mobile SVG specs you will find a link fromthe 'Status of this Document' to the patent page. There is one patent number there, from Kodak, along with a legal statement from Kodak that it is not needed for implementing SVG. We still have to tell people about it, of course, since they told us.
SVG support has been a difficult issue in Mozilla because of the rich canvas. As you say, the XML parser and DOM and CSS parser and inheritance and XLink simple linking and JPEG and PNG and ECMAscript are there already.
The Mozilla SVG project started off by using Raph Levien's rendering library libart,
which is only licensed to be used under the terms of the LGPL
and not the standard Mozilla MPL/GPL/LGPL tri-license.
So, that licensing issue held up getting SVG code into the trunk, and when it was in ther trunk, stopped it being in the core builds (it was there in CVS and could be enabled at compile time). It worked on Linux, MacOS, Windows, etc - it was very cross platform code but there was the licensing issue.
A new approach is to split the rendering code into platform-independent and platform-dependent parts. A test of this approach is available from the croczilla site (which has a bunch of great examples too) - there is a build that uses the GDI+ renderer suplied with Windows 2000/XP. Clearly, this avoids the license issue o the rendering library and clearly, it means there needs to be a separate platform layer for each supported OS (darwin on MacOS X, perhaps different linux layers for Gnome or KDE, etc)
I know the Netscape folks are aware of this, too, because I visited Netscape and gave them a demo which included Mozilla SVG among other things.
SVG 1.1 is just a modularized version of SVG 1.1, so that the SVG Tinad SVG Basic profiles can be built. It does not add new features.
The first working draft of SVG 1.2 was also released today, and asks for feedback about including audio: http://www.w3.org/TR/SVG12/#SMIL
There are already SVG implementatons that have experimental ausio support in their own namespace, for example the Adobe viewer and the CSIRO PocketPC viewer, so that prototypes one way to do it (as an audio element to SVG)
<audio xlink:href="whatever" volume="50">
XSmiles shows a different approach - use SMIL and SVG each in their own naespace.
Feedback on which methodis best would be welcome, to
mailto:www-svg@w3.org
actually deciding to include audio, one way or another is easy, everyone wants that, its a question of what syntax to use.
The other issue is the format. In SVG, unlike HTML, there are required formats on the image element - JPEG, PNG, and SVG itself of course. For audio, should we
- require one particular format
- require several formats
- not say anything
the issue being that the most popular format, MP3, is not royalty free. Ogg Vorbis is an option, but not all platforms support that and for mobile, there is not really room to add audio code. The SVG mobile players will likely just use an operating system call to do that. So, its a tricky decision.
"On occasions people have been flying to WG meetings and the patent terms of the meeting have changed while they were in mid air."
Actually that is completely incorrect. What actually happened was that the patent policy for a group (the second SVG WG) was expicitly set to Royalty Free in the call for participation, many weeks before the meeting.
The issue was not that the policy changed "in mid air" but that it did *not* change; the assumption had been, apparently, that we would change to RAND (while they were in midair); we did not change to RAND and I stand by that decision, as chair of the relevant WG.
Slashdot Mirror
Since other folks clarified that the suit needs to be about patents that are claimed to be essential for implementing W3C specifications, it just remains to fill out point 1 and swap A and B in your point 4:
1. Entities A, B ..Z implement a W3C standard, in the process receiving a royalty-free license for some implicated technology from Entities A, B ...Z.
4. B sues A on a related matter, for example they claim a patent on some essential W3C technology
As a result:
5. A sends B their new license terms for the assorted patents they hold, plus a request for prompt payment of fees or removal of product from distribution
6. B considers whether they can pass this cost on to their customers and still remain competitive with C..Z who still get A's patent claims royalty free.
anonymous coward said
Which - relinquishing their rights or being altruistic? Because contrary to your assertion, altruism (while being possible) is not the sole reason. Limiting their liability to patent infringement lawsuits is one big, sound reason. The people that designed the specification (remember, W3C designs these specs it does not just rubber stamp them) are the ones most likely to hold patents on them. If they all sign up to an RF working group, in advance, then that removes a big source of financial risk (not the only source, but the most credible and likely one).
Another reason is to grow the market. Four or five companies each pushing their own proprietary format or protocol results in four or five tiny niche markets. But four or five companies that collaborate to make a freely implementable format or protocol, in the expectation that they can make good products or services that use them, also results in a bigger market and more opportunities to make money.
Altruism is good, but altruism with the chance to make a bigger profit is a business case ;-)
Possibly 95% (seems a little high, please post your source) of the desktop computer market. Desktop computers whose sales growth has slackened off to pretty much flat over the last couple of years.
Compare this with the handheld PDA and mobile phone markets, whose growth is accelerating and whose lower cost and lower complexity make them more availabile to the populatrion at large.
Add a strategy to ensure we have just one Web - no more 'this is the handheld site' nonsense - people still get to share URLs without asking what brand of computer or phone you are using - and that percentage share rapidly goes below 50%.
Ta-da, instant relevance for standards-compliant content.
You are missing some important points here. Possibly you are confusing royalty free licensing with open source software.
There is plenty of scope for innovation - just, not at the expense of interoperability. Implementors are free to make things faster, more robust, easier to use, and so forth (including using any patented techniques that they own or have licensed). Which can of course generate the ching ching - better products get better reviews and sell more copies. And there can be open source implementations too and gasp these interoperate with the commercial ones...
So your binary choice between good (but licensed for fee) and crap falls wide of the mark.
At first sight, this a great comment. Why add all those new features if SVG 1.0 is not implemented 100% ?
But then reality strikes. SVG 1.1 adds not a single new attribute, element or method. It modularises SVG 1.0, is all.
SVG Tiny and SVG Mobile are profiles (subsets) of SVG. They are mainly intended for the Mobile industry - SVG Tiny on cellphones, SVG Basic on PDAs. And there are five Tiny and three basic implementations that I am aware of.
But these profiles also give a series of steps that new SVG implementations can take in turn. Instead of releasing a first version of an implementation that implements some random selection of features based on change or best guesses, a first implementation can go for SVG Tiny. Then in the next version it can add stuff like gradients and opacity and scripting and go for SVG Basic before finally biting off the rest of the stuff like complex filters andf going for SVG 1.1 Full, which is the exact same as SVG 1.0
So, the first step in not getting ahead of ourselves is to take a glance at the actual specs before commenting ....
About the CPU power - in the SWF format from macromedia, there is a fixed frame rate. So, your desktop gives you only that framerate (though it could do better) and the high end PDA gives you that framerate and the low end PDA or cellphone would presumably curl up in smoke or dump core or take eight times as long to play it in agonising slomo, or something. In SVG, the animation is declarative so you can play it at the best framerate that your device can give (like video games, the better your machine the smoother the animation).
There does need to be some way to throttle back the animation though, I agree, just like the difference in a video game between 100fps and 500fps would be better spent doing something else.
Anonymous Coward wrote: It could be months before it gets to that stage
The stages in the lifecycle of a Standards Track W3C specification are:
So it is being discussed because Proposed Recommendation means it has exited last call - which means there are multiple interoperable implementations and a test suite. Which means you can use it, now.
The thing with rumours is that, like sex, you should check past history before sharing with someone new.
Short verson SVG is Royalty Free
Longer verson SVG is Royalty Free and here is why ...
The SVG Working group is chartered to be a Royalty Free working group. It was the first one at W3C, in fact. That did mean, though, that we asked all members of the working group for their license terms on patents that they might not even know they had ;-) which scared some people at the time of the Big RAND Wars which slashdotters will remember ... its seems that reading "company X has US patent 12345 and gives the following royalty free license" or "company Y has no patents and gives a RAND license to them" etc was too confusing.
So we simplified and clarified. In the SVG 1.1 and Mobile SVG specs you will find a link fromthe 'Status of this Document' to the patent page. There is one patent number there, from Kodak, along with a legal statement from Kodak that it is not needed for implementing SVG. We still have to tell people about it, of course, since they told us.
So yes, SVG is Royalty Free
SVG support has been a difficult issue in Mozilla because of the rich canvas. As you say, the XML parser and DOM and CSS parser and inheritance and XLink simple linking and JPEG and PNG and ECMAscript are there already.
The Mozilla SVG project started off by using Raph Levien's rendering library libart, which is only licensed to be used under the terms of the LGPL and not the standard Mozilla MPL/GPL/LGPL tri-license.
So, that licensing issue held up getting SVG code into the trunk, and when it was in ther trunk, stopped it being in the core builds (it was there in CVS and could be enabled at compile time). It worked on Linux, MacOS, Windows, etc - it was very cross platform code but there was the licensing issue.
A new approach is to split the rendering code into platform-independent and platform-dependent parts. A test of this approach is available from the croczilla site (which has a bunch of great examples too) - there is a build that uses the GDI+ renderer suplied with Windows 2000/XP. Clearly, this avoids the license issue o the rendering library and clearly, it means there needs to be a separate platform layer for each supported OS (darwin on MacOS X, perhaps different linux layers for Gnome or KDE, etc)
I know the Netscape folks are aware of this, too, because I visited Netscape and gave them a demo which included Mozilla SVG among other things.
SVG 1.1 is just a modularized version of SVG 1.1, so that the SVG Tinad SVG Basic profiles can be built. It does not add new features.
The first working draft of SVG 1.2 was also released today, and asks for feedback about including audio:
http://www.w3.org/TR/SVG12/#SMIL
There are already SVG implementatons that have experimental ausio support in their own namespace, for example the Adobe viewer and the CSIRO PocketPC viewer, so that prototypes one way to do it (as an audio element to SVG)
<audio xlink:href="whatever" volume="50">
XSmiles shows a different approach - use SMIL and SVG each in their own naespace.
Feedback on which methodis best would be welcome, to
mailto:www-svg@w3.org
actually deciding to include audio, one way or another is easy, everyone wants that, its a question of what syntax to use.
The other issue is the format. In SVG, unlike HTML, there are required formats on the image element - JPEG, PNG, and SVG itself of course. For audio, should we
- require one particular format
- require several formats
- not say anything
the issue being that the most popular format, MP3, is not royalty free. Ogg Vorbis is an option, but not all platforms support that and for mobile, there is not really room to add audio code. The SVG mobile players will likely just use an operating system call to do that. So, its a tricky decision.
"On occasions people have been flying to WG meetings and the patent terms of the meeting have changed while they were in mid air."
Actually that is completely incorrect. What actually happened was that the patent policy for a group (the second SVG WG) was expicitly set to Royalty Free in the call for participation, many weeks before the meeting.
The issue was not that the policy changed "in mid air" but that it did *not* change; the assumption had been, apparently, that we would change to RAND (while they were in midair); we did not change to RAND and I stand by that decision, as chair of the relevant WG.