Bjorn,
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
Agreed.
- Earlier in the cycle for reviewing about.html files and such.
Agreed.
- 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 eclipse.org-planning-council@
mailing list.
Done.