[DMCA-Activists] On Software Patents, Sender-ID, and MARID

[Seth Johnson]

(You can't patent abstraction.  This is, always was, and always
will be plain common sense, a matter that can only be a second
nature principle for human society.  How innovative abstractions
may be is utterly irrelevant, as Mr. Mead recognizes.  Mr. Mead
has a very good story to tell with the MARID Sender-ID process,
that might provide the means for understanding this, for anybody
who imagines that this basic essential principle either somehow
has to be, or somehow can be, ignored.  -- Seth)


> http://moongroup.com/index.php?option=content&task=view&id=31&Itemid=2


MARID: Are Software Patents a Bad Thing?          

Written by Chuck Mead     
Sunday, 26 September 2004
 

Foreword

Today, there is a serious problem with the American patent
system. The approval process encourages dishonest intellectual
property claims and this is harming the public interest.

How? 

Much of the work on the Internet is done through the use of open
standards. This has allowed for significant development and
innovation but when an open standard is subject to a patent
claim, this can cause problems. 

There is a clash taking place in the market place. Many believe
the best course to ensure innovation is through proprietary
software. Others strongly believe this approach has a fundamental
flaw. Innovation only occurs through open sharing of ideas. 

This struggle and the real potential for abusive patent claims on
open standards threaten ongoing innovation in America through
continued development of the Internet. The events we are about to
describe will show there is a need for immediate reform.
Otherwise, we run the serious risk of what most consider as
common Internet property falling solely under the control of
private interests. 

This poses true potential for harm to our most cherished
fundamental freedoms as we move forward in transforming America
into a global information society. 

- John Glube


Introduction

The events described in this article highlight serious problems
caused by the patent system used in the United States of America.
The original intent of the patent system was "to promote the
progress of science and the useful arts, by securing for limited
times to authors and inventors the exclusive right to their
respective writings and discoveries." Unfortunately, our current
system merely encourages dishonest intellectual property claims
and through its unlimited application and approval process uses
such broad strokes that it is actually harming the public
interest. The events we describe here are true and illustrate an
ongoing situation which has been deleterious to the public
welfare both within the United States and internationally. 


Technical Background

As you may know the technological underpinnings of the modern
marvel we all know as the Internet are built upon a large set of
defined protocols which were (and are) published as standards.
These are often referred to as Request for Comments or RFC's and
they are created, published and maintained by an organization
called the Internet Engineering Task Force (IETF). The canonical
location for published RFC's is here. 

The IETF has shepherded the standard development process since
the beginning of what we generally think of today, as the
Internet age. Its first meeting was held in January, 1986 in San
Diego, California. Oversight of the IETF is the responsibility of
the Internet Society (ISOC) which is an international,
non-profit, membership organization whose purpose is to foster
the expansion of the global Internet. 

The Internet Engineering Steering Group (IESG) is responsible for
technical management of IETF activities and the Internet standard
process. It administers the process according to rules and
procedures ratified by the ISOC Trustees. 

The details of the organizations mentioned above are given here
as background to events we intend to discuss more fully. Those
desiring to read more about the details of the inner workings of
the standards process should read The Tao of IETF: A Novice's
Guide to the Internet Engineering Task Force. 


For several years now the Internet world has become increasingly
concerned with the incredible volume of Unsolicited Commercial
Email (UCE which may also be referred to as Unsolicited Bulk
Email [UBE] or SPAM). One of the preeminent features of UCE has
always been that the actual originators of UCE messages are
almost always concealed through the use of forged headers.
Consequently finding the true sender of the message is,
essentially, impossible. The IETF, through an aptly named working
group it called MTA Authorization Records In DNS (MARID),
undertook to engineer and examine technical methods to prevent or
detect forgery in electronic mail. While not targeted against UCE
alone the technologies discussed would certainly have gone a long
way toward eliminating a good bit of the UCE, as well as
preventing the receipt of the viruses and worms which have
plagued users of the Microsoft operating system family popularly
referred to as Windows. At the same time the proposals also
appeared to prevent another rising problem which is typically
called phishing. The Anti-Phishing Working Group (APWG) defines
phishing this way: 

Phishing attacks use 'spoofed' e-mails and fraudulent websites
designed to fool recipients into divulging personal financial
data such as credit card numbers, account user names and
passwords, social security numbers, etc. By hijacking the trusted
brands of well-known banks, on line retailers and credit card
companies, phishers are able to convince up to 5% of recipients
to respond to them. 

Preventing phishing attacks was also seen as a valuable benefit
of the proposals considered by MARID. 

Prior to continuing with this explanation of events a minimum
understanding of how messages actually transit the Internet is
essential. When an Internet user sends a message to another user
the software they use (normally referred to as a mail client)
connects to what is called a Message Transfer Agent (MTA or mail
server). The MTA the client has passed the message to is now
responsible for determining where to send the message next. It
executes this task by querying another commonly used system
called the Domain Name Service or DNS. The DNS stores records
about domains Internet wide and may be used to specifically
identify the host or hosts responsible for handling electronic
mail for a given domain. Now that the MTA has queried DNS it
knows which mail server to send the message to next so it
initiates a connection to that host and says hello. After the
initial greeting the two hosts negotiate what we call a Simple
Mail Transfer Protocol (SMTP) session. Then the message is
transmitted by the sending host and may be accepted or rejected
by the receipt host based upon the receipt host's own set of
rules. The receipt host may do any of a number of things with the
message. In general the local rule sets on the receipt host may
direct that the message be rejected (denied by rule prior to the
completion of delivery), bounced (denied by rule after completion
of delivery), delivered to the end recipient or relayed to
another host. This describes the general processes involved with
transmission and receipt of a message. Experts in the field could
certainly add much more to this but our desire here is to simply
describe the process in general without having to burden the
novice with more detail than is necessary to understand the
issues and terminology. 


So what derailed the MARID process?

Throughout the MARID process a consistently recurring issue
barred the way to any possibility of consensus on the proposals
being considered. This occurred due to overwhelming evidence that
the proposed solutions could not be deployed universally as a
standard because the various proposals were encumbered by
Intellectual Property claims. These claims arose because of a
patent application submitted by Microsoft and currently under
consideration by the US PTO. Though Microsoft offered to license
their technology under terms acceptable to the IETF their license
deliberately excluded any possibility that an open source
software product could use their technology. This happened
because the license Microsoft offered and the licenses used to
distribute open source MTA's were wholly incompatible. Many of
the corporate representatives involved with the MARID Working
Group simply shrugged this off but the more numerous independent
members, many of whom use, support, or develop open source
software MTA's could not ignore it. This caused an insurmountable
disagreement where consensus proved impossible. 

The root cause of the disagreement is easily explained. In spite
of the fact that most of the well monied corporate entities
represented within the MARID working group didn't care about the
licensing problem, the vast majority of software used to
transport electronic mail on the public Internet today is
licensed using open source licenses. Examples include open source
MTA's like Sendmail (arguably the oldest MTA in use today),
Postfix, and Exim. Another MTA which must also be considered is
called Qmail. Though Qmail's license does not meet the technical
criteria required to be considered open source it does have a
license which causes problems with implementation under the
claims and licensing being made by Microsoft. Current estimates
are that some number in excess of 75% of all messages which
transit the Internet today are handled by open source software
and specifically by these open source MTA's. The problem MARID
had then becomes obvious. If Microsoft's license is not usable by
the developers and maintainers of open source MTA's then any
proposal which could not be used without accepting that license
is not implementable as a standard. It is simply impossible to
make a proposed solution a "standard" if 75% of those who would
need to use that "standard" cannot due to intellectual property
encumbrance. 


The Event Sequence

In June of 2003 a project called Sender Policy Framework began to
take shape on the public Internet. It was created by Meng Weng
Wong and it's purpose, laid out in the inaugural message to the
SPF mailing list, was to change the world. SPF was not the first
project of this type. In fact Meng referred to and thanked the
proponent of another idea called Designated Mailers Protocol or
DMP. DMP exists still as a draft standard at the IETF, authored
by Gordon Fecyk. 

SPF, through a promotion and adoption process typical of
successful, open source Internet projects, began to gain
adherents and proponents more successfully than any other idea
known in this realm. To date there are easily more than 100,000
domains publishing SPF records in their DNS. There is no way of
knowing how many of those are also checking their inbound
electronic mail for valid SPF records for senders but we suspect
there is likely a rough equivalency between the numbers of those
who have published and those who are checking. As of this writing
(September 2004) these numbers are continuing to grow. 

At about this same time Microsoft began talking publicly about a
similar proposal they were promoting called CallerID. Between
June of 2003 and January of 2004 the proponents of SPF and
CallerID found their way to the IETF's MARID working group. 

