>>>>> "Mark" == Mark J Nelson <Mark.J.Nelson at sun.com> writes:
Mark> - We must allow for external CRT Advocates, and must treat them as Mark> first class citizens, able to evaluate any incoming RTI from any Mark> external contributor or Sun employee. I like this goal. Some implications that I didn't see called out in your email: - the list of WebRTI advocates will be different than the list of OpenRTI advocates - policy changes (e.g., for incoming open source) will need to be promptly communicated to the CRT, because external advocates won't see the internal emails Mark> A possible solution: Mark> Clarify and codify the deterministic conditions that affect the Mark> choice of internal/webrti vs external/openrti. In each tool, when Mark> creating a new, marketing release RTI (name likely to change?), Mark> start with a series of questions. As a function of those answers, Mark> either allow creation of the RTI, or refer the user to the other Mark> system. This seems reasonable, and a better solution doesn't immediately come to mind. We'll still need to allow for the case where an RTI gets created in one system, and then it's determined it should be in the other system. Mark> 3. Did you use any information considered proprietary or Mark> confidential to Sun when you wrote this code? s/to Sun/to Sun or any third party/ (I know, it's just a sample question, but I thought it better to note this now.) Mark> - emancipation efforts, which would require both open and closed Mark> pushes, but which should generally involve open RTIs Well, we'd like the RTI to be open, but I don't see how to do it, and I'm not sure it's worth spending the time to figure it out. I'd just treat it as a sponsored putback and use a closed RTI. Mark> - integration of open source projects covered by an OSR Mark> (typically, 3-clause BSD licenses, but others also apply), which Mark> should be open, but which have tentacles into Sun's legal Mark> processes I suspect these will end up being closed RTIs. Some sort of internal involvement will be needed in any event to deal with the legal processes. Mark> An alternative, from a devil's advocate point of view: what if Mark> another company wants to contribute, in a way that protects their Mark> own corporate information and/or security? Hmm. I guess this affects the wording of your question 3 (about proprietary/confidential information). We want to support the case where company XYZ is contributing an open-source driver even if the complete specs for the hardware are not open. And we'd want to make sure we deal with closed-source firmware sensibly (e.g., wifi drivers). Mark> Should this whole thing ultimately evolve into "we're ALL simply Mark> subject to the SCA, and we all use openrti for every integration Mark> to the open gate, regardless of our employment, and we assert as Mark> part of filing an RTI that we have done due diligence, following Mark> all applicable corporate policies and procedures, regardless of Mark> the 'corporation' in question?" Part of what the RTI provides is an audit trail. If every putback to the open tree goes through openRTI, and openRTI has nothing linking it to Sun's legal processes, you'll need to provide that link somewhere else, so that you keep that part of the audit trail. mike
