Jim has a fine idea in principle, but in practice defensive patents are necessary. Keep in mind that the patent system is changing to first-to-file, from first-to-invent. Prior art is still not patentable, but the patent law still gives significant advantages to patent holders over public domain technology users. In a patent suit, by law the patent is to be presumed valid by the court. A patent could be filed on a novel improvement to the public domain technology, or on an unpublished but otherwise public domain technology that either all but obsoletes the PD work, or makes it somehow unusable. Without a defensive patent, it is impossible to obtain a cross license scenario that essentially negates the offensive patent. The current law strongly promotes patenting and disadvantages not patenting, which is an unfortunate fact that cannot be ignored. [The LPF and other organizations are working in various ways to change the patent law. There is a case that is going to be before the US Supreme Court which could invalidate software as a category, but we can't presume that case will be resolved in our favor. Though I might add that the general trend in patent law for over 400 years has been to restrict and reduce patenting, with some notable exceptions] Its also entirely possible that a novel patent may be so useful as to leave no choice but agreement to terms. Consider for example the fast fourier transform versus the fourier transform. Both do the same job at the end, but the FFT is so much faster that it makes real-time fourier analysis possible where it wouldn't even be doable with the unmodified fourier transform. There would be no choice but to accept the license terms on such a novel and incredibly useful invention. So the problem can't be removed, entirely. I think the basic procedure of RFC3979 is exactly right: Require disclosure, consider non-patented alternatives, and make an informed decision about the costs and benefits giving preference to unencumbered solutions where possible. The problems we have had with this procedure is that authors haven't disclosed, that working group chairs have suppressed the discussion of non-patented alternatives, or chairs have entirely disregarded RFC3979 altogether asserting that non-technical details are irrelevant or a 'rat-hole'. I think we need to consider the ways that people have tried to circumvent the procedures required by RFC3979, and to either close the loopholes if any, or impose penalties on the failure to comply with RFC3979. Most troubling is that IETF managers aren't complying with RFC3979 in WG discussions, and/or aren't requiring authors to comply with RFC3979. Altering any part of RFC3979 or altering required patent, copyright or trademark terms won't change non-compliance. So I think the only alternative, for managers anyway, is some sort of penalty, and perhaps better education about the policies of the IETF that WG chairs have to enforce. Compliance has to start with the WG chairs. --Dean On Fri, 15 Aug 2008, Bound, Jim wrote: > Have read all this thus far and complex problem/discussion and good to > have here. I know this is heresy to many vendors but I believe the > IETF should not permit at some date in the future any part of a > specification to have any IPR from any vendor that is accountable to > patents or royalties. In simpler terms anything we develop in the > IETF is public domain in the legal context, and we do not use any > vendor patents for any of our work. Just remove the problem entirely. > As specs are implemented IPR added value can be done by vendors and > inventors to improve and customize their product or invention to > attain larger ROI in the market competitively, but the base core IETF > specs are patent, royalty, and IPR free to all worldwide regardless of > geography or governmental boundaries. > > Disclaimer: This is my personal opinion and does not reflect the view > of the company I work for at all. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf