- From: Paul Rohr <paul@abisource.com>
- Date: Mon, 01 Oct 2001 19:13:38 -0700
- To: www-patentpolicy-comment@w3.org
Sigh. / informative / In the mid-90s, I had the privilege of attending WG meetings for the standardization of HTML and CSS as a technical representative for Spyglass. This was during the heat of the browser wars, when my company was struggling to keep up with our much larger rivals (MSFT and NSCP). Yet despite the heated nature of that battle, there was always a clear and pragmatic focus on how we could agree to standardize for the benefit of *all* implementors, not just those in the room. More recently, I've had the privilege of leading the development of AbiWord, a cross-platform word processor that's steadily gaining the respect and admiration of hundreds of thousands of users worldwide. There are a number of possible reasons for that success, such as: - the product has a clean, familiar user interface - there are a number of import/export filters - translations are available for over 30 locales - it's an Open Source product - our spokesperson, Abi the Ant - etc. Yet I can't stress enough how much of our success is clearly due to the fact that, from the very beginning, we chose to build our underlying technology on the following W3C recommendations: XML 1.0 PNG 1.0 In addition, while we weren't able to use the formatting models of CSS 1.0 and 2.0, wherever possible we've attempted to reuse the design and standardization efforts from those specs in the design of our own file format. Likewise, we've been telling developers for years that when it came time to add vector graphic support to our products, they should look to the relevant W3C standard (SVG) as it developed to see if it could in any way be used to suit our needs. To be clear -- none of these four technologies were developed or standardized with my product in mind. As a desktop word processor with an unabashedly WYSIWYG focus, our product isn't really the kind of Web technology that the W3C is chartered to support. Still, I've happily recommended to all new AbiWord developers that they look first to the relevant W3C standards when trying to decide how we should implement any new features. By insisting from day one that the file formats we create are as W3C-friendly as possible, we not only minimized cross-platform compatibility issues for ourselves, we've also strived to maximize the odds that the content we create could be as interoperable as feasible with other software products in the future. I thus find it *incredibly* disillusioning to learn (at this late date) that W3C is considering using anything other than RF patent policies for their standards. Since our software was developed under the GPL, we've already had to forgo support for the GIF file format due to patent problems. The last place I expected to find similar problems was at the W3C. Shame on me for not paying closer attention. / normative / Obviously, I hope you'll reconsider this policy, as it's bad for widespread deployment of the standards, bad for follow-on implementors, and bad for the reputation of the W3C. However, so I can better understand the import of this policy if it *is* enacted, I'd appreciate answers to the following questions from a PPWG member: 1. What grandfather provisions, if any, are there for the de facto RF patent policies on existing recommendations, such as XML 1.0 and PNG 1.0? Under existing W3C policies, are those specifications currently considered to be RF after all? 2. What language in the proposed policy, if any, constrains existing WG members from adding patent claims to encumber those (or other) existing W3C recommendations? 3. I notice that some of the SVG WG members are asserting RAND policies for their contributions to the recently-published SVG 1.0 recommendation. If the proposed policy (to allow RAND) is *not* adopted, what happens to the status of SVG 1.0? Is it still a W3C recommendation, even though it doesn't seem to be RF? 4. Will the SVG working group be required to recharter itself to apply the new RAND policies to the recently-published SVG 1.0 recommendation? 5. Finally, as a developer and distributor of GPL software which currently *does* make use of W3C specs, how does the PPWG recommend that I deal with any W3C specs that become RAND-encumbered? Do I need to just avoid them entirely, or does the PPWG know of any interpretations of the RAND policy which might be GPL-compatible? (I highly doubt that Eben or Richard missed anything here, but if you know of anything, please let us all know.) / confused and disappointed / Paul
Received on Monday, 1 October 2001 22:05:17 UTC