Re: IPR at IETF 54
At 02:09 PM 5/31/2002 -0400, Theodore Ts'o wrote: So we seem to have only a few work items suggested so far: I think the problem is that while there is (very) rough consensus IETF-wide that there is a strong cultural bias against patent encumberances (*), this bias is not adequately documented in writing. 1. Improve the language that indicates IETF community preferences concerning when to accept or reject IPR components to a specification. Per Ted's observation, the improved language needs to give better guidance to new IETF participants and to other groups that work with the IETF. (The rest of Ted's note suggested some nicely pragmatic goals/caveats for upper and lower bounds to this goal.) Ten years ago, we were mostly concerned with the silent patent holder problem. ... The current process was designed to minimize this risk, ... As KRE points out, the whole mechanism falls apart when vendors field products based on a proposed standard, not to mention an internet draft. It seems unlikely that we can do much about this, for specifications that have IPR announced after proposed standard has been reached. 2. When we know about IPR before going to Proposed, we could of course require the interoperability test for IPR licensing beforehand. The idea of requiring interoperability testing before going to Proposed is already in the IETF repertoire for certain sensitive cases, so this would be a pretty compatible change to the current model. There are other issues. The first one is the imprecision of the disclosure requirements. 3. Seems like this is a relatively minor tuning issue to the current policy, followed by some careful legal language crafting. Yes? A second issue is the interaction between the standardization process and non-disclosure agreements. For example, an IETF participant may know that his or her former employer has a patent claim on a technology considered for standardization; in fact, I know case where the participant is in fact one of the authors of the patent. Yet, the agreement signed when leaving an employer typically prevents disclosure of such information. In another example, a vendor may have to sign an NDA before learning that its product infringes on some other organization's patent. This vendor is then legally prevented to signal the existence of the patent claim to the IETF. 4. This is probably going to be the toughest of the set to resolve. Perhaps we can treat some sorts of NDA-related issues as conflict of interest, and invoke our current rules concerning them? Ultimately I suspect we have little leverage here. I would contend that, if we have one urgent problem to solve, it is to find a way to ensure speedy disclosure of intellectual property issues that affect a standard. I have never heard anyone claim that we have more leverage over this than we are already exerting. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850 -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
Re: IPR at IETF 54
--On 31. mai 2002 07:54 -0600 Vernon Schryver [EMAIL PROTECTED] wrote: I guess what I was asking was how the IETF would feel about an organization grabbing a patent on an algorithm and using it the same way the GNU crew uses copyright on source code. (Remember - the GNU copyright only works for *code* - since algorithms can be (at least in the US) patented but not copyrighted, you'd have to do a similar stunt with a patent). (And yes, this would be a case of the Good Guys file a bull-manure patent to pre-empt the Evil Guys from filing a bull-manure patent - but until the Patent Office gets their act together we're stuck with borked software patents that are invalid due to prior art, etc) In theory that could happen. It may have happened in practice with the Ethernet patent. But what's the point? What is gained by winning such a patent from government(s) compared to publishing the same document, other than a year or three of jumping through hoops and plenty of money and hassles? the only advantage I could see is that the only prior-arts database the patent offices are REQUIRED to search is the database of old patents.
Re: IPR at IETF 54
From: Harald Tveit Alvestrand [EMAIL PROTECTED] ... (And yes, this would be a case of the Good Guys file a bull-manure patent to pre-empt the Evil Guys from filing a bull-manure patent - but until the Patent Office gets their act together we're stuck with borked software patents that are invalid due to prior art, etc) In theory that could happen. It may have happened in practice with the Ethernet patent. But what's the point? ... the only advantage I could see is that the only prior-arts database the patent offices are REQUIRED to search is the database of old patents. The trouble with that common suggestion is that it assumes the word search makes sense in this context. It does not and cannot. Anyone who has read at least two patents realizes that they are certainly not intended to be written to do clearly describe an idea. Because of the way they are written, it is too much hope that people of reasonable intelligence and at least ordinary education and skill in the relevant arts can honestly search patents. If that notion made sense, new patents would be as popular reading as the Scientific American. There would be trade publications that consisting largely of patents. You would consult US4558302 instead of the BSD code to figure out LZW. Second, what do the followin words from http://www.delphion.com/details?pn=US06025810__ say about the intelligence and ordinary education of the responsible examiner: A method to transmit and receive electromagnetic waves which comprises generating opposing magnetic fields having a plane of maximum force running perpendicular to a longitudinal axis of the magnetic field; generating a heat source along an axis parallel to the longitudinal axis of the magnetic field; generating an accelerator parallel to and in close proximity to the heat source, thereby creating an input and output port; and generating a communications signal into the input and output port, thereby sending the signal at a speed faster than light. Yes, I know the group velocity can exceed the speed of light. Do you think that is relevant? You used to be able to see that whole patent for free. As far as I could tell then, it and the companion patents made less sense than Eugene Terrell's IDs. Third, if you pay the least attention to business news, you frequently hear of court cases in wich one patent is found to be invalid because of other patents. If patent searching is makes sense, how did the Welch LZW patent get granted after the IBM patent? Vernon Schryver[EMAIL PROTECTED]
Re: IPR at IETF 54
In general, this IPR debate seems to be missing several relevant parts of the discussion. The discussion seems to be focussed on the case where a company brings forward a proposal, and simultaneously has or applies for a patent. That is one interesting case. It does cause problems. It is hard to control. But the other cases are much harder: At the time when VRRP was chartered we knew that Cisco claimed relevant patents, and that while they were (to my perspective) trying to be cooperative they would not guarantee that whetever the working group did they would provide free licensing on their existing technology. Should we have refused to charter the working group? In anumber of working groups, as the work was going along, vendors have come forward with claims that they have patents that are (or may be) relevant to the work. We once (probably more than once) tried to actually have IETF counsel determine whether these patents were likely to be relevant. The result of this experience was the conclusion that the IETF should NEVER get into that game. As such, we are in no position to evaluate patent claims. We simply publish them. Whould we then prevent standardization if anyone claims a patnet that is / may be relevant to practicing the standard under consideration unless they promise to license freely? That is a recipe for disaster! For those who do not se why... Anyone who did not like a standard could undertake a bit of work, file for a related patent, and then claim that they thought it was necessary to practice the standard. Since we can not be in the business of validating such claims, any such policy would inherently provide lots of companies, particularly large companies, with a way to block things they don't like. Then there are the folks who are not participating in a particular activity at the IETF, but then conclude (after we standardize) that they have a relevant patent. Should we declare the standard historic? And then there are the folks who do not even participate in the IETF... Yours, Joel M. Halpern At 07:54 AM 5/31/2002 -0600, Vernon Schryver wrote: From: [EMAIL PROTECTED] In still other words, don't you remember the years of pain Motorola/Codec caused PPP with those two bogus patents? I guess what I was asking was how the IETF would feel about an organization grabbing a patent on an algorithm and using it the same way the GNU crew uses copyright on source code. (Remember - the GNU copyright only works for *code* - since algorithms can be (at least in the US) patented but not copyrighted, you'd have to do a similar stunt with a patent). (And yes, this would be a case of the Good Guys file a bull-manure patent to pre-empt the Evil Guys from filing a bull-manure patent - but until the Patent Office gets their act together we're stuck with borked software patents that are invalid due to prior art, etc) In theory that could happen. It may have happened in practice with the Ethernet patent. But what's the point? What is gained by winning such a patent from government(s) compared to publishing the same document, other than a year or three of jumping through hoops and plenty of money and hassles? If you look at patents, you soon see that there's nothing special about software patents and that the problems with the system are more than 100 years old. What would you expect from giving lawyers and government bureaucrats (specifically including examiners) the responsibility and authority to determine the validity (e.g. no perpetual motion) and novelty of other people's ideas? Government central planning of economies is more or less dead (for now), but government central planning for science and technology lives in the West. Vernon Schryver[EMAIL PROTECTED]
Re: IPR at IETF 54
Date:Thu, 30 May 2002 23:13:24 -0500 From:Dave Crocker [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | So, what exactly do folks think is a practical kind of change to the | current IETF policies? Actually, like many things, I suspect that the underlying problem that we're seeing is in quite a different area than the one we're looking in. My suggestion to fix this problem is quite simple No more last calls before moving protocols to historic, except where they're full standards already. For everything else, going to historic should be automatic. That is, the only way to avoid any spec being made historic automatically, is for it to become a full standard. This is more or less saying what Henning Schulzrinne said before I got the chance... The problem is that very few standards make it to Draft. Exactly. We have developed a culture of getting the work to PS status, and considering it done. We even disband working groups (or move them to dormant status, which is effectively the same thing) as soon as all their docs have been published. And the implementors see that - as soon as something has reached PS status, it is considered finished, and we even have people getting upset (because of the deployed base we'll be breaking) if any changes get made. That's what's really broken here - we actually have almost the prefect IPR policy in place, but we're not bothering to actually attempt to use it before it is way too late. What we need to do is make sure that everything gets to draft standard within a relatively short time after it has reached PS, say 9-12 months (preserving the current 6 month minimum to make sure there's enough time for implementations to be attempted). Anything that hasn't made it to DS then should simply be shelved, abandoned (DS isn't much of a hurdle after all). And we should be actively discouraging distribution in products of anything that isn't at least DS (to do that we probably should get into the habbit of making random innocuous changes to docs when they go to DS state - like if we have commands that are issues in binary and they're 1, 2, 3, ... (as usual), we just change which is 1, which is 2, etc so everyone actually running the code has to update - which of course is impossible after something has been shipped. Then again, we need to make sure that all DS's get elevated to full standard quickly, or dropped. This is where the IPR rules really get exercised, where we see if the proposal has IPR rules that make it difficult to implement and deploy or not. If the IPR rules cause problems, then the doc won't reach Std status, and again, that should mean that it is automatically made historic and abandoned. It isn't the IPR rules that need changing here, the current formulation that Christian Huitema came up with is almost certainly the best we can do - anything different is far more likely to cause problems than to solve any. kre
Re: IPR at IETF 54
On Fri, 31 May 2002 08:40:17 +0300, Pekka Savola said: A bad thing IETF could do (but not the worst luckily :-) is to give a signal Ok.. feel free to patent and give RAND licensing.. depending how good it is, we might give it a standards status or we might not. That _encourages_ to do patents (or try to), and we want to avoid that. Patents *in and of themselves* are not a Bad Thing. As far as the IETF goes, the problem only arises when the patent is used to enforce a restrictive licensing policy. Can anybody think of a reason the IETF should object to patented tech *per se*, as opposed to objecting to *hard-to-license* patented tech (the latter I think we have consensus as being a Bad Thing)... -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08433/pgp0.pgp Description: PGP signature
Re: IPR at IETF 54
From: [EMAIL PROTECTED] Patents *in and of themselves* are not a Bad Thing. As far as the IETF goes, the problem only arises when the patent is used to enforce a restrictive licensing policy. Can anybody think of a reason the IETF should object to patented tech *per se*, as opposed to objecting to *hard-to-license* patented tech (the latter I think we have consensus as being a Bad Thing)... In real life, every patent that is enforced is hard-to-license. Every patent that is not ignored by everyone including the holder has a restrictive licensing policy, official IETF, IEEE, and other dogma notwithstanding. Any sort of real patent licensing requires dealing with lawyers, negotiations, and the rest of that very painful, incredibly slow, and cripplingly expensive show. The phrase non-restrictive patent licensing policy is an oxymoron. The entire and only point of a patent is to restrict that other people can do. At best, you can have a take equal money from anyone patent licensing policy. In still other words, don't you remember the years of pain Motorola/Codec caused PPP with those two bogus patents? Vernon Schryver[EMAIL PROTECTED]
Re: IPR at IETF 54
On Fri, 31 May 2002 07:12:50 MDT, Vernon Schryver [EMAIL PROTECTED] said: In still other words, don't you remember the years of pain Motorola/Codec caused PPP with those two bogus patents? I guess what I was asking was how the IETF would feel about an organization grabbing a patent on an algorithm and using it the same way the GNU crew uses copyright on source code. (Remember - the GNU copyright only works for *code* - since algorithms can be (at least in the US) patented but not copyrighted, you'd have to do a similar stunt with a patent). (And yes, this would be a case of the Good Guys file a bull-manure patent to pre-empt the Evil Guys from filing a bull-manure patent - but until the Patent Office gets their act together we're stuck with borked software patents that are invalid due to prior art, etc) /Valdis msg08437/pgp0.pgp Description: PGP signature
Re: IPR at IETF 54
From: [EMAIL PROTECTED] In still other words, don't you remember the years of pain Motorola/Codec caused PPP with those two bogus patents? I guess what I was asking was how the IETF would feel about an organization grabbing a patent on an algorithm and using it the same way the GNU crew uses copyright on source code. (Remember - the GNU copyright only works for *code* - since algorithms can be (at least in the US) patented but not copyrighted, you'd have to do a similar stunt with a patent). (And yes, this would be a case of the Good Guys file a bull-manure patent to pre-empt the Evil Guys from filing a bull-manure patent - but until the Patent Office gets their act together we're stuck with borked software patents that are invalid due to prior art, etc) In theory that could happen. It may have happened in practice with the Ethernet patent. But what's the point? What is gained by winning such a patent from government(s) compared to publishing the same document, other than a year or three of jumping through hoops and plenty of money and hassles? If you look at patents, you soon see that there's nothing special about software patents and that the problems with the system are more than 100 years old. What would you expect from giving lawyers and government bureaucrats (specifically including examiners) the responsibility and authority to determine the validity (e.g. no perpetual motion) and novelty of other people's ideas? Government central planning of economies is more or less dead (for now), but government central planning for science and technology lives in the West. Vernon Schryver[EMAIL PROTECTED]
Re: IPR at IETF 54
Date:Fri, 31 May 2002 09:03:43 -0400 From:[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | OK.. I'll bite - at what point should a not-yet-full standard expire to | historic? Pretty quickly. What the max period at DS should be I'm not sure, but certainly no more than 2 years. The point not being to shed lots of stuff necessarily of course, but to put more pressure on all of us to take the comparatively small steps needed to move the docs up the chain. Compared with the work needed to get something to PS state, the rest of it isn't difficult really. | And the flip side - we've moved an amazingly SMALL number of documents | to Full Standard, and only when we *think* we *fully* understand things. That's the problem. Or it is with the IPR issues. It is determining whether we can make that final step (widespread deployment is what is required, expecting full understanding of almost anything is naïve) that actally decides whether or not the IPR rights holder is being reasonable or not. That's what we really need to figure out relatively quickly - we can't wait 10 years with docs in PS (and a lesser number DS) state with everyone assuming they are *the* standard - then we haven't properly tested any IPR problems that might exist. | One of the *GOOD* things about protocols living at DS is that you can | convince vendors to start supporting the *new* DS rather than the *old* one. Yes, that's true - but it would be even easier if the new one were a full standard (even if the old one was too). kre
Re: IPR at IETF 54
On Fri, 31 May 2002 22:34:06 +0700, Robert Elz said: Yes, that's true - but it would be even easier if the new one were a full standard (even if the old one was too). How would that work (having 2 full standards for the same exact thing)? msg08440/pgp0.pgp Description: PGP signature
Re: IPR at IETF 54
Date:Fri, 31 May 2002 11:48:24 -0400 From:[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | How would that work (having 2 full standards for the same exact thing)? Depends on what the thing is, and how precisely you mean the same exact thing. In some cases it wouldn't - it is common for a new std to obsolete an old one, no reason that can't continue. But sometimes the new std is written in such a way that the old one can also continue. Eg: the standard for IP. There's a new one (not yet full std, but really should be by now), and the old one. They do the same job, but can co-exist (version field works, though other ways used more commonly). You might say those are not the same thing, but the new one really is intended as a replacement (eventually) for the old. kre
Re: IPR at IETF 54
On Fri, 31 May 2002 07:54:49 MDT, Vernon Schryver [EMAIL PROTECTED] said: In theory that could happen. It may have happened in practice with the Ethernet patent. But what's the point? What is gained by winning such a patent from government(s) compared to publishing the same document, other than a year or three of jumping through hoops and plenty of money and hassles? The problem is that you can publish the same document, and then some sleazeball competitor patents it, because the patent office does such a poor job of researching prior art. If http://www.bustpatents.com didn't have a reason to exist, I'd agree with you. msg08442/pgp0.pgp Description: PGP signature
Re: IPR at IETF 54
From: [EMAIL PROTECTED] ... The problem is that you can publish the same document, and then some sleazeball competitor patents it, because the patent office does such a poor job of researching prior art. That seems to be based on the false notion that the patent office checks even its own documents for prior art. If http://www.bustpatents.com didn't have a reason to exist, I'd agree with you The reasons I see for that and similar publications do not involve the assumption that government bureaucrats and everyone else involved in the IP protection business don't see that their own interests lie in what can be charitably summarized as erring on the side of accepting instead of rejecting patent applications. Look for the notion of blocking patents in the 19th Century in such as in development of firearms. Unless you think everyone in the 19th Century was a superstitious and ignorant idiot or that all real science and technology appear after 1950, look at the many obviously silly patents from the first century of the extortion racket. Vernon Schryver[EMAIL PROTECTED]
RE: IPR at IETF 54
| And the flip side - we've moved an amazingly SMALL number of documents | to Full Standard, and only when we *think* we *fully* understand things. That's the problem. Or it is with the IPR issues. It is determining whether we can make that final step (widespread deployment is what is required, expecting full understanding of almost anything is naïve) that actally decides whether or not the IPR rights holder is being reasonable or not. Ten years ago, we were mostly concerned with the silent patent holder problem. It is reasonably easy for a WG to make its own decision when the existence of the patents and the licensing conditions are disclosed up front, before the WG agrees on a solution. But the real problem occurs when the patent holder ambushes the standard. Products get developed and fielded, and then the vendors or the users of these products get hit by an infringement lawsuit. The current process was designed to minimize this risk, on the belief that if an issue actually existed, it would surface during the early phase of testing, i.e. before the standard would move from proposed to draft. The rationale was that there would not be much usage at that stage, and that if push came to shove the WG could re-design the standard so as to not require licensing of a hard-to-get patent. As KRE points out, the whole mechanism falls apart when vendors field products based on a proposed standard, not to mention an internet draft. There are other issues. The first one is the imprecision of the disclosure requirements. The current process does not exactly say who is required to disclose the existence of intellectual property. According to some interpretations, a working group chair whose organization holds patents affecting a draft discussed in the working group is not required to disclose these patents, if he or she does not contributes or otherwise participate in the discussion of this specific draft. A second issue is the interaction between the standardization process and non-disclosure agreements. For example, an IETF participant may know that his or her former employer has a patent claim on a technology considered for standardization; in fact, I know case where the participant is in fact one of the authors of the patent. Yet, the agreement signed when leaving an employer typically prevents disclosure of such information. In another example, a vendor may have to sign an NDA before learning that its product infringes on some other organization's patent. This vendor is then legally prevented to signal the existence of the patent claim to the IETF. I would contend that, if we have one urgent problem to solve, it is to find a way to ensure speedy disclosure of intellectual property issues that affect a standard. -- Christian Huitema
Re: IPR at IETF 54
I think the most effective thing would be to send a strong signal of some kind: If you patent technologies and give non-RF licenses, _do not expect the technology be supported in IETF at all_. The problem is that there are enough companies out there that don't care. There are some areas of technology out there where companies that don't need IETF-style interoperability have essentially patented every possible branch of the decision tree (and are continuing to do so). What should the IETF do here? Fortunately, we don't do codecs. Whew. However, there may be other areas where the only remaining way forward is to actively cut through the existing jungle of utterly bogus patents. By the way, I do completely agree with your point. Just pointing out that it may not be enough. Gruesse, Carsten
Re: IPR at IETF 54
On Thu, May 30, 2002 at 11:13:24PM -0500, Dave Crocker wrote: To underscore the point that Marshall has been making: The IETF has a strong preference to use unencumbered technologies. When there is a choice between encumbered and unencumbered, the working group includes encumbrance into the range of factors it treats as important for evaluating alternatives. There are some unknowns about licensing. Some holders of IPR are helpful to resolving that easily and quickly. Others are more reticent. That become a component of the evaluation about the IPR factor. And so on. Generally this thread seems to be seeking determinacy for a matter that can only be made deterministic by a) ignoring IPR encumbrance, or b) rejecting all IPR encumbrances. The first is not compatible with IETF culture. The latter is not practical in some cases. So, what exactly do folks think is a practical kind of change to the current IETF policies? I think the problem is that while there is (very) rough consensus IETF-wide that there is a strong cultural bias against patent encumberances (*), this bias is not adequately documented in writing. This is exacerbated by the fact that some IETF working groups, particularly those where a greater number of the participants do not have as much IETF experience and acculturation. This is happening more and more as we start doing more cross-collaborations with other standards bodies, and when technologies which previously had been used on top of other media are ported to IP, and people who had been used to working in other standards bodies find them selves working within the IETF. (*) Unless there is a ***very*** reason why you can't do without the patent --- RSA signatures/encryption being classic example, but even there, RSA DSI's licensing policies were probably far more effective that the U.S. government's export control regime at preventing the deployment of secure protocols in the Internet). Many of these newcomers to the IETF very dutifully read the relevant RFC's (2026, et. al.), and then are surprised either (a) they get strong push back from the IESG, or (b) their decisions get attacked at IETF plenery sessions, the IETF mailing list, or in other venues. They are get surprised, and there is some fairness to their argument that this bias against non-RF patents isn't written down anywhere and isn't formally part of our policies. Granted, we can't document every tiny detail of cultural biases within the IETF in our policy documents, but I think this one is important enough that we need to say something. Once we do decide that we need to say something, then the next question is exactly where do we draw the line, and that's where all of the discussion and long missives to the IETF mailing list are coming from. Although it's pretty clear we won't be able to give working groups an algorithmic flowchart about when a non-RF patent is acceptable, I do believe that we can give some general guidelines, and then require that the working group chair work with the area director when this sort of issue raises its ugly head. This won't solve the stealth patent problem, where the patent problems only reveal themselves very late in the process, or even after document is published as an RFC, but it does handle a large number of other cases. - Ted
Re: IPR at IETF 54
Bill Strahm wrote: On Thu, 30 May 2002, RJ Atkinson wrote: On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote: Here's one for starters: there's no guidance on how or whether to treat differences in licensing terms for competing proposals. It would be nice to be able to say that all other things being more-or- less equal we should prefer technology which will be available royalty-free, Agree. My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). And it would be good to have a conventional template for the royalty-free licence -- one that the IETF's legal counsel has reviewed and believes is acceptable for IETF purposes. I disagree with this, I don't think the IETF can afford to keep a staff of lawyers working on determining the licencing statements of all of the standards being churned out. That said, I don't think it would do any good anyway, lets say the IETF lawyer gives his Okey Dokie, then my company implements the standard and a problem with the licencing terms comes up... Who do I go sue, the IETF ??? I hope not, but that could be creating a legal liability for the IETF if its lawyers make statements on the licencing terms of protocols... Bill Bill, The IETF isn't incorporated, so there is no way it can make such statements. The IETF's corporate umbrella is the Internet Society. Now I haven't consulted ISOC's CEO and VPs but I am on pretty safe ground in asserting that you are correct: ISOC would never accept such a liability. Our insurance company wouldn't let us. Brian E Carpenter Board Chairman, Internet Society http://www.isoc.org INET 2002, Washington, DC, 18-21 June http://www.inet2002.org
Re: IPR at IETF 54
On Fri, 31 May 2002 [EMAIL PROTECTED] wrote: On Fri, 31 May 2002 08:40:17 +0300, Pekka Savola said: A bad thing IETF could do (but not the worst luckily :-) is to give a signal Ok.. feel free to patent and give RAND licensing.. depending how good it is, we might give it a standards status or we might not. That _encourages_ to do patents (or try to), and we want to avoid that. Patents *in and of themselves* are not a Bad Thing. As far as the IETF goes, the problem only arises when the patent is used to enforce a restrictive licensing policy. Can anybody think of a reason the IETF should object to patented tech *per se*, as opposed to objecting to *hard-to-license* patented tech (the latter I think we have consensus as being a Bad Thing)... Some reasons have been given already about the evilness of (almost) all patents. I'll add one that hasn't been widely discussed. The patent holder is in charge of the licensing. So he could do e.g.: - write so ambiguous licensing terms nobody has the courage to implement the spec without long, long consultation with lawyers - the licensing terms could have a few (intentionally or unintentionally) clauses that can afterwards interpreted differently *) - change the license afterwards *) an example of this is: http://www.ietf.org/ietf/IPR/ISI-NGTRANS.txt, specifically: --8-- [...] If SRI's submission (or portions thereof) is accepted and becomes part of the IETF standard, then SRI will grant royalty-free permission under such patents for both commercial and non-commercial uses, to the extent _necessary for compliance_ with the standard. [...] --8-- (underlining mine) This can be interpreted that everyone implementing a MAY or SHOULD in the specification could be blamed for infringing the licensing terms afterwards. Fun, eh? .. If it takes a lawyer to write (or understand) licensing terms, they're probably too complex .. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: IPR at IETF 54
From: Pekka Savola [EMAIL PROTECTED] ... .. If it takes a lawyer to write (or understand) licensing terms, they're probably too complex .. Something like the programmer who is his own IP lawyer has a fool for a client applies. In other words, if you need to sign a license, then it takes a lawyer to understand its terms. 10 or 15 years ago people said that free RFCs versus expensive ITU (ISO) standards were a major advantage of the DDN Protocol Suite. Today, the cost of necessary legal advice dwarfs those old documentation fees by orders of magnitude. This is all merely sweeping against the tide. I predict all of this noise will come to nothing but affirming the IETF's IP status quo. The IETF has always had too many people who without the faintest clue or interest in implementing anything, except when they mean unpack a box and plug it in. That problem has continued to worsen over the years and has been joined by another problem. Many of the ever fewer IETF implementors (or their employers) now hope to get rich (or avoid bankruptcy) by selling IP licenses. Vernon Schryver[EMAIL PROTECTED]
Re: IPR at IETF 54
At 08:12 PM 5/29/02 -0500, Pete Resnick wrote: And overall I'm pretty darn sick and tired of wasting my time in WG/BOF sessions where all I get is a series of undiscussed presentations that could have been done in I-Ds which I could have read before the meeting. So don't go to the session. One thing that's pretty clear is 1) that there's a problem, and 2) nobody's exactly certain what the problem is. I don't think that putting some effort into trying to scope the problem is a bad idea. Here's one for starters: there's no guidance on how or whether to treat differences in licensing terms for competing proposals. It would be nice to be able to say that all other things being more-or- less equal we should prefer technology which will be available royalty-free, but that's not current policy and I have absolutely no clue if there are legal problems with doing it. (It might also help damp some conduct problems that are arising out of people being overly enthusiastic in promoting their encumbered technology.) I wouldn't expect questions like that to be answered at an IPR session, but I hope that issues like it will be raised. Melinda
Re: IPR at IETF 54
On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote: Here's one for starters: there's no guidance on how or whether to treat differences in licensing terms for competing proposals. It would be nice to be able to say that all other things being more-or- less equal we should prefer technology which will be available royalty-free, Agree. My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). And it would be good to have a conventional template for the royalty-free licence -- one that the IETF's legal counsel has reviewed and believes is acceptable for IETF purposes. Creating a separate open [EMAIL PROTECTED] mailing list for these discussions would also be helpful, IMHO. Perhaps the IETF Chair could arrange such ? Regards, Ran [EMAIL PROTECTED]
Re: IPR at IETF 54
... we should prefer technology which will be available royalty-free, but that's not current policy Whose policy? Some WGs have a policy (or are actually chartered) to develop deployable protocols. Where a legal issue would make a protocol non-deployable, we have to look elsewhere. (Of course, that only applies to parts of the IETF -- maybe one reason why an IETF-wide policy may be harder to come up with than e.g. in the W3C.) Oh, and I would rather avoid the confusing term royalty-free. Imagine a technology that is licensed royalty-free to end-users (i.e., every single user has to pay a lawyer to get a license contract in place, which then is royalty-free). Royalty-free, but useless. Lawyer-free/paperwork-free would be the more useful criterion. Gruesse, Carsten
Re: IPR at IETF 54
On Thu, May 30, 2002 10:59:27AM -0400, RJ Atkinson wrote: My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). and if one solution is 120% better technically than another, but has a RAND license associated with it? What if it's 170% better?
Re: IPR at IETF 54
... we should prefer technology which will be available royalty-free, but that's not current policy Whose policy? RFC-2026, section 4.1.2 (Draft Standard): If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. /=\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |=| |I am Homer of Borg. Prepare to be assi... Mmm, doughnuts!| \=/
Re: IPR at IETF 54
My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). and if one solution is 120% better technically than another, but has a RAND license associated with it? What if it's 170% better? working groups make trade-offs all the time between simplicity, functionality, and so on. licensing is another cost. given the amount of traffic on this topic, it appears that licensing is a very heavy cost. this may provide an answer to your question... /mtr
RE: IPR at IETF 54
From: Scott Brim [mailto:[EMAIL PROTECTED]] On Thu, May 30, 2002 10:59:27AM -0400, RJ Atkinson wrote: My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). and if one solution is 120% better technically than another, but has a RAND license associated with it? What if it's 170% better? The de-facto policy in these cases has been to choose the less-encumbered technology as the standard (i.e. MUST implement), and the more-encumbered technology an option (MAY implement). For example, when RSA was still encumbered and Diffie-Hellman was not, the IETF settled on making Diffie-Hellman mandatory, RSA optional. Maybe this should be documented. -- Christian Huitema
Re: IPR at IETF 54
RFC-2026, section 4.1.2 (Draft Standard): If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. The problem is that very few standards make it to Draft. As the old saw goes, the Internet is running on proposed standards. (A more accurate description would be on Internet drafts and proposed standards). Statistical details were presented at the last plenary. Thus, this mechanism offers almost no remedy or protection. It would also be interesting to know if this has ever been checked in reality, even for the few standards that have made it that far. Also, this does not help if the two licensing arrangements are between two big corporations that have blanket mutual licensing deals, as is common. This says very little about whether a smaller company, a competitor or an open-source implementation could get a license.
Re: IPR at IETF 54
On Thu, 30 May 2002, RJ Atkinson wrote: On Thursday, May 30, 2002, at 09:48 , Melinda Shore wrote: Here's one for starters: there's no guidance on how or whether to treat differences in licensing terms for competing proposals. It would be nice to be able to say that all other things being more-or- less equal we should prefer technology which will be available royalty-free, Agree. My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). And it would be good to have a conventional template for the royalty-free licence -- one that the IETF's legal counsel has reviewed and believes is acceptable for IETF purposes. I disagree with this, I don't think the IETF can afford to keep a staff of lawyers working on determining the licencing statements of all of the standards being churned out. That said, I don't think it would do any good anyway, lets say the IETF lawyer gives his Okey Dokie, then my company implements the standard and a problem with the licencing terms comes up... Who do I go sue, the IETF ??? I hope not, but that could be creating a legal liability for the IETF if its lawyers make statements on the licencing terms of protocols... Bill
Re: IPR at IETF 54
one that's O(logN) with a non-RF license and one that's O(NlogN) with an RF license i probably wouldn't need to think very hard to go with the latter. simply because we'll see a lot more community good... Right. Standards exist so that we can get interoperability; expensive licenses limit interoperability. /==\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc. | |http://www.incentivesystems.com |My opinions are my own. | |==| |The Empire has a tyrannical and repressive government. What| |form of government is that? A tautology. | \==/
Re: IPR at IETF 54
At 11:15 AM 5/30/2002 -0400, Scott Brim wrote: and if one solution is 120% better technically than another, but has a RAND license associated with it? What if it's 170% better? And Scott's questions become particularly comfortable if we translate them into questions about protocol efficiency. That is, we consider a range of merits, rather than just stating flat rules about single decision attributes. To underscore the point that Marshall has been making: The IETF has a strong preference to use unencumbered technologies. When there is a choice between encumbered and unencumbered, the working group includes encumbrance into the range of factors it treats as important for evaluating alternatives. There are some unknowns about licensing. Some holders of IPR are helpful to resolving that easily and quickly. Others are more reticent. That become a component of the evaluation about the IPR factor. And so on. Generally this thread seems to be seeking determinacy for a matter that can only be made deterministic by a) ignoring IPR encumbrance, or b) rejecting all IPR encumbrances. The first is not compatible with IETF culture. The latter is not practical in some cases. So, what exactly do folks think is a practical kind of change to the current IETF policies? d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
Re: IPR at IETF 54
On Thu, 30 May 2002, Dave Crocker wrote: Generally this thread seems to be seeking determinacy for a matter that can only be made deterministic by a) ignoring IPR encumbrance, or b) rejecting all IPR encumbrances. The first is not compatible with IETF culture. The latter is not practical in some cases. So, what exactly do folks think is a practical kind of change to the current IETF policies? I think the most effective thing would be to send a strong signal of some kind: If you patent technologies and give non-RF licenses, _do not expect the technology be supported in IETF at all_. Cannot adapt internet-drafts with RAND terms as working group documents unless explicitly chartered to do so etc. (Though there could be a case-by-case appeals process or whatever -- if something really really major would show up.) A bad thing IETF could do (but not the worst luckily :-) is to give a signal Ok.. feel free to patent and give RAND licensing.. depending how good it is, we might give it a standards status or we might not. That _encourages_ to do patents (or try to), and we want to avoid that. That way, RAND and other restrictions would only be used to harass IETF progress (and those of their competitors) with patents that they never intend to go to standards. But we can't avoid that anyway. -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
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 at IETF 54
On Wed, May 29, 2002 09:10:20PM +0100, Graham Klyne wrote: How do we best approach the design of Internet technologies so that IPR-related obstructions to their deployment will be minimized? That assumes IPR-related goals are obstructions. For me they're a pain but I've been burned so I have no problem with people, including me, protecting themselves. Let's start one step back. How can we best approach the process of building and running the Internet to minimize conflict between technology goals and IPR-related goals? ..Scott
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 at IETF 54
sure is a lot of interest in this subject from diverse folk. maybe we should hold a wg/bof meeting on friday in yokohama to discuss it. randy
Re: IPR at IETF 54
On Wed, May 29, 2002 02:58:59PM -0700, Dave Crocker wrote: It is not clear that an entire week of discussion would be fruitful for that sort of deep and broad requirement for substantial process and concept invention, nevermind a couple of hours at the end of a long work-week, with little group preparation. Personally I'm not after solutions yet. IPR problems are lurking in many working groups. We're going to have to figure out new ways of dealing with conflicting goals, and it's going to take a change to the IETF culture to get enough people following them. Polemicized email arguments won't do it. There are only two ways to change IETF culture: (1) have people of influence issue a document of some sort and promote it for 3 years, or (2) have a plenary meeting and come up with a good sound bite to summarize a solution (like we reject kings, presidents and voting etc.). The first takes a long time. I don't expect to accomplish the second, but I'd like to allow for it.
Re: IPR at IETF 54
At 06:34 PM 5/29/2002 -0400, Scott Brim wrote: arguments won't do it. There are only two ways to change IETF culture: (1) have people of influence issue a document of some sort and promote it for 3 years, or (2) have a plenary meeting and come up with a good sound bite to summarize a solution (like we reject kings, presidents the sound bite came from a person of influence issuing it. yes, it happened to be at a plenary, but it was a thoroughly produced occurrence. At 03:35 PM 5/29/2002 -0700, Randy Bush wrote: sure is a lot of interest in this subject from diverse folk. maybe we should hold a wg/bof meeting on friday in yokohama to discuss it. Sopunds like we are targeting a free-form coffee klatch or encounter group, to let all us ignorant folk vent our feelings on this difficult legal topic, and we all hope that there is an accident of brilliance that instantly solves everything -- even though we haven't solved it in 12 years of effort? We seem to hold process-related IETF work to a very, very different standard of work specification than we hold for technical efforts. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] TribalWise, Inc. http://www.tribalwise.com tel +1.408.246.8253; fax +1.408.850.1850
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 at IETF 54
On 5/29/02 at 3:35 PM -0700, Randy Bush wrote: sure is a lot of interest in this subject from diverse folk. maybe we should hold a wg/bof meeting on friday in yokohama to discuss it. Oooo.that's a good idea. While we're on topics which generate a lot of interest from diverse folk, let's have a WG/BOF meeting on Friday in Yokohama to discuss the format of RFCs, and one more to talk about conformance testing. We could even have one to decide what top-level domain names we need, if you like. Look, as I've said now multiple times, I think it's peachy to have a session if we have something to discuss (where discuss is defined as participants interacting verbally). However, I'm not convinced by anything said so far that we do. So far I have gleaned that perhaps there will be some expert who will explain to us what we need to know. That can be done as a 0.5-1.0 hour presentation on IESG plenary night, or better yet can be written up as an I-D. If the latter, and there is *fruitful* discussion of the draft (where fruitful is defined as could benefit from high-bandwidth interaction), then its time to go ahead with a WG/BOF on the topic. But the discussion so far on this list does not seem ripe enough to warrant one. And overall I'm pretty darn sick and tired of wasting my time in WG/BOF sessions where all I get is a series of undiscussed presentations that could have been done in I-Ds which I could have read before the meeting. -- Pete Resnick mailto:[EMAIL PROTECTED] QUALCOMM Incorporated
Re: IPR at IETF 54
On Wed, 29 May 2002 15:35:26 PDT, Randy Bush said: sure is a lot of interest in this subject from diverse folk. maybe we should hold a wg/bof meeting on friday in yokohama to discuss it. Just remember to let us non-travellers know what happened. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08408/pgp0.pgp Description: PGP signature
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