During an interim period between January of 2004 and May of 2004
much discussion ensued which included meetings and mailing list
work, as well as behind the scenes work undertaken by a variety
of people concerned with the issues at hand. Finally in May of
2004 a rough merger was agreed to between proponents of SPF and
CallerID. The technical details of the merger were relayed by
Wong in the following two emails sent to the SPF mailing list: 

http://archives.listbox.com/address@hidden/200405/0198.html
http://archives.listbox.com/address@hidden/200405/0199.html


Following the merger MARID's work took on a sense of urgency as
it appeared that there was a real chance that something usable
could come out of the effort but unfortunately this did not last
for very long. 

On May 28th of 2004 the IETF received Microsoft's Statement about
IPR Claimed in draft-atkinson-callerid which was to become a
focal point of the discussions from that point forward. The
discussions did not get hung up at this point simply because
Microsoft had made an IPR declaration (this disclosure is
required under the rules of the IETF and is normal). The problem
ensued because of the license Microsoft chose to require
agreement to before anyone could use the IP. They chose a license
type which is often used in this situation as they checked option
"b" under section VI. Licensing Declaration. This box is
entitled: Royalty-Free, Reasonable and Non-Discriminatory License
to All Implementers **. But the double asterisks pointed at the
following locale which spelled out the details of the proposed
license: 

http://www.microsoft.com/mscorp/twc/privacy/spam_callerid.mspx 


Following the links at that URL eventually lead you to a PDF file
which contains the text of Microsoft's license for Sender ID. It
is the wording of this license which caused all the trouble.
Rather than trying to give a re-hashed, second hand explanation
of what the problem with this license is, we defer at this point
to Larry Rosen an attorney who specializes in computer related
technological issues. Rosen confirmed in a quote in this 25
August 2004 article at eweek.com that he had been discussing the
license with Microsoft and he is quoted as saying that, "...the
'nontransferable, non-sublicenseable' language in their
reciprocal patent license imposes an impossible administrative
burden on the open-source development community and, in essence,
creates additional downstream patent licenses that will be
incompatible with the AFL/OSL and similar open-source licenses,
and with the open-source development process." 

Rosen goes on to say that, "The requirement that 'If you would
like a license from Microsoft (e.g., rebrand, redistribute), you
need to contact Microsoft directly' gives Microsoft information
about its competitors' plans that it has no reason to know."
Later in that same article Rosen refers to some of his
discussions with the attorneys at Microsoft who are responsible
for this license and relays that little progress has been made to
dissuade them from its use. 

In addition the Apache Software Foundation (ASF), distributors
and licensors of the worlds foremost web server and myriad other
pieces of open source software, officially rejected the Microsoft
license in a message published on their web site on 2 September
of 2004. In this message we glimpse some additional details
referencing the negotiations between Attorney Rosen and a
Microsoft attorney named Michele Herman. The message says that
beginning on the 9th of June of 2004 the ASF had begun consulting
with Rosen "to coordinate our efforts to resolve the patent
licensing issues." and that Rosen began negotiating with Hammer
on the 20th of July. The ASF message contains a cogent analysis
(the most detailed yet seen) on the problems with Microsoft's
license. 

An article published by pcpro.co.uk on the 8th of September
references some comments made by Matt Sergeant, a senior
anti-spam technologist for MessageLabs that are quite revealing.
Mr. Sergeant's comments are contained in a message sent to the
MARID mailing list on 2 September 2004. Mr. Craig Spietzle who
Sergeant refers to in his message is, apparently, the director of
industry and partner relations of the Safety Technology Strategy
Group at Microsoft. When pressed by Sergeant on whether Microsoft
would commit to fixing the licensing problems Mr. Spietzle did
not give Sergeant a clear response and left Sergeant with the
muddled impression that they would not fix the license. 


On the 14th of July, 2004 Mark Lentczner sent an email to the
MARID mailing list explicitly requesting that Microsoft clarify
the restrictions imposed in their license. 

Also on the 14th of July, Harry Katz, one of the Microsoft
participants in the MARID working group responded to a criticism
of Microsoft's Intellectual Property claims where the critic
declared that Bill Gates' quote about "...using security as a
"Strategic Competitive Advantage" might come back to bite him in
the anti-trust area." by saying: 

First, please read Ted Hardie's posting about our IP filing with
respect to the original Caller ID specification from which Sender
ID is derived. 

Second, to suggest that this is becoming a Microsoft only
solution is outrageous, abusrd [absurd] and without any basis in
fact! 

In reality we have been working in good faith within this group
to arrive at an Internet standard that the whole industry can
support with the objective of addressing a problem that we are
all concerned about. The current drafts, and the revisions we are
now working on following last week's design review, are
dramatically different from our original Caller ID proposal -- a
fact that reflects our willingness to compromise with others in
order to arrive at a common solution. 

If you cannot restrain yourself from gratuitous
Microsoft-bashing, I strongly suggest that you 

A) Do it somewhere else so you won't be disturbing people who are
trying to accomnplish meaningful work, and 

B) Get your facts right. 


Mr. Katz' protestations DO NOT stand up to the preponderance of
the evidence we have to draw from. The final clue to the reasons
why the MARID effort ultimately collapsed is found here, wherein
Mr. Katz was asked explicitly by a participant named Chris Haynes
if Microsoft's patent applications included the SPF technology as
well as the components of their own specific MARID contributions.
Mr. Haynes asked, "If you were able to confirm that the Microsoft
disclosure / IPR claims do not cover the marid-core spec. taken
in isolation, that would be extremely helpful and could allay
some people's concerns." The Katz response was terse as he
replied, "Confirmed." The direct implication of Mr. Katz response
was that SPF was in the clear as far as Microsoft's patent
applications were concerned. 

Later, on the 24th of August 2004, the issue of SPF's possible
encumbrance was raised again and once again, Mr. Katz confirmed
that SPF was NOT encumbered by Microsoft's claims. 

Also on the 24th of July of 2004 Richard Stallman, founder of the
Free Software Foundation, sent an email to the MARID mailing list
warning that the license Microsoft was imposing on it's
Intellectual Property was incompatible with and unusable by
software licensed under any of the existing open source licenses.


On the 19th of July 2004, Andrew Newton, co-chair of the MARID
working group laid out the schedule for "last call" (final
consensus) on Sender-ID. The schedule called for final consensus
to be completed by the 11th of August. This last call was then
extended into September as it became apparent that the WG would
not be able to reach a working consensus this soon. On 1
September 2004 Mr. Jonathan Gardner sent a proposal to the WG
entitled: Motion to abandon Sender ID. This proposal highlighted
all of the deployment issues caused by the Microsoft license and
suggested strongly that the WG should drop Sender ID as it was
not deployable because of the license. Then, on the 10th of
September Mr. Yakov Shafranovich asked the chair for a
determination on the "bottom line" for Sender ID's consensus
call. The response came the next day as the co-chairs rendered
their judgement. 


The following is the judgment of the co-chairs relating to
consensus within the MARID working group during the last call
period of 23-August-2004 through 10-September-2004. 

1) On the issue of using a DNS name prefix, there is at least
rough consensus that no prefix should be used. 

2) On the issue of compliance with the use of the TXT record, the
working group has at least rough consensus that TXT usage is
acceptable for compliance and should not be specified as a
configuration that will be non-compliant. However, there is at
least rough consensus that the use of the SPF-specific record
type is more desirable than the use of a TXT record type. It is
the opinion of the co-chairs that the -protocol document clearly
state that the usage of TXT records will most likely be
deprecated by future protocol definition. 

3) On the issue of ignoring patent claims, the working group has
at least rough consensus that the patent claims should not be
ignored. Additionally, there is at least rough consensus that the
participants of the working group cannot accurately describe the
specific claims of the patent application. This stems from the
fact that the patent application is not publicly available. Given
this, it is the opinion of the co-chairs that MARID should not
undertake work on alternate algorithms reasonably thought to be
covered by the patent application. We do feel that future changes
regarding the patent claim or its associated license could
significantly change the consensus of the working group, and at
such a time it would be appropriate to consider new work of this
type. 

4) On the issue of the ABNF in section 3.4.1 of -protocol and
multiple scopes, there is at least rough consensus to allow the
syntax and record structure to support multiple scopes. 

With regard to items 3 and 4 above, it is also the opinion of the
co-chairs that any attempt by the MARID working group to define
any new scopes other than "mailfrom" and "pra" for the SPF syntax
will at this time result in failure to find consensus within the
working group. 

The document authors have agreed to producing new drafts intended
to meet the chartered work item, and a consensus call on them or
the appropriate diffs will be forthcoming. This work plan does
not include scopes outside of "mail from" and "pra", and it is
our opinion that no new work items of this type should be
considered until MARID has successfully produced a first
specification. 

-MARID co-chairs 


