Re: IPR Re: IETF 54 calendar (fwd)
If what you are asking for is that for every proposal / i-d that shows up in the IETF, the IPR holder is automatically required to provide an RF license, you really don't understand the reason people bother with patents to begin with. doesn't follow. it's entirely possible to understand why people bother with patents and still believe that IETF shouldn't support their use to prevent free implementation of a standard. Keith
Re: IPR Re: IETF 54 calendar (fwd)
As I recall, RAND was explicitly selected over RF because there are and will be technologies that are interesting to incorporate in a system-wide standard approach, and forcing RF terms would automatically exclude those. There is enough of a bias in the participants toward RF when available, that explicit language requiring it adds no value and in some cases actually subtracts value from the process of achieving consensus. If what you are asking for is that for every proposal / i-d that shows up in the IETF, the IPR holder is automatically required to provide an RF license, you really don't understand the reason people bother with patents to begin with. tony - i don't find your last paragraph to be particularly helpful. a reasoned argument can be made that patents and community standards are incompatible. a rigorous study of the US patent system indicates that the founders introduced the system in order to serve the public good, by encouraging innovation, by granting limited monopolies on inventions. it is unclear if that system is particularly compatible with community-based approaches such as the IETF where, by definition, the output is not monopolized. with respect to your first paragraph, i note that if technology companies see value in participating in the standards process, then perhaps it is not unreasonable to suggest that the IETF consider only RF stuff, and then let the various IPR stakeholders decide whether the trade-off is worth it... in other words, if someone has some whizbang technology, and if they want the imprimatur of a community such as the IETF, then they can decide for themselves whether to RF it. if not, they are perfectly free to pursue a proprietary market strategy. for myself, i take no position on the merits of the two kinds of licensing; rather, i merely note that the issue is somewhat more subtle than first glance. /mtr
RE: IPR Re: IETF 54 calendar (fwd)
Marshall Rose wrote: As I recall, RAND was explicitly selected over RF because there are and will be technologies that are interesting to incorporate in a system-wide standard approach, and forcing RF terms would automatically exclude those. There is enough of a bias in the participants toward RF when available, that explicit language requiring it adds no value and in some cases actually subtracts value from the process of achieving consensus. If what you are asking for is that for every proposal / i-d that shows up in the IETF, the IPR holder is automatically required to provide an RF license, you really don't understand the reason people bother with patents to begin with. tony - i don't find your last paragraph to be particularly helpful. a reasoned argument can be made that patents and community standards are incompatible. a rigorous study of the US patent system indicates that the founders introduced the system in order to serve the public good, by encouraging innovation, by granting limited monopolies on inventions. it is unclear if that system is particularly compatible with community-based approaches such as the IETF where, by definition, the output is not monopolized. Clearly from the responses I didn't make my point in that last paragraph. The original note mentioned VRRP specifically, and in that case the IPR holder didn't bring the proposal to the IETF. The way I read that note, the Free Software community believes that the IPR holder should be required to provide RF terms when someone proposes a similar technology for standardization. with respect to your first paragraph, i note that if technology companies see value in participating in the standards process, then perhaps it is not unreasonable to suggest that the IETF consider only RF stuff, and then let the various IPR stakeholders decide whether the trade-off is worth it... in other words, if someone has some whizbang technology, and if they want the imprimatur of a community such as the IETF, then they can decide for themselves whether to RF it. if not, they are perfectly free to pursue a proprietary market strategy. In general I agree for the case where the IPR holder brings the technology for standardization. In the case where a proposal shows up which the group thinks is technically the right direction, but a 3rd party holds IPR, we can't require RF, but can require the WG demonstrate that RAND is functional. for myself, i take no position on the merits of the two kinds of licensing; rather, i merely note that the issue is somewhat more subtle than first glance. Subtle enough that a quick paragraph is easily misread. :) Tony
Re: IPR Re: IETF 54 calendar (fwd)
In message [EMAIL PROTECTED], Keith Moore writes: If what you are asking for is that for every proposal / i-d that shows up in the IETF, the IPR holder is automatically required to provide an RF license, you really don't understand the reason people bother with patents to begin with. doesn't follow. it's entirely possible to understand why people bother with patents and still believe that IETF shouldn't support their use to prevent free implementation of a standard. There's an interesting dilemma here. I know of one case where some IETFers tried *hard* -- and persuaded their employers -- that an algorithm they invented should be patent-free. But someone else asserted that his patent *might* cover their invention -- and, since their employers wouldn't profit from a patent-free protocol, they wouldn't stand behind it if it went to court, or even to lawyers at 20 paces. That is: no patent and no profit = no strong backing. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book)
Re: IPR Re: IETF 54 calendar (fwd)
doesn't follow. it's entirely possible to understand why people bother with patents and still believe that IETF shouldn't support their use to prevent free implementation of a standard. There's an interesting dilemma here. I know of one case where some IETFers tried *hard* -- and persuaded their employers -- that an algorithm they invented should be patent-free. But someone else asserted that his patent *might* cover their invention -- and, since their employers wouldn't profit from a patent-free protocol, they wouldn't stand behind it if it went to court, or even to lawyers at 20 paces. That is: no patent and no profit = no strong backing. one of the major problems with the patent system is that it all but forces competition even when it's not desirable. which is why I don't blame companies (or individuals!) for patenting things and licensing them on a don't sue us, we won't sue you basis. (which seems to me to be entirely compatible with RF) Keith
Re: IPR Re: IETF 54 calendar (fwd)
On Wed, 29 May 2002 15:40:55 PDT, Tony Hain said: Clearly from the responses I didn't make my point in that last paragraph. The original note mentioned VRRP specifically, and in that case the IPR holder didn't bring the proposal to the IETF. The way I read that note, the Free Software community believes that the IPR holder should be required to provide RF terms when someone proposes a similar technology for standardization. Be very careful here - asserting that there is one the Free Software community that agrees on ANYTHING is hazardous. Fortunately for our collective sanity, most of the community seems to be in either the GPL camp or the BSD/X11 camp, and both of those groups would agree on royalty-free as a requirement. I have to agree with the RF requirement on more pragmatic grounds - if we want to move something along the Standard track, we're saying This is the way it should be done. And the reality is that a monoculture is a Very Bad Thing for all the usual diversity reasons. However, this implies that there will be platforms with marginal support, where most of what's being done is for free by hobbyists and owners/users (see the Linux world several years ago for an example). Letting something onto the Standards track without a RF clause is basically saying Your checkbook must be at least license fee tall to ride this function of the Internet. And we don't want to do that. Does anybody know if it's possible to write a license for basic technology (the algorithms themselves, not a particular source implementation) such that code written to implement it can be released under the BSD or GPL licenses, as the implementor sees fit? Do we, as the IETF, want to say must be *either* BSD-ish or GPL-ish licensed, or do we want to say must be compatible with both styles, or do we want to do a semantic tap-dance and use verbiage that doesn't actually *reference* either by name, but is acceptable to either/both camps? I know that the GNU people are more than happy to discuss in great detail exactly how a specific license is or isn't compatible with their agenda and license, and I'm sure a spokesperson can be found for the BSD-style camp as well... (And as usual, IANAL, I just happen to have opinions on what I perceive as a desirable goal) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08409/pgp0.pgp Description: PGP signature
