W3C home > Mailing lists > Public > www-patentpolicy-comment@w3.org > January 2003

Patent Policy

From: Edward Welbourne <eddy@chaos.org.uk>
Date: Tue, 31 Dec 2002 17:13:00 +0000
To: www-patentpolicy-comment@w3.org
Message-Id: <E18TPwq-000668-00@utter.chaos.org.uk>

http://www.w3.org/TR/2002/WD-patent-policy-20021114/

> The W3C Royalty-Free Patent Policy governs the handling of patents in
> the process of producing Web standards.

A very important topic.  Many pieces of software in the modern world are
naturally obliged to interact with the world-wide web; it is crucial
that the web thus be governed by open standards, if innovation is to
continue to flourish on and around the web.  A standard whose
implementation is covered by a patent cannot be sensibly described as
open unless the patent is first de-fanged.

> The goal of this policy is to assure that Recommendations produced
> under this policy can be implemented on a royalty-free basis.

(aside: assure ... `ensure' seems more apt ...)

I contend that this goal is too tame: software designed to interoperate
with the Recommendations must also be implementable on a royalty-free
basis, even if the software in question is not countenanced by the
Recommendations.

Both Web Servers and User Agents (to give the most obvious examples) are
significant and complex bodies of software which support mechanisms for
third-party code to provide added functionality at run-time (e.g. flash
and kindred plugins for browsers, or [NI]SAPI server-side extensions).
Such extensions are not parts of the Recommendation, and the extension
is a separate piece of software from the implementation of the
Recommendation.  Yet an extension may need - and typically does have -
access to arbitrary functionalities of the program it extends -
including those covered by an Essential Claim.

Once an Essential Claim is available to extensions to, and to programs
interoperating with, implementations of a Recommendation, it will
effectively be available to arbitrary other programs, save that it will
oblige them to go through some artificial motions to make themselves
classifiable as implementation of, interoperator with or extension to
the Recommendation.  Introducing the need for such artefacts benefits
no-one, least of all the W3C.

It is clear, further, that many in the Free (as in Liberty) Software
movement will be unable (both in principle and in practice) to work with
your policy unless all techniques which are necessary to implement W3C
Recommendations are available for use in all software - not just that
relating to W3C Recommendations - on a royalty-free basis.  The Liberty
to re-purpose code - to re-use it in arbitrary other programs - is an
essential part of the Open Source revolution.  Any Libre implementation
of a W3C Recommendation will include implementations of all Essential
Claims; limiting the royalty-free ambit only to implementations of W3C
Recommendations will collide disastrously with such re-purposing.

Accommodating the needs of the Free Software movement will effectively
turn the policy into a requirement that patenters of Essential Claims
substantially abandon relevant patent privileges; however, one may
equally read this as saying that a standard cannot sensibly be called
open if it depends on a technology which is subject to a monopolistic
privilege.  This would appear to be a prima facie truth which must be
accepted by all participants in the standards-making process.  To this
essentially political argument, I shall add a strictly technical
argument, below, with the same net effect.

(aside:
> All sections of this document are normative unless specifically
> market non-normative.
       ^
  marked
typo !)

That said, the policy appears to be a very sensible and prudent approach
to the sensitive and difficult problem of engaging holders of
monopolistic privileges in the standardisation process, save for one
clause which realises the restriction, implicit in the above goal, to
protecting only implementations of W3C Recommendations - namely ...

Section 3, clause 3:
[a W3C Royalty-Free license ...]
> 3. may be limited to implementations of the Recommendation, and to
>    what is required by the Recommendation;

This may lead to software being forbidden to interoperate with a
Recommendation, unless it is, itself, an implementation thereof.  It may
prevent extensions from integrating properly with implementations of
Recommendations, in so far as they have an existence independent of the
implementation (e.g. they are separately distributed).  It might even
oblige an implementation to use one solution to a general problem where
the Recommendation requires exercise of an Essential Claim while yet
using a separate solution to most of the same problem where the
Recommendation does not strictly require the Essential Claim.  It runs
against the W3C's interests for such restrictions to arise.

Worse, such a limitation may restrict the architectural choices of those
implementing a Recommendation: one would naturally chose to break up the
functionalities involved therein into a family of libraries, all
employed by one program to implement the Recommendation.  However, no
one of the libraries would constitute an implementation of the
Recommendation: only the main program itself would then be allowed to
contain the code which exercises the Essential Claim.

Indeed, where the Recommendation's implementation has, or may have,
several running instances at one time on a computer, breaking the
program up into shared libraries (a.k.a. DLLs) is the natural way to
minimise the host computer's resource-use; only a `thin application'
need remain as the program of which several copies are run.  Likewise,
if parts of the functionality (of an implementation of a Recommendation)
are only used on some runs of the program, putting those parts into a
shared library makes it possible for the program to only load the
library when needed - thereby, again, reducing load on the computer.
Again, if several W3C Recommendations require some common functionality
(e.g. URL parsing), it makes sense for an implementor to write a shared
library providing this, to be used by the implementations of all the
relevant W3C Recommendations - rather than obliging each of these to
include its own, probably with subtly incompatible bugs.  In like
manner, shared libraries provide a natural mechanism for the development
of a W3C standards-compliant core on top of which application-developers
can implement `thin applications', thus separating out the user
interface from the core and allowing several different user agents to be
built on top of a single engine (c.f. the gecko renderer).

If code implementing an Essential Claim is included in a shared library,
however, it becomes accessible to other programs - they need only link
against the shared library and exercise its API - even if those programs
do not implement W3C Recommendations.  It will then be a legal nightmare
to decide who is guilty of the patent infringement - the application
author has not written, published or distributed any code which
implements the Essential Claim, but has merely linked against an API
provided as part of the existing functionality of the target computer
system; yet the implementor of the Recommendation supplied the shared
library, in good faith, as part of the implementation of the
Recommendation.  Clause 3 would thus appear to allow the patent holder
to forbid the implementation of an Essential Claim in a shared library.

The flip-side of this is that the natural way for an implementor of a
Recommendation to make functionalities available, to other programs
interoperating with the Recommendation, is to provide those
functionalities via shared libraries.  It is, indeed, desirable that
essential components of implementations of W3C standards (e.g. XML
parsing, HTTP requests, etc.) should be provided in this form, so as to
facilitate the various uses (discussed above) of shared libraries as
common `engine and API' components.  Clause 3 allows a patent-holder to
forbid such sensible practices: indeed, the objective it tries to
achieve (namely, to ensure that the license not extend to applications
outside the arena of the W3C Recommendation) implicitly presumes that it
will be so used.

The world of computer software is ill suited to such "field of use"
restrictions, since the boundaries are far less well-defined than is
naively supposed in the wording of clause 3: allowing such restrictions
will merely lead to a legal quagmire from which neither the W3C nor
implementors of its Recommendations will ever escape.  If a patent
restricts the use of a technique essential to the support of a standard,
either the relevant claim of the patent needs to be substantially waived
or, if the patent-holder cannot be prevailed upon to do so, the standard
must be changed; otherwise, the standard is not meaningfully `open'.

Please remove clause 3 from Section 3 before ratifying this policy.

Your humble and obedient servant,

     Edward Welbourne.
--

Writing in my capacity as a private netizen; however, I earn my living
as a programmer, in which the web has been pivotal since 1994, including
a period as a server developer for www.Zeus.com and my present
employment as a browser developer for www.Opera.com.  For more, see
	http://www.chaos.org.uk/~eddy/cv/history.html
Received on Friday, 3 January 2003 12:15:12 GMT

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