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 who are > probably not naive about these things have concluded that an > application process is not necessary. > > Now I want to turn the logic of your note around. You and/or > RedPhone Security have presumably concluded that you would > derive some value from having the IETF publish this document, > preferably on the standards track. I don't need to speculate as > to where on the spectrum between altruism, a belief that it > would enhance your reputation(s), or a belief that having this > out there as an RFC would enhance your ability to market the PAS > bits that you are not giving away to conclude that you see > _some_ benefit to yourselves or the larger community: if you > don't, the investments you have clearly made in this would be > dumb and I have no reason to believe that you, your > organization, or your lawyers are dumb. > > Without getting into a discussion about whether particular > provisions are or are not usable by particular communities, I > assume it is clear to everyone that, if an encumbered technology > is proposed for standardization, the IETF's rules require making > a decision as to whether or not the technology is important > enough to justify accepting the encumbrances. For me, at least, > that isn't a binary decision -- it involves weighing the level > of encumbrances and/or aggravation in working around them > against that perception of importance. > > 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. > > In my personal opinion, and given that experts in the relevant > parts of the community are telling us that this technology is > not critical to the most-important functions of TLS, if you > can't or won't do that, the IETF should simply conclude that our > interests in publication of this material are not sufficient to > overcome the disadvantages of the encumbrances, stop spending > time on this discussion, and move on. > > john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
