Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] RE: Comments from the Planning Council on the IP Process

Thanks for passing these along. Comments inlined below.
I would like to preface my comments by recognizing that the IP process does place a large burden on development at Eclipse. New projects in particular have a lot of work and lengthy delays to deal with. It sucks.
We at the EMO are doing some things to help improve the process. We've hired two more people to help with the process, and intend to have  IPzilla implemented by the end of September. I admit that we under-estimated the staffing required to support this process and it has taken us far too long to address the situation. But with the scarce resources we have, we really are trying to make things better as fast as we can.
However, it is important to remember that the EMO is charged with the responsbility of implementing the Eclipse IP Policy as it is approved by the Board. Many of the key suggestions below run counter to that policy. If we are going to be able to implement any of those ideas, the policy itself would have to be changed. As I have indicated below, if the Planning Council wishes to, I believe that it would be a worthy conversation to have with the Board. But from the EMO's perspective, I think it would be more helpful if we separated the conversation into two pieces: (a) process improvements we can make within the scope of the current policy, and (b) changes suggested by the Planning Council to the policy itself.

  • Transparency, especially of the status of a contribution questionnaire and its position on the queue  
I believe that IPzilla will directly address these. 
  • People should be able to run IP clearance in parallel with development. Perhaps a shadow repository. Or allow code to be checked in before it is reviewed, but just not released before it is reviewed. The goal is to prevent the legal review delay (no matter how short it is) from slowing down development.
    • Checkin-but-not-release seems like a good idea to us. What if we find that there is an IP violation? Do we need to remove the code from CVS? What happens now? Have we gone back and removed offending code in the past? How would that be different here?  
This has been explicitly discussed and rejected at the Board. If the Planning Council would like to make a direct representation to the Board in support of this, I think that would be a great idea. But the Board decision currently trumps the Planning Council request.
  • Project leads and PMCs need to be cc'd on CQs and replies. The status of CQs needs to be visible to submitters, project leads, and PMCs.  
I believe that IPzilla will directly address this. 
  • Self service tools for scanning by PMCs and PLs (and committers).  
I could imagine making the scanning tool available via committer tools so that they can pre-scan. But their analysis does not replace the EMO's. This will require lots of training and documentation, as the current tool is not exactly user friendly. But this is certainly a suggestion worthy of consideration.
  • Foundation-sponsored training for committers around IP responsibilities  
  • Earlier in the cycle for reviewing about.html files and such.  
  •  Aim for milestone M-n approval and "no new third-party stuff added after Mx"  
Agreed. But I would like to point out that everyone should be very careful about what they ask for. Depending upon the value of "x", a rigorous application of the "no new third-party stuff added after Mx" would (by my recollection) have resulted in both the Eclipse and WebTools projects not shipping in Callisto. As I recall in both cases there were components found very late in the release cycle.
  • legal@ should reply to emails in a timely manner  
Agreed. I also believe that IPzilla will help to address this. 
  • It takes too friggin' long.
    • Perhaps we can have quick provisional approvals.  
Believe it or not, we already do quick provisional approvals wherever we can. We also triage EPL contributions and try to turn those around ASAP. The third-party approvals take more time. As for the time of the approvals, we have grown the staff from one person to three people and will have IPzilla implemented by the end of September. Hopefully things will start to improve soon.

ACTION: [Bjorn FB] pass these along to legal@

I kind of liked the idea of allowing check-ins but not allowing releases before legal clearance because how is that different from what we do today when someone checks in bad code?  
Again, this has been explicitly discussed and rejected by the Board of Directors. 
Here's the problem: once code is checked into CVS and goes into the builds, we are distributing it. Once we are distributing it any and all license terms apply and any and all liabilities could be incurred. The current thinking is that this is a risk. I do very much appreciate that this risk reduction comes at a cost. Again, if the Planning Council wanted to re-visit this issue with the Board, I do believe that it would be a worthy conversation to have.  
Perhaps you could comment on that to the mailing list. 

Back to the top