At 11:57 AM -0700 10/23/07, Hallam-Baker, Phillip wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C815A6.947239F7"
The objective here is to constrain the amount of unproductive argument by
limiting the number of possible end states.
In particular I would like to tip the scales so that if we have proposals A
and B where A is unemcumbered but B is not that proposal B has to demonstrate
a remarkably higher value in order to be chosen over A.
I believe it is fairer to recognize that in your example proposal B is known to
have
been patented where A is not. There is always the chance that someone will
turn out to
have secured rights which they later claim read on A. In that case it may
actually
be better to choose B, knowing that the license offered works for the
development
and deployment community than to choose A. In other words, a "defensive"
patent declaration by someone whose license works for the appropriate
community may actually add security. It doesn't completely remove the risk
that someone will turn up with other rights, but it really can help.
The reason that the "wiggle room" argument is problematic is that the
development and deployment communities for different areas of standards
work in the IETF are different. A license offered by company C for work
in routing may work well, where the exact same license by organization M
for work at the apps layer may not. Allowing the folks who actually plan
to write the code to indicate where there are problems and where not
may be better than trying to get a few sizes to fit all.
Several people have already sent pointers to Simon's draft, which describes
how to get to a particular outcome; I think that is a good thrust. With that
and similar documents in hand, that community can have blueprints for
how to achieve particular goals. Those will get used, and that will make things
easier.
But that's very different from trying to set the scales for working groups
in advance. That will just get into hair-splitting over whether something
meets a vague test for "remarkably higher", which is even harder to
get argued. "I can and will implement this, with the offered license" is a
much easier statement to evaluate than "This meets the 3 tests offered
in RFC XXXX for "remarkably higher" value because of N, M, and O".
Speaking only for my non-lawyer self,
Ted
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf