W3C home > Mailing lists > Public > www-patentpolicy-comment@w3.org > October 2001

late comment, PPWG response requested

From: Paul Rohr <paul@abisource.com>
Date: Mon, 01 Oct 2001 19:13:38 -0700
Message-Id: <3.0.5.32.20011001191338.00ce6bd0@mail.abisource.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 April 2010 00:13:40 GMT