Subject: [Rmt] Is RFC 3450 patent-encumbered?

From: Andrew Marlow <[email-masked]>
Date: Wed, 08 Oct 2003 12:44:05 +0100

In RFC 3405 I came across the following:

7.  Intellectual Property Issues

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

What does this mean? I note that the confusing phrase
"Intellectual Property" is used. Does this mean that
RFC 3405 is patent-encumbered? Or that it might be?
I am interested in the possibility of open source
implementations of this std. Would such a thing
be prohibited?

I am VERY disappointed to see such a paragraph
in an RFC. This suggests (to me at least) that
IETF stds might not be open any more but might
be owned and controlled by the companies involved
in their creation, which then attach strings to
the use of such stds. I hope I am wrong but this
parahgraph is worrying.

Regards,

Andrew Marlow
----
There is an emerald here the size of a plover's egg!

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: julien maisonneuve <[email-masked]>
Date: Wed, 8 Oct 2003 14:36:20 +0200 (MEST)

> Date: Wed, 08 Oct 2003 12:44:05 +0100
> From: Andrew Marlow <[email-masked]>
>  10/08/2003 13:46:25
> 

AFAIK only a patent can cover intellectual property in this domain.
So yes, there is probably a patent pending. You have to check the
patent claims to see whether they cover your application.

> I am VERY disappointed to see such a paragraph in an RFC. This
> suggests (to me at least) that IETF stds might not be open any more
> but might be owned and controlled by the companies involved in their
> creation, which then attach strings to the use of such stds. I hope
> I am wrong but this parahgraph is worrying.

This is assuming that the presence of patents in standards would be a
new thing. It is not. 

The IETF - like several other std bodies - requires disclosure of
patents whenever a document is promoted to standard. The existence of
a patent doesn't mean that something will not be standardized, but
non-patented alternatives may be preferred if they perform similarly.
Also, whether a pending patent application should be disclosed is
still grey area.

And it may be getting worse :
http://www.lightreading.com/document.asp?site=lightreading&doc_id=41487

The problem related to software patents is only going to get bigger
with time. It is already messing the picture in Europe where the
patent law must go from a sensible perspective to the american way in
order not to disadvantage the local industry.
However, failing a change in the American law and patent process,
nothing is going to change (except for the worst). Patents in their
overly broad variety are there, and patents will generally exist for
most ideas proposed as a standard.

You cannot require std bodies to approve only non-patented ideas,
because otherwise they will just stop working, and standardization
will happen in bodies with more patent-friendly environments (such as
industry foras).

Regards,
					Julien Maisonneuve.

Not representing the views of my employer.

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 8 Oct 2003 11:01:12 -0700

That phrase was added to RFC3450 at the request of the IETF because certain
FEC codes that could be used in the ALC standard are covered and protected
by patents, but not all FEC codes are.  Thus, open source implementations of
the standard are not prohibited if you use unprotected FEC codes, but if you
decided to use FEC codes that are protected then you would need to get
permission/a license to do so.  If you look at RFC 3453 (which provides a
general overview of FEC codes known at that point in time) then you will get
a general idea of which FEC codes known at that point in time are protected
and which are not by looking at the references.  If you look at RFC3452
(which is the building block that describes the way to specify and use FEC
codes in RFC3450) then you will see that there are two types of FEC Encoding
IDs: Fully-Specified and Under-Specified. For a Fully-Specified FEC Encoding
ID a full public description must be available, and generally these types of
FEC codes are unprotected open intellectual property.  For an
Under-Specified FEC Encoding ID, they may be only partially described (e.g.,
a pointer to a product in which they are used) and can be proprietary.  This
plug-and-play convention was designed to allow anyone to use the standard
without forcing them to use proprietary FEC codes, but also allows those who
want to use proprietary FEC codes and still use the standard to do so
without giving up their protection rights.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Andrew
> Marlow
> Sent: Wednesday, October 08, 2003 4:44 AM
> To: [email-masked]
> Subject: [Rmt] Is RFC 3450 patent-encumbered?
>
>

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 09 Oct 2003 09:47:41 +0100

in addition to this, lets say that this is a really common problem and
solution to many areas of standardisation where coding techniques are
sometimes protected - look at gazillions of the AVT WG standards -t
hey have codepoints for free audio and video codings, and codepoints
for patented ones...

the same problem also occurs at low (sub-ip) levels ...

personally, i think its ok (though not ideal), so long as there are
reasoanbly efficient free alternatives - its a free market  - you can
use uucp or x.25 or ipv6 if you dont like the ipv4 internet standards 
(hey, check out the number of mpls related patents:)

In missive <[email-masked]>, "Michael Lu

 >>> There is an emerald here the size of a plover's egg!

 cheers

   jon