I would like you to realize, though, that many people will see a vast difference between approving a standard that may (or may not) be encumbered by an unforeseen patent and knowingly approving a standard with strings attached. The difference is one of the reasons the FSF exists - to promote the awareness that patenting of software hinders progress. In this case, RedPhone's licensing of TLS-authz (which looks to be a widely adoptable standard) is incompatible with GPL, LGPL, Mozilla 1.1, and Apache2.0 licenses due to restrictions in field-of-use.
The reason that hundreds of people wrote in at the last minute, Noel, is because they were concerned. They were concerned because of a push from the FSF, and though the effect was irritating to those of you on the list, the impetus was valid. TLS-authz per this standard cannot be integrated into Free Software - which is a major problem for anyone using a monolithic software or a software without a plugin architecture that would including the functionality outside the application's license. If the IETF had detected these problems - namely that the patent license required was incompatible with the licensing of some double-digit percentage of the software effected - than we wouldn't have bombed your list at the last minute in a last attempt to apprise you to this problem.
Your quote:
It is also worth remembering that almost no technology is unencumbered these days. Indeed, we mostly don't know when it is. So it's pretty naive to think that the IETF (or anyone) can only approve unencumbered technology (despite what we may wish).
Is invalid. What this states is equivilent to "Eating an apple that might be rotten tastes as bad as eating an apple that we know is."
peace,
Ryan McIntosh
Software Architect
PeaceWorks Computer Consulting
ph: (204) 480-0314
cell: (204) 770-3682
ryan@xxxxxxxxxxxxx
----- Original Message -----
From: Noel Chiappa
To: ryan@xxxxxxxxxxxxx
Cc: jnc@xxxxxxxxxxxxxxxxxxx
Sent: Wed, 11 Feb 2009 21:47:18 -0500 (EST)
Subject: Re: RE proposed standard draft-housley-tls-authz-extns-07
> My apologies, Noel.
Don't worry about it. It's really the FSF who is guilty - they suckered you
all into doing their dirty work.
> Just so it's clear - my comments were in support of Free Software, not the
> Free Softw are Foundation.
Got it - and in fact, tqhe major, important and consequential contributions of
the free software community as a whole are well understood by most IETF
people, and many of us are therefore receptive to their concerns - but those
concerns need to be expressed in an effective manner.
> Please, advise as to the proper forum for voicing my concerns regarding
> the potential encumberance of a suggested standard by patented
> software if not the mailing list for your organization.p
The problem is that our process is set up all wrong for that kind of
interaction. A lot of these decisions are complicated, and so it doesn't
really work well to come in at the end, after everyone else has looked at a
lot of different issues and tradeoffs, and hammered out something that meets
everyone's goals, and ask that things be changed...
As a result, the IETF almost _can't_ have a good mechanism for receiving
'outside' comments at the last moment. The thing is that the IETF is so open
(there is no fee to join a list, or any kind of qualification) that we've
always asumed the best way to influence work on an IETF standard is to just
be on the inside!
That means joining the mailing list for the Working Group that's developing
the standard, and give your opinion while the WG is still working on it. Yes,
this means people have to somehow find out that a WG exists, spend time
paying attention to it, etc. Of course, not everyone can manage to do that.
On the other hand, if people come in at the end, then you're back to the
'everyone went round and round and hammered this out, and now you want us
to change it' problem. Sigh...
Also, you may find the attached message from another IETFer to provide some
insight into our attitude about encumbered standards.
Here's another point for you: we have had cases were we approved a spec, and
_after_ it was implemented and deployed, it turned out someone outside the
IETF had filed a patent application that bore on it, one we had no idea
existed (the US used to not make applications public) - we call them
'submarine patents' (for the obvious reason).
So we can't _guarantee_ that a spec has no encumbrances _anyway_.
Noel
--------
From: Thomas Narten
Date: Wed, 11 Feb 2009 09:16:23 -0500
The basic process is that when IPR is known to exist, the IETF (and/or
the WG where the work is being developed) consider the IPR disclosure
along with the licensing terms, and any other issue they deem
relevant. They then decide whether to:
-- reject the technology outright, because the IPR is simply too
problematic to have in that particular standard.
-- Try to work around the IPR by changing the technology to not
infringe the IPR (usually hard or impossible to do, for several
reasons)
-- Accept that there is IPR, but publish in the experimental or
information category, rather than on the Standards Track.
-- Accept that there is IPR but publish as a standard anyway. This is
done when it is believed having a standard is important, and that
the IPR is not sufficient grounds to torpedo the entire effort. If
the IPR proves to be too onerous in practice for folk to implement
(whether vendors or open source), the standard goes nowhere. That
is often a fine way for the situation to work out. "Let the market
decide". And, it is worth noting, that the open source community
does play an important role here, because if they won't implement
a technology, that can be enough to prevent the technology from
obtaining critical mass.
It is also worth remembering that almost no technology is unencumbered
these days. Indeed, we mostly don't know when it is. So it's pretty
naive to think that the IETF (or anyone) can only approve unencumbered
technology (despite what we may wish).
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf