Subject: Re: A priori IPR choices

From: "Lawrence Rosen" <[email-masked]>
Date: Tue, 23 Oct 2007 19:50:53 -0700

To: IETF list

These are statements from FSF about the issue we've been discussing at
[email-masked]. 

http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.
html 

and

http://www.fsf.org/news/oppose-tls-authz-standard.html 

The GPL does not have problems with most IETF specifications, only those
that are encumbered by non-free patents. This is an important example of why
so many of us in the open source and free software communities believe that
the IETF patent policy must be improved. 

/Larry Rosen

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)

3001 King Ranch Road, Ukiah, CA 95482

707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243

Skype: LawrenceRosen

Author of "Open Source Licensing: Software Freedom and 

                Intellectual Property Law" (Prentice Hall 2004)

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 24 Oct 2007 13:58:28 +0200

Philippe Verdy wrote:

> We do have lots of informational RFCs which are still needed and
> actively used, sometimes even required (notably those in the BCP
> series, like the "Netiquette" which has become a requirement for
> almost all ISP customers, as part of their contract, despite they
> are only informational, and could change at any time after having
> been replaced by another RFC replacing the older one with the same
> BCP number.

BCPs aren't informational RFCs, for an introduction see RFC 4677
or <http://en.wikipedia.org/wiki/Request_for_Comments#Status>.
Maybe you confused BCP with FYI, RFC 1855 is also known as FYI 28.

FLAME ON: It's now 12 years old, and some parts are rather silly:
Be careful with monospacing fonts, and be sure to have a signature
which you attach to your message.
FLAME OFF (flame tags recommended by FYI 28).

 Frank

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 24 Oct 2007 11:33:39 -0700

Not as out of date as some sources
 
http://davidguy.brinkster.net/computer/
 
It was my first computer book.

________________________________

From: Frank Ellermann [mailto:[email-masked]]
Sent: Wed 24/10/2007 7:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: FYI 28 (was: A priori IPR choices)

 Frank

---

From: "Philippe Verdy" <[email-masked]>
Date: Wed, 24 Oct 2007 11:56:50 +0200

The FSF campaigns against the current IETF policy and the current policy
used in several standard bodies (notably ISO) who currently accept standards
encumbered with patents, only if they are licensed to everyone who ask for
it, under “reasonable” or “fair” licensing practices. However the acceptable
licenses are not precisely defined (at ISO, patent licensing royalties are
still acceptable), and notably this does not restrict the licensors from
requiring a nominative agreement with each licensee. Such standards do exist
in ISO (notably most MPEG related applications are covered by such
restrictive licenses).

However, the FSF recognizes that, until now, the IETF was more strict about
the licensing conditions, rejecting proposals that included royalties-maker
licenses and explicit personal agreement between the licensor and the
licensees (under this scheme, if it was accepted, nothing would prevent a
licensor to start charging yearly royalties to each licensor for exercising
the patented rights.

But, the IETF is less strict about RFCs that are published with
“informational” status. We do have lots of informational RFCs which are
still needed and actively used, sometimes even required (notably those in
the BCP series, like the “Netiquette” which has become a requirement for
almost all ISP customers, as part of their contract, despite they are only
informational, and could change at any time after having been replaced by
another RFC replacing the older one with the same BCP number.

I do approve the FSF campaign: if the IETF publishes a RFC, and even if it’s
just informational and still not a “BCP” recommendation, those RFCs should
really be patent free, or exempt from non-free patents requiring an explicit
license. We have already seen in the past the case where a licensor changed
its policy, and started to claim royaltees for what was initially granted
for free and licensed to any one without charge. We can accept the existence
of patents only as a way to prevent another counter-patent to be reserved by
someone else (but in a free world, such patent is normally not needed, as
the copyright assignment and its legal protection is enough to avoid this).

However, the WIPO is currently changing the game, trying to merge the two
systems of copyrights and patents into a single one with equal force,
forcing those that just want a protection of their copyright to register it
at some national or international registry to maintain the protection. This
is a dangerous evolution, because it would harm all legitimate authors that
have produced valuable works, and assigned a their copyright on these works,
to protect it from claims by others: they would now have to pay each year
some fee to a registry to maintain the protection on their own work; if they
just forget to do that, someone else (richer than the authors) will apply
for a patent registration and will pay indefinitely the registry to gain and
enforce the legal protection.

For this reason, we should only accept patents that are protected with the
following minimum bases:

*	Licensed to anyone without condition, and in every country (within
the limitations of the national laws applicable to the licensors, such as
export/import controls, but at the time of proposal or publication of the
standard, such legal restrictions should not exist, and the IETF should
invite all governments to rapidly express their reservations against legal
restrictions in their area, by submitting also a copy to ISO members where
worldwide governments are represented).
*	(If legal restrictions exists and are known to the IETF or to the
standard proposer, they MUST signal them, so that every licencee car verify
if the standard is usable for their intended application).
*	Licensed only in a non-exclusive way (no licensee can claim
ownership or reservation within some domains of application or exercise of
the patent, or reservation in any place, against other competing licensees):
all licensees being treated equally, whatever the time when they first got
their license.
*	Does not require an explicit agreement between each licensor and
licensee.
*	Grants usage and distribution rights to anyone, acting then as a
legal sublicensor: the sublicensor must not forbid the exercise of the
distribution right by its own licensees.
*	Being granted without limitation of time, including the distribution
right (so that new licensees can always come and apply the same terms).
*	Offers a warranty (signed by the patent owner) to licensors that the
patent does not violate any other patent or copyright or author’s rights.
*	Making this warranty permanent too, and without requesting any
charge to pay by the licensees and distributors (including the IETF).
*	Offer a signed warranty of indemnification of licensees and of the
IETF if the patent licensor has violated these rights.
*	Stating contractually that no further charges will be requested to
all licensees in the future by the patent owner.

With all these conditions, patents are in fact not needed. We much prefer
the system of copyrights which is much simpler to protect open and free
technologies.

If needed, all RFCs published by the IETF should first pass a long enough
transitory period where the RFC is published but with strong notice that it
is not approved, so that the only rile of the publication is to verify that
the RFC does not violate any rights. After this time has elapsed (2-3 years
after first publication?) during which the other patent owners have had the
possibility to exercise their rights, the RFC could be only be in an
informational state, becoming a recommendation later.

*	The IETF should also make some efforts to propose alternatives to
every published standard, so that at least one replacement technology is
also published with the same status, allowing applications to implement
several of them, and possibly turning down rapidly, with less efforts, any
technology for which a patent becomes applicable. The BCP standard track
should list the alternative technologies, and not promote only one.
*	In addition all standard should support optional additions and a
framework for making these options interoperable with other implementations
of the standard that don’t have this option. This will ease the replacement
of one technology by another if there is any problem with a technologies
that was informally considered ”the best” one (but appears to be now
encumbered by costly patent claims). In fact this should be the role of
standards: not promoting a single technology, but providing this free
framework for interoperability. The “requirements” in a standard should be
only about interoperability, not about an exclusive implementation solution.
*	So supporting the extensibility should be a requirement for
conformance. If a “standard” does not support extensibility, it should be
deprecated or another newer standard should be created rapidly as an
accepted alternative, within which the currently deprecated standard would
just become a particular implementation.

  _____  

De : Lawrence Rosen [mailto:[email-masked]] 
Envoyé : mercredi 24 octobre 2007 04:51
À : [email-masked]
Cc : [email-masked]
Objet : Re: A priori IPR choices

To: IETF list

and

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Oct 2007 13:17:08 +1300

(Cross posting removed)

On 2007-10-24 22:56, Philippe Verdy wrote:

...
> licensor to start charging yearly royalties to each licensor for exercising

In that case the FSF recognized wrong... the IETF has often approved standards
track documents with IPR disclosures setting RAND conditions.

On 2007-10-26 21:13, Norbert Bollow wrote:

...
> The question is this:  Is copyleft open source / free software so
> unimportant with regard to any area of internet standards that it
> would be justifiable to adopt any specification with fundamentally
> incompatible patent situation as a standards-track RFC?
> 
> I believe that the answer to this question very clearly is no!

Norbert, you seem to miss the point that the IETF's criterion
for advancing documents along the standards track is *empirical*
(has interoperability been demonstrated in the real world?) and
emphatically not faith-based (do we *believe* that the standard is
good and the IPR issues unimportant?). The question at issue is
whether we should change the empirical criteria to explicitly include
the availability of at least one implementation that is both
interoperable and free.

On 2007-10-27 07:22, Hallam-Baker, Phillip wrote:
...
> It is not a major change in principle. But it does have some practical changes.
> 
> When we chartered KEYPROV I was told that the IPR regime should not be in the charter, this was not a concern to me there because all the proposals were OK IPR wise. But I do want to have the option of the forcing function in the charter as explained. This is standard in OASIS and in W3C there is only one regime that the WGs can chose.

I think it really is an enormous change in principle, from
an empirical to a faith-based approach.

On 2007-10-27 08:06, SM wrote:
...
> Patents do raise some concerns about interoperability in regards to open source/free software.  From a technical point of view, there is nothing that prevents implementation if the specifications are available.  But then, we are taking a narrowed view of interoperability. 

Well, that's exactly the reason for the IETF's empirical approach;
we don't even need to consider IPR as a separate issue when testing
interoperability. The simple existence of interoperable implementations
tells us that IPR conditions must be reasonable. If we extend that to
include at least one free implementation, that tells us that IPR
conditions for free software must be reasonable. QED.

     Brian