RE: [eclipse-pmc] contributed keyword

["Mike Milinkovich" <mike.milinkovich@xxxxxxxxxxx>]

Eugene, 

My comments were general. They apply to all Eclipse community projects.

But be careful of semantics. There are many cases where committers access
controls are set to a specific set of components. They can only commit to
those components. That is not what I was talking about. I was referring to
the scenarios where the Eclipse Foundation IP due diligence process would
kick in. 

It is possible that a PMC could decide to institute IP controls at a finer
granularity (e.g. component) than what the EMO requires (e.g. project). If
they did so, that would be fine with us. Just don't blame the EMO for the
extra paperwork :-D

Mike Milinkovich
Office: +1.613.224.9461 x228
Mobile: +1.613.220.3223
mike.milinkovich@xxxxxxxxxxx


> -----Original Message-----
> From: Eugene Kuleshov [mailto:eu@xxxxxxxx]
> Sent: Thursday, June 07, 2007 12:27 PM
> To: mike.milinkovich@xxxxxxxxxxx; eclipse-pmc@xxxxxxxxxxx
> Subject: Re: [eclipse-pmc] contributed keyword
> 
> Mike, Philippe,
> 
>   Does this ally only to Eclipse Platform or to Technology and Tools
> projects too?
> 
>   Reason I am asking is that there are projects that do have
> per-component commit restrictions for committers.
> 
>   Thanks
> 
>   Eugene
> 
> 
> Mike Milinkovich wrote:
> > My apologies if I'm intruding, but hopefully this EMO perspective
> will help
> > the conversation.
> >
> > If an individual has the paperwork in place to be a committer on a
> project
> > and writes code which is committed to the project's repository then
> no
> > further documentation is required. Regardless of whether they are
> "active"
> > or "inactive" or work for their former employer. As long as their
> paperwork
> > is in place and up-to-date, they are a committer.
> >
> > This would also apply if a committer writes some code which is
> committed to
> > another component within the same project by another committer.
> >
> > If a committer writes some code which is committed to another project
> for
> > which they do not have commit rights (presumably by a second
> committer),
> > then they should be documented as a contributor, as commit rights are
> scoped
> > to a project. Basically we just want some housekeeping in place so we
> can
> > track the origin of the code. Yes, this may mean that a CQ is
> required :-(
> >
> > In the case of a contributor, we don't differentiate between doc,
> code, XML,
> > whatever. If a contribution is made that ends up somewhere in CVS,
> then it
> > should be documented in the IP log and/or whatever mechanism your
> project is
> > using. So the formal definition of what a contribution is not based
> on what
> > the type of artifact is, it is based on whether copywritable material
> ends
> > up in CVS or SVN.
> >
> > That said, as a practical matter release reviews focus on the
> copywritten
> > materials which actually ship in a release. So patches to (for
> example) web
> > projects receive less scrutiny and are lower risk. So I believe the
> PMC has
> > some discretion there if the cost/benefit trade-off is prohibitive.
> >
> > Basically, the questions that we are always seeking to answer are:
> can we
> > demonstrate *who* wrote this copywritten material, and is there a
> trail that
> > demonstrates that we have the permissions in place to distribute it.
> > Individuals covered under a committer agreement and employer consent
> are
> > obviously in good shape. But since the employer consent forms may be
> limited
> > to a specific project, crossing project boundaries require additional
> > documentation.
> >
> > I hope this is helpful.
> >
> > Mike Milinkovich
> > Office: +1.613.224.9461 x228
> > Mobile: +1.613.220.3223
> > mike.milinkovich@xxxxxxxxxxx
> >