On Oct 29, 2004, at 5:56 PM, william(at)elan.net wrote:
Original:
| On Oct 29, 2004, at 12:44 PM, James Couzens wrote:
|
| > I would consider DK before SenderID, its most certainly more
mature and
| > it also hasn't spent the last ~6 months beating around the
proverbial
| > bush debating stupid software patents.
|
| I don't know what you mean by "debating", but you might want to take
a
| closer look at the IPR disclosures page.
|
| -andy
My answer (corrected spelling, missing word):
| Andrew, you should know quite well by now that just IPR disclosure
| is not enough and until we actually see the license the patent
| issue is still there.
Andrew Newton's answer to above:
Are we talking about the same thing?
Yes we're talking about same thing. You seem to have applied that for
WG to deal with patents most important is the IPR and then the debate
and issue is over. Its actually been backwards - we knew from the start
the IPR is there but the debate was not about the existance of the IPR,
but about the license.
Now some in IETF might say that IPR disclosure already provides
information
about what kind of license it would be (i.e free for all, etc) but it
appears that disclosure in the IPR document is not enough and until we
actually see the license, the WG can't be sure how much of an issue the
patent is and this may result in intense debates at the very crucial
point
of the WG's work cycle.
No, we're not talking about the same thing.
In the statement above, James used the word "debating". And when I
said "I don't know what you mean by 'debating'", I meant that I didn't
understand the use of the word "debating" in his sentence since it
seemed to have applied to "stupid software patents" ( and not stupid
software patent licenses as you seem to have further honed in upon ).
However, if "stupid software patents" are the issue then I have
suggested a closer look at the IPR disclosures page given James' words
of "I would consider DK before SenderID". Or in other words, there is
a patent covering DomainKeys.
-andy
smime.p7s
Description: S/MIME cryptographic signature