This statement of consensus was a killer for Sender ID. It was,
for all intents and purposes, kicked to the curb but the
denouement was yet to come! On the 16th of September 2004 the
United States Patent and Trademark Office published the patent
application that Microsoft had been sitting on since October the
10th of 2003. The contents of this incredibly broad patent
application may permanently kill Sender ID and probably SPF as
well as a number of other electronic tools commonly in use today.
It needs to be analyzed by a competent patent attorney but until
it is the only presumption we can make is that all bets are off
if it is granted. It's contents blew up any possible continuation
of the MARID working group. 

Discussions on the MARID mailing list continued for a few more
days and then the MARID co-chairs made another announcement: 


After an assessment of the current state of the MARID working
group, its charter, and its milestones, the working group chairs
and Area Advisor have concluded that the MARID working group
should be terminated. 

The group was originally chartered with a very tight time frame,
with the expectation that a focused group of engineers would be
able to produce in relatively short order a standard in the area
of DNS-stored policies related to and accessible by MTAs. The
group has had no lack of energy. From the outset, however, the
working group participants have had fundamental disagreements on
the nature of the record to be provided and the mechanism by
which it would be checked. Technical discussion of the merits of
these mechanisms has not swayed their proponents, and what data
is available on existing deployments has not made one choice
obviously superior. Each represents trade-offs, and the working
group has not succeeded in establishing which trade-offs are the
most appropriate for this purpose. These assessments have been
difficult in part because they have been moved out of the realm
of pure engineering by the need to evaluate IPR and licensing
related to at least one proposal in the light of a variety of
licenses associated with the deployed base of MTAs. 

Efforts to reach consensus by compromise and by inclusion have
been attempted on multiple occasions. Despite early hopes of
success after each such attempt, post-facto recycling of
technical issues which these efforts should have closed has shown
that the group remains divided on very basic issues. The working
group chairs and Area Advisor are agreed that the working group
has no immediate prospect of achieving its primary milestone: 

Aug 04 Submit working group document on MTA Authorization Record
in DNS to PS 

Rather than spin in place, the working group chairs and Area
Advisor believe that the best way forward is experimentation with
multiple proposals and a subsequent review of deployment
experience. The working group chairs and Area Advisor intend to
ask that the editors of existing working group drafts put forward
their documents as non-working group submissions for Experimental
RFC status. Given the importance of the world-wide email and DNS
systems, it is critical that IETF-sponsored experimental
proposals likely to see broad deployment contain no mechanisms
that would have deleterious effects on the overall system. The
Area Directors intend, therefore, to request that the
experimental proposals be reviewed by a focused technology
directorate. This review group has not yet been formed but, as
with all directorates, its membership will be publicly listed at
http://www.ietf.org/u/ietfchair/directorates.html once it has
been constituted. 

Concluding a group without it having achieved its goals is never
a pleasant prospect, and it is always tempting to believe that
just a small amount of additional time and energy will cause
consensus to emerge. After careful consideration, however, the
working group chairs and area advisor have concluded that such
energy would be better spent on gathering deployment experience. 

regards, 

Ted Hardie, co-Area Director, Applications 


The upshot is that instead of having a bona fide RFC we will now
have competing proposals in the experimental track and no
"standard" way of handling the anti-forgery effort with our
email. Coincidental to most of these final events an article was
published at internetnews.com which included a very interesting
quote from a Microsoft spokesperson: 

"The SPF technical alternative is just now becoming a real focus
for the IETF. It is premature for the standards participants to
disclose any IP they may own related to SPF. If SPF continues to
work its way through the process, there will likely be a point
where Microsoft and others will [be] asked to identify any
essential IP claims and Microsoft will follow the IETF guidelines
for disclosure at that time." 

That statement and the statements of Harry Katz are obviously,
glaringly inconsistent! What are we to conclude? Did Katz not
know what Microsoft's true intent was? Did he know and yet he
chose to conceal it? I don't know. I do not know Harry personally
and so I will choose to absolve him personally. On the other hand
I cannot and will not absolve Microsoft of their responsibility
for this debacle. It is clear that Microsoft planned and
orchestrated these events with the intent to co-opt the process
and ultimately to own all rights to any resulting work from
MARID. 


What can we do now?

First and foremost if you are involved with open source software
you must not accept Microsoft's license! Larry Rosen has made
that quite clear with his comments and I believe that we must
continue to refuse to accept the conditions Microsoft is
attempting to impose. 

