RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, On the one hand, let's just get started figuring out how the promise / request can be made so that it's not a burden to the open source community. I'm asking for input. Maybe a comment in the open-source source code (the way the EAY disclaimers read atop OpenSSL files for example) is sufficient to publicly request the GUL. Maybe that also satisfies the install disclosure as well, at least as far as the open source provider is concerned. I'm open to reasonable suggestions here. And I have benefited from Simon's pushback so far. My revised sense is that those who publish source code, such that promises embedded within that source code also get published, don't need to write a postcard. Those who are keeping their source code as a secret will need to notify RedPhone Security of their acceptance of the GUL more explicitly than in source code comments. On the other hand, I want to ask open source providers who accept the GUL to avoid knowingly trafficking in PAS Function implementations. Here's an analogy: PAS Function implementations aren't kiddie porn, but all the same they're not very compatible with public ftp sites, etc. In the analogy I mean this: In some countries, users of PAS Functions could/may be doing something illegal if that user doesn't have a license. I want to ask GUL-compliant open source publishers to discard contributions that implement PAS Functions, e.g. not roll them up into a release. This is my personal opinion of the GUL: IF person X, who doesn't participate in (or know about) the GUL makes a PAS Function, that's RedPhone Security's concern, not any open source provider's. If person X checks PAS Functions into a development/unstable source code tree operated by a GUL licensee, then I'd expect the GUL licensee to just delete that contribution when it's discovered, and not worry any further about it. In my mind, a scenario that violates the GUL would be where person X contributes (checks into source control), and a GUL licensee accepts the contribution, and that licensee functionally tests and approves the PAS Functions (thereby confirming that the contribution performs the PAS Functions described in the GUL), and then that licensee releases the PAS Functions as a stable / blessed build. That seems to me to be a three strikes and you're out GUL violation. In saying this, I'm trying to be flexible. I could go farther and try to work out more detailed scenarios that might reduce risk and burden, but I'd just be guessing. Instead, let me stop here and ask for input. Is there burden in putting a comment in source code that recites the RPS GUL, or is the burden in the postcard? I'm open to suggestions on the mechanics for making the GUL promise. Is it risky that a (possibly open source) software provider might accidentally but in good faith cruise through all three strikes with respect to the PAS functions (accept, test and release) and that their GUL might be void until things get patched up with RedPhone Security? Then let me know what risks are of concern so I can try to address them. To be fair, I can see that the open source community probably bears a higher burden to keep PAS Functions out of their source code, so I would like to try to ease the burden of requesting the GUL. So I'd like to work this out, but I will need some clear and direct feedback to get it right. Best regards, mark -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 11:23 AM To: Mark Brown; 'Simon Josefsson' Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns --On Monday, 23 April, 2007 17:17 -0500 Mark Brown [EMAIL PROTECTED] wrote: ... My understanding is this: The request for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. ... Mark, with the usual IANAL qualifications, I've seen lots of general, you don't need to ask us licenses that contain this license is valid only as long as you refrain from doing the following things... language. The most common form of that language involves provisions about not suing the company granting the license, but that is by no means the only version. At least a few of the organizations that have written such licenses are very big players in the patent game. So, while reasonable people (and I assume lawyers :-( ) may disagree on how far it is necessary to go to get people to explicitly agree to those provisions, I infer that some organizations
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, I should have responded in my last email: I think you are being told --by a number of people and in different ways-- that there is a perception that having to ask for a license is seen as appreciably more burdensome and, for various reasons, risky than if a general license is granted without an application process. My impression is that is a general perception around the IETF, not just related to your work or proposal. So, rather than (or at least in addition to) telling others to go consult their lawyers to find out whether they could possibly work with your licensing requirements, I would encourage you to go back to your own and see if you can either (i) get the requirement to formally apply to you for a license removed or (ii) get a really good explanation as to why no strategy other than such an application is sufficient to meet your organizational needs. Sure, I can do that too. I'm a newcomer to the IETF, and sometimes I find myself a bit out of the loop regarding the general perception around the IETF. I appreciate you filling me in. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Hi Simon, It would be useful if you could explore with your lawyers if it is actually easy for you to avoid problem (1). I'm wondering what exactly the requirement for implementers to request this license from you gives you. Your text suggest that you will never refuse to grant the rights in your license to someone who ask, is that right? If so, what problem would there be in granting the rights immediately to everyone, without a need to request it from you? Is your reason that you want to know who is using your IPR, and open up a communication channel with them? To solve that concern, you could write a request that everyone is requested, but not legally required, to get in touch with you. That would get you into contact with the majority that is positive about talking with you, and you wouldn't need to hear from people who doesn't want to talk with you. My understanding is this: The request for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. Replacing the need to request a license from you with a requirement to place a comment in header files to make things clear to end users may be acceptable, possibly barring the problem in the next paragraph. This is basically the same as giving the rights directly to everyone, without a need to contact you. So it seems you have already started leaning towards that solution. (It is important that you do not require that the comment is placed in all advertising material, or similar, or you will run into the problem that the original BSD license had with GPL-compatibility.) Making the GUL promise costs no money (that part is free); I hope it doesn't cost anybody any time to _not_ implement the PAS Functions; and I don't want to make the mechanics of making the request / promise cost a lot of time either. But the GUL promise as valuable consideration is the cost of the GUL to Manufacturers. As far as I can see, it's not ok to omit this. I hope many people find the offer attractive. As I mentioned, I'm open to suggestions and feedback on the mechanics of making the request. Another basic problem is that free software projects may not be able to agree to your field-of-use limitation in (2) and at the same time be compatible with license such as the GNU General Public License. Thus they would never be able to implement tls-authz even without any support for PAS under your license. I am not certain of this, but I could ask the Free Software Foundation's lawyers about this -- they are the copyright holder of GnuTLS which implements tls-authz without PAS today, and can speak authoritatively about this. I would appreciate if you would follow up with your lawyer(s) on this question. As I've said before, I believe that even if GNUTLS/FSF (for example) made the GUL promise, its software would continue to be free to use because only GNUTLS (or whatever parent organization) would be bound to honor that promise. I hope your lawyers will find this to be true. Best regards, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, You observed: Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I believe that is required even for patent applications. RFC 3979 talks about patent applications in several places. You're right, please let me correct myself again here. My use of the term disclosure was sloppy. Here's what I was told by IESG: The IESG has been informed by Mark Brown that he had knowledge of the September 2005 patent application filed by his employer at the time he submitted draft-housley-tls-authz-extns. Accordingly, he was obligated to disclose the existence of this patent application upon making this submission. Making a required IPR disclosure after a draft is approved does not meet the requirement to promptly make the disclosure. According to section 7 of RFC 3979 failure to make a required disclosure is a failure of process. It should be noted that the above disclosure obligations apply to unpublished patent applications. When a patent application that is required to be disclosed is unpublished, the discloser must 'indicate that the claim is based on unpublished patent applications', but is not required to list the application number (see RFC 3978 Section 6.4.1). The content of the IETF-required IPR disclosure is this: 1. (YES) the discloser must 'indicate that the claim is based on unpublished patent applications' Not these: 2. (NO) list the application number (see RFC 3978 Section 6.4.1). 3. (NO) otherwise publish to the IETF the pending patent claims or description of the invention disclosed in any unpublished patent application(s) What I meant to say in my earlier email is that I don't think IETF requires disclosure of the body of the patent application, it's claims, etc. as in (3). I recognize that IETF does require the required IPR disclosure made via http://www.ietf.org/ipr-instructions as described in (1). This probably isn't news to any of you, but I wanted to correct my sloppy use of the term disclosure. Thanks, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Harald, I want to apologize again for screwing up the IPR disclosure process. Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I finally made my disclosure on the IETF website (what I mistakenly thought was a second disclosure) after my patent got published. And, in all honesty, even this disclosure got delayed because I sought advice. Please note that the filing's publication, the delay, and the IPR disclosure all happened after the last IETF approval for the ID. The right thing to do is to use the IETF website the very day your file your first ID, and not hope that the verbiage atop the ID will somehow disclose that IPR filings are in progress. As a result of my mistakes, the IETF withdrew approval of the ID and explained the process to me. That's fair. But please keep in mind that even for important things, it's easy to make mistakes your first time through a process. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb 2006) in good faith. It is possible that the patent claims can be read more broadly than I expected, but that's a fairly detailed and unresolved legal question. I am working diligently to -- let me speak carefully -- explore if and how I can make a royalty free license grant to ensure that promoting TLS authz continues to be an act in good faith, while still protecting a way for my company to make money on its IPR. I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. I think IPR questions are complicated in part because for some questions only a lawsuit can answer the question -- but we should all want to stay clear of these kinds of lawsuits! So answers seem to me to be in short supply. I want to craft the proposed license to make this situation a little clearer than that, but doing so often involves taking risks of giving away a huge loophole. So I'm working to get good legal advice. In short, I am working to create a royalty-free license grant -- hopefully I can disclose it next week. With some luck, it will clarify the situation. Best regards, mark -Original Message- From: Simon Josefsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 10:12 AM To: Sam Hartman Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED] Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns Sam Hartman [EMAIL PROTECTED] writes: Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? If the patent concern is valid and covers TLS libraries or other applications, no. However, as far as I am aware of the public information that is available, the situation appears to be that we don't know whether these patents apply and to what extent. I don't know whether the patents were filed in good or bad faith. More information from the patent holders may help here. If it is possible to implement the protocol without violating the patents, I would support publication. I've seen some claims that this may be possible. I have no interest in reading these patents myself, but my position would be influenced if someone knowledgeable reads the patents. Given the amount of patents out there, it would be unreasonable for us to move everything to informational just because someone finds something that may be relevant to a piece of work. The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
