DocumentTag Date: Sat, 18 Feb 1995 16:07:35 -0800
To: Christian Huitema / Chair of Internet Architecture Board
From: Dave Crocker
Subject: Formal IAB appeal: IESG prudence or paralysis?
IETF rules provide for appeal to the IAB, when there is disagreement with an IESG decision. It is with considerable sadness that I must file a formal “appeal” against the IESG for its IN-action, rather than action. They have had a task on their plate for an excessive period of time and appear to be unable or unwilling to resolve it. I am therefore asking you, the IAB, and the rest of the Internet technical community to review the matter and to bring it to an immediate and constructive conclusion.
The task in question is the hand-off of ownership of the RPC and XDR specifications from Sun Microsystems to the IETF. This task has been on the IETF plate for approximately two years (years!) Previously, the IESG authorized a working group to do the technical review and refinement of the specifications. The working group was created and operated in the usual IETF style and completed its technical work quickly and long ago. The working group activities were straightforward and were notably lacking in controversy. The community and the working group participants did their job. However, further processing of the work onto the standards track has been blocked by the IESG’s inability to complete a rather simple letter of agreement between the Internet technical community and Sun. An entirely reasonable version of that document was completed over one YEAR ago.
THE OTHER SIDE OF THE COIN & SOME BACKGROUND
This is the first time that the IETF has attempted to receive technology developed in a proprietary context, so it is reasonable and appropriate that the process be done carefully. In fact, it is essential that it be done VERY carefully. After this much time however, we must ask whether the duration of the process represents reasonable prudence or institutional paralysis. In my opinion, we are suffering from the latter, not benefiting from the former.
The general question of IETF receipt of proprietary technology has been under study for approximately four years, including numerous consultations with attorneys. The specific opportunity with RPC/XDR arose approximately two years ago. A core difficulty with this issue is that the IETF has no legal context. It is not a legal entity. Among other things, this means that it cannot sign documents. Concerns such as this were at the core of the formation of the Internet Society. Hence, it was to ISOC that the IESG turned when the RPC/XDR opportunity arose. Unfortunately, this path proved entirely unproductive, while causing many months of delay. Surprisingly, the IESG again turned the matter over to ISOC recently. The response from ISOC’s attorneys continues to provide a basis for open-ended delays.
I was the cognizant IETF area director for the RPC/XDR two years ago and pursued the relevant discussions and relevant drafts of an agreement over the course of one year. In my view, the Internet protocol suite can benefit from the addition of technologies of this type. That was also the consensus among the Internet technical community.
At least one year ago there was, in my opinion, a reasonable draft agreement developed. I am not an attorney and consequently cannot render an opinion on “legal” adequacy of the document. However, the document covered all of the issues that either side sought to raise over the course of several months of discussion. Further the process of developing the agreement was quite comfortable. That is, Sun was direct, open and flexible in the discussion. I believe that this agreement will be a contract between Sun and the Internet technical community. As such, it is a “social” contract, more than a legal one. As such, one’s sense of “comfort” with their handling of the negotiation is particularly important. It provides a basis for developing one’s sense of Sun’s likely future behavior with respect to this technology and the IETF. I should also mention that the community was quite forceful in expressing concern’s about Sun’s possible behavior and expressed those concerns at the Amsterdam BOF and over public discussion, as did I during the many private meetings I held with Sun staff. The IETF has a certain style of open, fair, and highly independent decision making. It applies to this matter as to all others and that fact was repeatedly made clear to everyone participating in the discussions, including Sun. It was also added as a clause in the draft agreement of one year ago.
After I resigned as area director last Spring, the matter was pursued by the IESG casually until last Fall, when I probed the IESG formally. There was a spurt of activity, explicitly intended to expedite resolution. Unfortunately, the specter of legal concerns has continued to haunt this document. I have had numerous conversations with many IESG members on this matter, over the last 6 months. It is clear that there will be no progress made without intervention. Comments from IESG members and ISOC personnel make it clear that fear of legal repercussions has paralyzed those involved on behalf of the IETF.
Along with the general legal concerns, assorted specific issues have been raised during some discussion. These divide into assertions about requirements FROM Sun and about special treatment OF Sun by the IETF. Let me try to quash those here and now. Beyond the usual little wrinkles that show up in any negotiation, Sun has been extremely flexible in their position. In particular, they have imposed no requirement that the document be a formal, legal one, and they have imposed no requirement that the IETF standardize XDR or RPC. The draft agreement of one year ago specifically provided for an “exit” condition should standardization not occur. On the matter of special treatment, there has been clear, repeated and forceful communication to Sun and others that the rules of the process are equally applicable to all; Sun is getting NO special treatment. An obvious example of this assertion is the usual IETF requirement that the IETF acquire change control (i.e., “own”) the technology.
LEGAL RISK & CREATIVE SOLUTIONS
It cannot be denied that anyone affixing their signature to an agreement with Sun, on behalf of the IETF, leaves themselves open the legal actions taken against them. In fact in general, one must note that binding this activity to the usual legal processes has been the basis for the paralysis, with an apparent promise that the paralysis will continue into the indefinite future.
The IETF is a master at developing unusual solutions to difficult problems, without losing sight of first principals for pragmatics. This is true for its own processes as well as its technical work. Hence, it has been suggested that the document be signed not by the formal “officers” such as the IETF chair, but rather by other participants from the community who are willing to step forward. At least one participant has offered so far, in addition to myself and I suspect that more offers are readily available. No doubt this is not the only alternative that can be taken to bring this matter to a productive conclusion, but it is available and reasonable.
The ISOC has had the matter of legal issues pertaining to moving proprietary technologies into the IETF for roughly 4 years. There is no firm schedule for their resolving this matter and the pattern over the last four years suggests that the matter will not be resolved by them anytime soon.
The IESG has had the matter of IETF acquisition of Sun’s ONC RPC/XDR technology for roughly 2 years. There is no firm schedule for their resolving this matter and the pattern over the last 2 years — and especially the last few weeks of private discussions — suggests that the matter will not be resolved by them anytime soon.
Meantime, Sun and the Internet technical community await completion of the agreement, so that the community can pursue its consideration of RPC/XDR standardization. They have been waiting far too long.
I am asking you, the IAB, and the Internet technical community to consider and decide upon the following:
1.Does the IETF wish to be able to pursue the “friendly take- over” of proprietary protocols?
2.Does the IETF continue to wish to do such a take-over of RPC and XDR and pursue its standardization, as it decided in 1993?
3.Does the IETF wish such pursuit of RPC/XDR to be done in a timely manner, keeping in mind that two years have already passed and the relevant technical work is long done?
4.What method should be used to conclude the agreement between Sun and the IETF?
I am attaching a proposal for resolving the matter through the development of a “social” contract between Sun and the IETF. The purpose of the mechanism is, quite simply to relieve anyone who is uncomfortable from having to affix their signature to the agreement, instead allowing others from the community to do so. In particular, the validity of the agreement would be established by a variant of the usual IETF community rough consensus process.
Again I must express my sadness at being compelled to file this formal appeal to the IAB. However, the matter has been blocked too long and there is no indication that progress will be made anytime soon. So, I urgently request that you pursue it to a timely resolution.
Subject: Proposal for a Social Contract
This document proposes community discussion and assessment of rough consensus to permit community approval of an agreeement with Sun Microsystems, to allow IETF pursuit of standardization for ONC RPC and XDR.
In late-1993, the IESG chartered the ONCRPC working group to prepare documents “that describe ONC RPC to reflect the current state of the deployed and accepted technology, and submit them for Internet standardization”. This working group was chartered after the community expressed considerable interest in having the ONC RPC technology enter the Internet’s standards-track. The working group completed its work in June of 1994.
According to RFC 1602, before the IESG can enter a technology onto the standards track, any issues of intellectual property rights must be resolved. In those cases where ownership of a technology is asserted, the owners must execute an agreement with the Executive Director of the the IETF Secretariat. Unfortunately, the procedures defined in this section of RFC 1602 have no prior operational experience.
Work to develop an agree began in early-1993. Despite activity with respect to this goal, little progress has been made. Before the IESG can issue the last call with respect to advancing the drafts produced by the ONCRPC working group to proposed standard status, this matter must be resolved.
The core of the problem is that any agreement between the owner of a technology and the Internet Technical Community (ITC) involves judgement and negotiation to define the appropriate technology and the legal document delivering the appropriate rights. The process in RFC 1602 is unworkable because it does not empower any ITC representative to negotiate, and because the IESG lacks the legal basis necessary to validate any agreement as meeting the spirit of RFC 1602 in cases where agreements are not clearly equivalent to those specified in RFC 1602.
One alternative is that any agreement should be between an owner and the Internet technical community — it is a “social” contract with the community, not a legal contract between entities — as there is no legal entity which acts of behalf of the Internet community. Such a social contract would be approved by the ITC, in the usual method of rough consensus, and would signed by volunteers from the community rather than the designated managers of the IETF technical standards process.
In the medium-term, it is clear that RFC 1602 must be revised to incorporate workable procedures. It is the intent of the IESG to re-activate the POISED working group, for the purpose of producing a successor document, which will then be subject to community consensus.
However, there are many issues for the POISED working group to address, and it will be sometime before a successor document will enter the Internet’s standards-track.
This proposal asks the community for a more timely solution with respect to ONCRPC, as that effort has been underway for two years.
The proposal asks the Internet community to grant a one-time exemption from RFC 1602 and direct the IESG to issue the last call for the drafts produced by the ONCRPC working group to move ONCPRC onto the standards track. Addditional advancement will comply with procedures in force at the time.
Specifically, the proposal is for the following:
•Interested parties are encouraged to participate in an open discussion on whether the IESG should be directed to issue a last call for the drafts produced by the ONCRPC working group to be published as proposed standards. This discussion will conclude by March 20th.
Discussion should focus specifically on whether the IESG is directed to issue the last call. Specifically, general discussion on reforms on RFC 1602 or on the drafts produced by the ONCRPC working group is inappropriate.
•One week prior to the Danvers meeting of the IETF, the IESG will gauge whether it feels that there is community consensus on this matter, and announce its decision to the community.
•If there is a positive consensus, then at the Danvers meeting of the IETF, there will be a plenary session in which any and all interested parties may sign the “social contract” (attached below) on behalf of the Internet community (members of the community unable to attend may electronically transmit their signatures). A represetative from Sun will sign on its behalf.
Afterwards, the IETF Secretariat will post the last call. Of course, when the successor to RFC 1602 is approved, the drafts produced by the ONCRPC working group will be subject to those procedures.
Otherwise, if there isn’t a positive consensus, any last call will be delayed until after the successor to RFC 1602 is approved by the community. At that time, this issue will be re-opened.
*DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT*
AN AGREEMENT BETWEEN
THE INTERNET ENGINEERING TASK FORCE
SUN MICROSYSTEMS, INC.
IN THE MATTER OF
ONC RPC AND XDR
1. For good and valuable consideration, receipt and sufficiency
of which is hereby acknowledged, Sun Microsystems, Inc. (“Donor”)
hereby grants to the Internet Society and the Internet
Engineering Task Force, their officers, employees, the IETF
Secretariat and contractors (“Licensees”) for the sole purpose of
making Donor’s Open Network Computing (“ONC”)
Remote Procedure Call (“RPC”) and External Data Representation
(“XDR”) (together the “Technology”, the technical specifications
of which are defined in Exhibit “A” attached hereto and
incorporated herein by reference) an Internet standard, a cost-
free, perpetual, non-exclusive, worldwide right and license under
any copyrights, patents or other rights in Donor’s Technology to
use, reproduce, modify, distribute, propose, test, develop,
analyze, enhance, revise, adopt, maintain, perform and display
publicly, and prepare derivative works that are based on or
incorporate all or part of the Technology, and to reproduce,
distribute and perform or display publicly any such derivative
works, in any form and in all languages (computer and foreign),
including the right and license to use the marks “ONC RPC” and
“ONC XDR” (“Marks”) in association therewith, and to authorize
others to do so. Donor agrees to permit Licensees to use Donor’s
name and address to indicate the original source of the
2. Donor further exclusively transfers to Licensees the worldwide
right and license to further evolve, develop and modify the
Technology for the purpose of making the Technology an Internet
Standard through the Internet Standardization Process (as
specified in RFC 1602 or its successors), including the right and
license to use the Marks in association with any such
modifications, and to authorize others to do so. In particular,
Donor acknowledges that if it performs any evolution, development
and modification of the Technology outside of the Internet
Standardization Process, that this should be clearly indicated as
being a non-standard development, and that no reference to the
Internet Standards Process is allowed for any such Technology
developed outside of the Internet Standards Process.
3. Donor hereby acknowledges that Licensees assumes no obligation
to maintain any confidentiality with respect to the Technology
licensed hereunder, and Donor represents that, to the best of its
knowledge, there are no infringement claims against the
Technology. Donor represents that the Technology was not prepared
jointly with others. Licensees acknowledge that any rights not
expressly granted herein are reserved by Donor.
4. Donor hereby acknowledges that Licensees have no duty to
publish or otherwise use or disseminate the Technology,
including, in particular, an obligation to raise the Technology
to the Internet standards-track. In the event the Technology is
elevated to Proposed standard level, Donor hereby agrees to
license the Technology to others under substantially similar
terms as those licensed to Licensee herein at no charge (with the
exception that such use of the Technology by such Licensees shall
be for purposes other than making the Technology an Internet
Standard), so long as such licensees of the Technology implement
the Internet standard. In the event the Technology is not
elevated to Proposed standard level within 24 months of the
execution of this agreement, then Section 2 of this agreement is
null and void.
5. THE TECHNOLOGY IS PROVIDED TO LICENSEES “AS IS”, AND ALL
REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY AND
NONINFRINGEMENT ARE HEREBY DISCLAIMED.
6. IN NO EVENT WILL DONOR BE LIABLE FOR ANY LOST REVENUE, PROFIT
OR DATA, OR FOR DIRECT, SPECIAL, INDIRECT, CONSEQUENTIAL,
INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF
THEORY OF LIABILITY ARISING OUT OF THE USE OR INABILITY TO USE
THE TECHNOLOGY, EVEN IF DONOR HAS BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGES.
7. This Agreement constitutes the entire agreement between the
parties concerning its subject matter, and supersedes all prior
written or oral agreements and discussions. All additions or
modifications to this agreement must be made in writing and must
be signed by an authorized representative of each party. If any
term or condition of this Agreement is declared void or
unenforceable as provided herein or by a court of competent
jurisdiction, the remaining provisions shall remain in full force
and effect. The parties agree to comply strictly with all
applicable export control laws and regulations. Where no U.S.
Federal law governs, this agreement will be governed by the law
of the State of California without reference to its conflict of
for Sun Microsystems, Inc.
for the Internet Engineering Task Force:
*DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT* *DRAFT*
Date: Tue, 28 Feb 95 21:51:54 GMT
From: William Allen Simpson
Subject: Formal IAB appeal: IESG paralysis and inactivity
From: Christian Huitema
The IAB has noted your appeal. We plan to conduct a public review of this matter during the open meeting of the IAB, in the Danvers IETF. We will make sure that adequate time is allocated for this review by scheduling an extension to the open meeting.
If all such appeals are to be in open forum, and we have to wait for an IETF Plenary to be held to consider an appeal, please add formal appeal of the IESG inactivity regarding PPP Compression to your docket.
The PPP WG submitted PPP Compression over a year ago.
Motorola sent a letter to the IETF. The IETF Secretariate has refused to disclose the contents of that letter, despite repeated verbal and written requests.
Motorola has failed to respond to my formal request for information.
Investigation showed that Motorola is claiming patents on 2 aspects of VJ Header Compression and IPX Header Compression. (Which are not in any way related to PPP Compression.)
Motorola has failed to respond to my formal notice that I personally have violated their patent claim(s), by relying on works published more than a year prior to their claims.
To: Christian Huitema
From: Dave Crocker
Subject: IESG Appeal: Constructive insecurity
Christian, members of the IAB, and members of the IETF technical community:
You requested contributions to aid IAB consideration of the formal appeal made to it. This appeal was initiated as a result of IESG failure to make progress with respect to IETF standardization of ONC RPC/XDR and failure to otherwise deal with the difficulties surrounding IETF acquisition of change control over formerly proprietary technology. The generic issue was before the IESG for four years and this specific matter for two years.
I am delighted that recent efforts have almost achieved the necessary signed agreement between SUN and ISOC (on behalf of the IETF) thereby allowing continued processing of the ONCRPC working group effort. This would seem to remove the cause of the appeal to the IAB.
However the nature of the process and events which led to the appeal, as well as comments by others to the IETF mailing list as a result of the appeal, suggest that there are some basic concerns about IESG role and style that need addressing. I believe that this appeal process can be valuable in providing an opportunity to discuss relationships and expectations, leaving the details of resolution to the planned, renewed POISED effort.
Let us be clear about a very basic point: Now and in the past, the IESG comprises people with considerable track records of achievement. Any group-wide problems with the IESG threfore are likely due to inadequacies in their selection criteria and/or inadequacies in the “job definitions” which guide IESG members and/or in the ongoing community interactions with the IESG. It is my hope that the community will treat the current situation as an opportunity to clarify the requirements for IESG — and IETF community — performance, rather than as an opportunity to cricize anyone’s behavior.
My own belief is that there are three major issues needing improvement:
1. Working groups are required to commit to a schedule and then to make forward progress, as well as to conduct their efforts in an open, fair and consensus-based manner. When a working group fails to make forward progress, it is held accountable. Other than periodic renewal/replacement of area directors, no specific accountablility exists for the IESG. It is therefore possible for issues on the IESG’s table to sit forever. We need to get more frequent and more detailed reporting by the IESG to the community. At the same time, we need better community attention to that reporting.
2. The IESG is subservient to the IETF, and not to any document the IETF produces as a representation of its process. A fundamental strength of the IETF has been its ability to adapt quickly and creatively to unusual problems, particularly by consultation with the community. I believe the the current operation is mechanical and bureaucratic, losing the basis for our strength.
3. The IESG is intended to administer IETF policies, rather than to set those policies. When there is a question about policy, it is imperative that the IESG consult its authority: the IETF. I believe the IESG has lost its sense of urgency in this requirement. More than anything, it is the responsibility of the community to re-assert its role and relationship with the IESG.
As an original member of the IESG, I’ll claim that during its early years the IESG benefited from strongly enforced insecurity. It had no real authority and was constantly kept in line by pressure from “below” and “above”. On the one hand, the IAB made it clear that the IESG needed in all cases to defer to the IAB; on the other hand, the IETF community was quite forceful in pushing back on IESG feedback/decisions/behaviors with which it disagreed. In my opinion, this caused the IESG to be extremely sensitive to community needs and consensus, frequently resorting to pulic consultation. In my opinion, this is far less true today, in spite of excellent intentions by IESG members.
We now view IESG area directors as having real and of being the definitive source for major decisions. We need to change this and encourage the IESG to renew its history of consulting the IETF population whenever serious and difficult issues emerge.
Date: Wed, 22 Mar 95 02:14:04 GMT
From: William Allen Simpson
Subject: Formal IAB appeal: IESG paralysis and inactivity
Date: Wed, 22 Mar 1995 01:07:43 +1100
From: Robert Elz
A couple of weeks ago, or so, you sent a brief appeal type message to the IAB.
If you want to continue with that, please send a much expanded message detailing exactly what you’re complaining about, and what you’d like done about it.
Please send something, one way or the other, today, to firstname.lastname@example.org – our next phone conference is tomorrow morning (early) your time, if anything is going to happen in the near future about this, we wwill have to talk about it then.
You can cc the ietf list if you want – you should if you’re deciding to abandon the thing, as your original message was cc’d there I believe.
This is certainly propitious, as it was one year ago today (still the 21st here) that the Last Call was issued. Unfortunately, this leaves little time to formulate the response. I will follow Dave Crocker’s example outline to help things along.
This is a formal appeal of inaction by the IESG, pursuant to RFC-1602
section 3.6. The IESG has not made a “final determination on whether or
not to approve the standards action” in “a timely fashion”, as required
by RFC-1602 section 3.1.2.
1) After more than 2 years of discussion and WG consensus building,
the Chair of the PPPext WG asked the IESG to publish a set of
drafts concerning PPP Compression negotiation as Proposed Standard,
together with several compression mechanisms as Informational.
2) I was the WG Editor during this period. I am listed as Author of
some of the drafts, and assisted in writing several others.
3) The Last Call was issued Mon, 21 Mar 94 [Exhibit A]. The
expiration of the Last Call was supposed to be April 11, 1994.
4) Soon thereafter, in response to a claim by Motorola, the
Compression Control Protocol author privately circulated an
Appendix to his draft. The language in this Appendix violated
requirements of RFC-1602. The Appendix was never posted as an
5) On Thu, 14 Apr 94, I brought this matter to the attention of Vint
Cerf [Exhibit B], as Chair of the ISoc, for examination by the ISoc
attorneys which serve the IESG in its decision making.
6) No communication was received from the ISoc attorneys.
7) After waiting for several months, and having received no
communication from the IESG as to the disposition of the drafts,
I inquired of the IETF Secretariate as to when the decision was
scheduled. No time had been scheduled.
8) Eventually, I learned from the WG Chair that Motorola had sent a
letter of some kind to the IESG or the IETF.
9) I repeatedly requested a copy of this letter from the Secretariate.
On Mon, 13 Jun 94, I was refused a copy of this letter [Exhibit C].
10) Investigation of the U.S. Patent numbers that were included in the
proposed Appendix showed that Motorola is claiming patents on two
aspects of Van Jacobson TCP/IP Header Compression [RFC-1144].
11) The dates of application for these patents are both long after Van
Jacobson first published his compression technique.
12) In any case, TCP/IP Header Compression is not a topic of the PPP
13) There are multiple interoperable implementations. With any
reasonable timeliness, the protocols would now be at Draft
Standard, or even Full Standard.
14) As of this time, the IESG has failed to reach a decision.
WHEREFORE, I am asking the IAB, and the rest of the Internet Technical
Community, to review the matter, and to bring it to an immediate and
A. Has the IESG acted in a “timely fashion”?
Petitioner says No. More than one month has passed.
B. Is there a limit to the “timely fashion” in which the IESG is
required to act?
Petitioner says, Yes. It is the next IESG meeting after the
expiration of the Last Call.
C. Has the ISoc provided sufficient assistance to the IETF in
resolving the legal issues?
Petitioner says, No. Petitioner is unware of any ISoc assistance.
D. Has the Secretariate provided sufficient assistance to the IETF in
resolving the procedural issues?
Petitioner says, No. The Secretariate has deliberately blocked
communication, and failed to schedule a time for resolution.
E. Can a letter from any entity block publication of IETF writings?
Petitioner says, No. For publication in the US, there is a
constitutional prohibition against prior restraint.
F. Is delay of publication an appropriate response to a threat?
Petitioner says, No. Any such threat should be followed by
accelerated and widespread publication, even as Informational.
G. Are the patent claims applicable to the Proposed Standard in
Petitioner says, No. Those drafts affected by any patent claims
are to be published as Informational.
H. Shall the IESG immediately publish the drafts?
Petitioner says, Yes.
William Allen Simpson
Madison Heights, MI 48071
Cc: IESG cc: email@example.com
From: IESG Secretary
Subject: Last Call: The PPP Compression Control Protocol (CCP) to Proposed
Date: Mon, 21 Mar 94 18:06:05 -0500
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider “The PPP Compression Control
Protocol (CCP)” for the status
of Proposed Standard.
Associated with the CPP protocol are the following five internet-drafts
which will be considered for publication as Informational RFCs:
1. PPP Stacker LZS Compression Protocol
2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol
3. PPP Gandalf FZA Compression Protocol
4. PPP Predictor Compression Protocol’
5. PPP BSD Compression Protocol
The reason that the various algorithm documents are not on a standards
track is because patents apply to these and some represent businesses
of their author’s companies. There can, therefore, never be multiple
interoperable implementations of same. The documents are structured in
this way specifically to enable businesses to persue their courses with
minimum impact of their patents and claims on the standard or the
process that generates it.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
firstname.lastname@example.org, or email@example.com mailing lists by
April 11, 1994.
Date: Thu, 14 Apr 94 21:17:31 GMT
From: William Allen Simpson
Subject: legal implications of compression
Have some legal implications in the compression text that Dave Rand
wrote. Fred Baker told me I should ask your lawyers, since you have
possible litigation. Am including the Internet Society, as
intellectual property claims are a current concern in our
I think that since this language will be STANDARDIZED forever, we don’t
want this kind of material. For one thing, it will give implied
acceptance by the ISoc, which may be harmful to contesting the patents.
Also, it is my understanding that people implementing will be subject
to “estoppel” (or some such legal term) of defending against the patent
claims, if they knowingly implement a contested claim.
I also think we should leave the author’s opinion out.
I think that it would be wiser to have shorter and simpler language,
Patents have become prevalent in the software industry, and
especially so in the area of lossless data compression. The
reader is advised to review the most recent Frequently Asked
Questions for Compression, available by anonymous FTP from many
mirror sites, including oak.oakland.edu in
Here’s what Dave wrote:
At this writing, there are some specific considerations that
must be addressed prior to releasing an implementation of CCP.
Patents have become prevalent in the software industry, and
especially so in the area of lossless data compression. While
the following is by no means an exhaustive list, the implementor
is encouraged to read and understand US Patents #5,130,993
(Gutman et al. “Transmitting encoded data on unreliable
networks”) and #5,245,614 (Gutman et al. “Vocabulary memory
allocation for adaptive data compression of frame-multiplexed
These two patents are under careful review by a number of
individuals and companies, with respect to the Compression
It should be noted that these patents may be relevant to
implementations that do NOT use a reliable data link, such
as the one described in the “PPP Reliable Transmission” .
These patents may also be applicable to those implementations
that have a single point of attachment to a multiple destination
network, such as Frame Relay.
In the author’s opinion, implementations that use a licensed
compression algorithm, a reliable data link, and use only
point to point dialup or leased lines, are not affected by
these patents. As always, exactly what is covered by
patents is best discussed with a patent attorney.
It is not the author’s desire to cause implementors to infringe
on existing patents, and there may be other patents that
cover other portions of the combined compression/PPP stack.
Please review existing patents carefully prior to releasing