Second, it is obvious at this juncture that innovation and
creativity is being crushed by the horrific state of the US PTO's
approval process. As it stands now there is every likelihood that
Microsoft's patent will be approved, and if it is they will own,
essentially, 100% of the DNS authorization methodology rights.
They would own it and yet this method is currently in its
infancy. Is our need for technologies that contribute to the war
on spam important enough for Microsoft to do the right thing
here? They could, after all, but I suspect they won't! The
evidence we have today clearly shows that they intend to do just
the opposite and given their intransigence on the license issue
they appear to want to drive a wedge between the abilities they
will have and the abilities the open source software community
will have to lawfully use in the war against spam and phishing.
It would be nice if they simply donated the patent applications
to the ISOC. If they don't then someone is going to have to
challenge the patents in court to have them invalidated. The way
the approval process works right now at the US PTO that is
exactly what would have to happen! 

John Glube, who like myself was a MARID participant has written a
piece which tells the same story I have told here. He has made
some concrete suggestions with steps that we could all take right
now. The most important thing, in my opinion, is that we contact
our elected representatives about this situation. We have a clear
opportunity here to present our legislators with the issue and
let them see how the ridiculous situation at the patent office is
doing exactly the opposite of what it's supposed to do. Software
patents do not encourage innovation nor do they help the public.
In fact, the current example clearly shows how a patent
application has seriously harmed an effort to provide some major
technological improvements for the public internet. The logical
question we should ask when this is said is why? The reasons are
many fold but I will try to sum it up in the next few paragraphs. 


When it comes to patents I think we all understand that the
intent is to preserve for an inventor a time-limited monopoly on
an invention's use so that he or she may profit from their work.
I have no problem with that, nor do I think that many thinking
people would. Yet there is a problem when it comes to patenting
software! Understanding the intent of patents is one thing.
Perceiving that the result is the opposite of the intent is an
entirely different thing. If the results of patenting software
are not what was intended can the act still be called a good
thing? Patenting software is not the same thing as patenting a
new kind of engine or pump. Though I believe that algorithms
encoded in software (source code) should certainly be copyrighted
by their authors I do not think that a patent on software is
right or really even possible. We should not provide an artifical
monopoly (patent) on logic or mathematics because both these
fields of endeavor follow and derive from natural law (the laws
of nature). Software is the coded extension of it's mother and
father, logic and mathematics! In the specific case of
Microsoft's patent applications they are using algorithms which
are obvious because they're using existing standards (RFC 2821
and RFC2822 which are, in effect, the natural law Microsoft is
drawing from for their patent application). There is nothing
particularly new or innovative in what they propose in their
application. In fact, if you've ever written a procmail filter
you've done at least a part of what they're proposing. So why
should the US PTO validate their claims? They should not! Yet
because of an apparent lack of funding and time the PTO simply
rubber stamps these things with the rationalization that if
someone wants to and they have a case (usually prior art or
"obviousness") they can have the claim invalidated in court. The
trouble is that it costs money to go to court and most people
cannot afford it. But the PTO cannot afford to properly evaluate
these applications either so they off load the expense on to the
public. This makes it overwhelmingly clear to me that the USPTO
is not qualified or even capable of validating software patents
and rather than do it themselves they are forcing us to do it
after the fact at our own expense! This seems a waste of time,
effort and money on all sides. Thus we should, at the very least,
invalidate the patents on software that exist and declare a
moratorium on their approval until such time as the conditions at
the PTO change. My preference would be that we stop patenting
software forever! 

How is it that we are willing to validate a monopoly on something
whose only real innovation or contribution is simply the
evaluation and presentation of conditions? Are we going to start
patenting the weather report next? When you encode logic and math
you do so to evaluate conditions found in standards or in genuine
natural law. You're doing the same thing with software that the
weather man does every night on television. You're reporting
results after evaluating a condition or state. Software
algorithms evaluate and report conditions, do calculations on
those conditions and then provide the result as output to a human
or as input to another software program. How many ways are there
to add, subtract, multiply and divide? While algorithms can be
well written (even elegant) and they are definitely forms of
expression which can and should bear copyright there is nothing
sufficiently innovative or even marginally original enough about
them to suggest they should be monopolized, even if the monopoly
is temporary. 

Finally, I would just like to say succinctly that creating an
artifical monopoly on software is exactly the wrong thing to do
if you want to encourage the progress of science and the useful
arts. With conditions as they are today patenting software is
accomplishing precisely the opposite. 


Good day!
 

-- 

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.