[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] 08 Sep 2010 - RT PMC call follow-up
|
Jesse,
The Committee is a Board Committee, so it is not usually open.
Save the dates for Eclipse Summit Europe, Nov 2-4
http://www.eclipsecon.org/summiteurope2010/
Mike Milinkovich
Office: +1.613.224.9461 x228
Mobile: +1.613.220.3223
mike.milinkovich@xxxxxxxxxxx
> -----Original Message-----
> From: Content-filter at foundation.eclipse.org
> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
> Sent: September-21-10 4:35 PM
> To: Janet Campbell
> Cc: emo-ip-team@xxxxxxxxxxx; Runtime Project PMC mailing list
> Subject: Re: [rt-pmc] 08 Sep 2010 - RT PMC call follow-up
>
> Is that IP Advisory Committee meeting open for general attendance? I
> would quite like to be a fly on the wall.
>
> cheers,
> jesse
>
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
>
>
>
> On Tue, Sep 21, 2010 at 15:20, Janet Campbell
> <janet.campbell@xxxxxxxxxxx> wrote:
> > Thanks Jeff,
> >
> > The issues you raise are representative of the kind of things I would
> expect
> > to be discussed at the IP Advisory Committee. Tomorrow’s IP Advisory
> > Committee meeting has been cancelled, and I have deferred the
> conversation
> > on this topic to the next regular meeting which is October 6th. We will
> > certainly factor these thoughts into our proposed revisions to the
> Policy.
> >
> > Thanks,
> >
> > Janet
> >
> > -----Original Message-----
> > From: Jeff McAffer [mailto:jeff@xxxxxxxxxxxxxxxxx]
> > Sent: Saturday, September 18, 2010 11:44 AM
> > To: Runtime Project PMC mailing list
> > Cc: 'Jesse McConnell'; emo-ip-team@xxxxxxxxxxx
> > Subject: Re: [rt-pmc] 08 Sep 2010 - RT PMC call follow-up
> >
> > Thanks for the update Janet. I do have a few questions/clarifications.
> >
> > - When you say "test suite" here what do you mean? Typically the test
> suite
> > is written by the Eclipse project team so its a bit odd to have Eclipse
> > originating code be an exempt prereq. What we are really talking about is
> > random libraries that the Eclipse project test suite might need in the
> > course of running the tests. While there likely are cases where we get
> whole
> > test suites from a third party (e.g., the OSGi tests), that is not the
> case
> > we are talking about here.
> >
> > - Are you specifically focussing on test-related code? The general
> problem
> > we are facing relates to prereqs that do not "ship". Testing is certainly
> > one of those cases but there are others. Build-time prereqs (e.g.,
> > annotation processors and the like) may also fall in this category.
> >
> > - Given that the subject of this effort (build, test and similar code) is
> > not actually consumed by the broader community, is there a chance that
> > listing these libs as exempt prereqs actually mislead consumers into
> > believing they need more than they really do?
> >
> > - These seem to point to a missing a concept in the IP policy. In a
> previous
> > post I mentioned the idea of "Released Content" (and its complement).
> While
> > I am not wed to that precise idea, it does seem like we are skirting the
> > issue. For example in documenting the exempt prereqs that arise out of
> your
> > proposed approach, we will need to identify the prereqs as "only for xxx"
> > (where xxx = build, test, ...) as in "you won't need this to actually use
> > the project's output". It seems that we should reify that concept into
> > something well-defined.
> >
> > - A step like this is good progress but we also need clarifications on
> what
> > kinds of third party use qualify. We started this process with a basic
> > confusion over how various uses should be classified and handled. This
> > gives us a means to handle with some types of uses but we need to nail
> down
> > very concretely what those uses are.
> >
> > - Can you comment on the workflows, roles and responsibilities involved
> > here? As I understand the policy, the EMO has to approve exempt prereqs.
> > Does there need to be a CQ? A PMC mailing list discussion? Other? If
> there
> > are multiple steps, what is the order?
> >
> > - Why is a license compatibility check needed? If for example a project
> > wanted to use MySQL (GNU licensed) to test against should this matter?
> > Assuming of course that there are no runtime or other requirements
> directly
> > on MySQL but rather "a database". Going back to the motivation for the
> IP
> > policy, our end-user community will know like know or care what database
> is
> > used.
> >
> > Jeff
> >
> > On 2010-09-17, at 2:47 PM, Janet Campbell wrote:
> >
> >> A quick update for everyone. We’ve reviewed our Policy – Guidelines for
> > the Review of Third party Dependencies [1] – and had a follow on
> discussion
> > with Jesse that was quite helpful. What I would like to propose for
> > discussion is that we introduce a modification to the definition of an
> > exempt prerequisite under the Policy to include test suites. While it
> > would still be necessary to document the use of the suites, the approval
> of
> > the use of them would be quite straightforward and no due diligence
> beyond a
> > license compatibility check would be required.
> >>
> >> We believe the proposed change would address many of the concerns raised
> > while maintaining the risk balance we seek to maintain at Eclipse. I
> plan
> > to introduce this proposed change at the next IP Advisory Committee
> meeting
> > on Wednesday of next week so if you have any concerns regarding this
> > approach, please let me know as soon as possible.
> >>
> >> Regards,
> >> Janet
> >>
> >> [1]
> >
> http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_P
> a
> > rty_Dependencies_Final.pdf
> >>
> >>
> >> -----Original Message-----
> >> From: Janet Campbell [mailto:janet.campbell@xxxxxxxxxxx]
> >> Sent: Tuesday, September 14, 2010 5:08 PM
> >> To: 'Jesse McConnell'; 'Runtime Project PMC mailing list'
> >> Cc: 'emo-ip-team@xxxxxxxxxxx'
> >> Subject: RE: [rt-pmc] 08 Sep 2010 - RT PMC call follow-up
> >>
> >> We appreciate everyone’s comments, understand your pain and are
> actively
> > looking into how we can alleviate the burden while maintaining the
> balance
> > of risk at Eclipse.
> >>
> >> We want to make sure that we find the right solution and so we ask for
> > your patience while we figure out how to best address your concerns.
> >>
> >> Regards,
> >> Janet
> >>
> >> Janet Campbell
> >> Director, Intellectual Property
> >> Eclipse Foundation, Inc.
> >>
> >> -----Original Message-----
> >> From: Content-filter at foundation.eclipse.org
> > [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
> >> Sent: Tuesday, September 14, 2010 4:26 PM
> >> To: Runtime Project PMC mailing list
> >> Cc: emo-ip-team@xxxxxxxxxxx
> >> Subject: Re: [rt-pmc] 08 Sep 2010 - RT PMC call follow-up
> >>
> >> Jeff, I think we are totally on the same page here..imo we just need a
> >> definitive statement that our basic view of the world can be
> >> effectively reconciled with IP policy and we should be good to go...
> >>
> >> so much of this is (I think) pretty common sense, its just making sure
> >> that what I/we think of as common sense passes the legal litmus test
> >> sufficiently :)
> >>
> >> fwiw I am tickled to see these distinctions being discussed
> >>
> >> cheers,
> >> jesse
> >>
> >> --
> >> jesse mcconnell
> >> jesse.mcconnell@xxxxxxxxx
> >>
> >>
> >>
> >> On Tue, Sep 14, 2010 at 15:15, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
> > wrote:
> >>> Thanks for the update Jesse. I really think that we are dealing with a
> >>> conceptual and terminological mismatch here.
> >>> A bit of context. The IP policy is in place largely
> >>> "to provide information and mitigate risk relevant to the
> >>> adoption and use of Eclipse projects in commercial products."[1]
> >>> Looking at the current IP policy [0] there appears to be a gap. We
> have
> > the
> >>> following terms:
> >>> “Content” is copyrightable material, including without limitation
> > software,
> >>> documentation, articles, whitepapers, and presentation materials.
> >>> “Distributed Content” is Content which is distributed by the Eclipse
> >>> Foundation via its Repository or other means in a manner consistent
> with
> >>> this Intellectual Property Policy.
> >>> “Eclipse Content” is Distributed Content intended to be developed or
> >>> modified by one or more Eclipse Projects (as that term is defined by
> the
> >>> Eclipse Development Process), regardless of the license or licenses
> that
> >>> govern the use of that Content.
> >>> “Non-Eclipse Content” is Distributed Content which is not Eclipse
> > Content.
> >>>
> >>> The notion of "Released Content" (potential new term) does not appear
> > here.
> >>> Released Content is the Distributed Content that we intend or expect
> our
> >>> adopters and users to consume. In the absence of this term there is an
> >>> implicit assumption that any and all Distributed Content is intended to
> > be
> >>> "used" by our end-users. Many of the cases at hand here relate to
> >>> Distributed Content that is not yet (or will never be) released and is
> > not
> >>> intended to be used by anyone other than the committers/contributors.
> For
> >>> example, tests. In [2] Barb signal towards this distinction by
> > acknowledging
> >>> that some people will get code from an "Eclipse repository before it is
> >>> “officially” released by a project". That is, there is Distributed
> > Content
> >>> that is Released and Distributed Content that is not.
> >>> In the absence of this distinction, Section IV of the policy has no
> > choice
> >>> but to say that all Distributed Content has to go through the IP
> process.
> >>> This is the problem.
> >>> In [1] Mike M recognizes this challenge when he says
> >>> "...test-time or build-time dependencies that are simply an artifact
> >>> of our production processes likely require IP processes which vary
> > somewhere
> >>> between minimal and none."
> >>> Similarly, speaking of the yet to be released Content in [2], Barb
> >>> acknowledges agrees that "this small risk would not justify the adverse
> >>> impact such additional controls would have on the community".
> >>> Summary: Recognizing that the constituents for whom the policy is in
> > place
> >>> likely don't know or care what is used to test the things they consume,
> > it
> >>> is hard to motivate considerable additional work for the IP team or the
> >>> committers to deal with Content that "will never see the light of day"
> as
> >>> Released Content.
> >>> To be clear, I am in now way suggesting that all test code be
> >>> IP-process-free. I am however suggesting that there are clearly some
> > chunks
> >>> of code or dependencies that matter only at points in time that have
> > little
> >>> to do with our adopter community. The IP policy should capture this.
> >>> Jeff
> >>> p.s., While INAL I thought it would be fun to put forward a definition
> of
> >>> Released Content:
> >>> "Released Content" is Distributed Content that is intended by the
> > producing
> >>> projects to be adopted or used by their end-user community. Released
> > Content
> >>> would include but not be limited to Distributed Content that has been
> or
> >>> will be the subject of a Release Review.
> >>> [0] http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf
> >>> [1] http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg01595.html
> >>> [2] http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg02007.html
> >>> On 2010-09-14, at 3:12 PM, Jesse McConnell wrote:
> >>>
> >>> I had a talk with Barb about this a bit and wanted to follow up on
> >>> this thread with this blurb from our conversation...
> >>>
> >>> my current frustration with the IP policy/procedure is the existence
> >>> of a 'safe on the build server' classification for some things. In my
> >>> little slice of heaven we write software that builds straight out of
> >>> svn...and the current definition of 'distribution' includes what is in
> >>> svn...which means that I am unable to make use of this 'safe on the
> >>> build server' classification of IP. From what I hear the whole 'safe
> >>> on the build server' exists because there is an explicit understanding
> >>> that the builds produced on the build server are not 'eclipse
> >>> distributions'.
> >>>
> >>> so I don't understand how there exists a case where a build occurring
> >>> on the eclipse build server is not a distribution but somehow software
> >>> being built from something checked out from SVN is some how an
> >>> 'eclipse distribution'. I understand that is absurd and its not
> >>> 'really' but if I want to open a CQ to use something like apache
> >>> directory service its basically a rubber stamp if I have it on the
> >>> build server and use it there, but if my build system has an actual
> >>> 'dependency' declared on it for usage in a test case (not going into
> >>> my distribution at _all_, just a unit test) it is suddenly a full
> >>> fledged dependency (because there is no distinguishing between test
> >>> scope or distribution scope).
> >>>
> >>> cheers,
> >>> jesse
> >>>
> >>> --
> >>> jesse mcconnell
> >>> jesse.mcconnell@xxxxxxxxx
> >>>
> >>>
> >>>
> >>> On Mon, Sep 13, 2010 at 15:45, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
> > wrote:
> >>>
> >>> Hey Barb,
> >>>
> >>> Thanks for the additional info. Comments embedded.
> >>>
> >>> Jeff
> >>>
> >>> On 2010-09-13, at 2:11 PM, Barb Cochrane wrote:
> >>>
> >>> 1) Eclipse-developed test code deposited in the repository
> calling
> >>>
> >>> third party test code which does not reside on Eclipse servers.
> >>>
> >>>
> >>>
> >>> Ø In the cases described, third party code could be characterized
> > as a
> >>>
> >>> “workswith” or perhaps “exempt pre-req”
> >>>
> >>> Can you clarify "could"? Is it "should" or "must"?
> >>>
> >>> As I recall from the discussion there were various shades here. There
> are
> >>>
> >>> a) test setups that just need some other function to be present but do
> > not
> >>>
> >>> reference this function directly in any code.
> >>>
> >>> b) test setups that need specific function to be present but still do
> not
> >>>
> >>> reference the function directly
> >>>
> >>> c) test setups that directly reference the third party libraries but
> that
> >>>
> >>> function is not part of the actual released output of the project
> >>>
> >>> Other scenarios where the third party references come from (to be)
> > released
> >>>
> >>> project output are easier to handle as classical dependencies. The
> > subtlety
> >>>
> >>> in the above comes from the absence/presence of direct references and
> the
> >>>
> >>> fact that test code is not generally released so is not typical
> > consumable
> >>>
> >>> project output. That is, we don't expect any significant number of
> people
> > to
> >>>
> >>> get this code (see case 2 below). Under that model, scenarios a-c above
> >>>
> >>> would be instances of case 2.
> >>>
> >>> Ø The process outlined in the Guidelines for the Review of Third
> > Party
> >>>
> >>> Dependencies would apply (as there is no distinction made based on the
> > type
> >>>
> >>> of code involved)
> >>>
> >>> Ø It is our understanding that the dynamic nature of calls to
> these
> >>>
> >>> third party packages would make the task of creating CQs for each
> package
> > an
> >>>
> >>> extraordinarily heavy burden
> >>>
> >>> Ø The IP team is in the process of reviewing the IP Policy to try
> > to
> >>>
> >>> identify what we can do to alleviate this burden. Janet will raise any
> >>>
> >>> suggested changes to the Policy to the IP Advisory Committee as
> > necessary.
> >>>
> >>>
> >>>
> >>> 2) A risk was identified in that there are a small number of
> >>>
> >>> bleeding-edge developers (low single percentage of users) who may
> > download
> >>>
> >>> code from the build server or from the Eclipse repository before it is
> >>>
> >>> “officially” released by a project. In either case, the downloader may
> >>>
> >>> consume code that has not been fully reviewed / approved by the IP
> team.
> >>>
> >>> We appreciate this risk being highlighted but feel the additional
> > controls
> >>>
> >>> necessary to eliminate this small risk would not justify the adverse
> > impact
> >>>
> >>> such additional controls would have on the community.
> >>>
> >>>
> >>>
> >>> 3) There was a question raised as to why CQs are required for
> >>>
> >>> “workswith” dependencies, but not their further dependencies. In the
> > case
> >>>
> >>> of dependencies, we are trying to highlight to our downstream consumers
> > the
> >>>
> >>> Eclipse Project dependencies in such a way so that they may investigate
> >>>
> >>> further and make decisions accordingly. In so doing, we must determine
> > what
> >>>
> >>> level of information is reasonable to provide given our resource
> >>>
> >>> constraints. It was felt that the first level of information regarding
> >>>
> >>> dependencies struck a reasonable balance given our current staffing
> > levels.
> >>>
> >>>
> >>>
> >>>
> >>> I hope that helps. If an additional conference call would be useful,
> >>>
> >>> please let me know. I hope to update you further on the first topic in
> > the
> >>>
> >>> next couple of weeks.
> >>>
> >>>
> >>>
> >>> Cheers,
> >>>
> >>>
> >>>
> >>> Barb Cochrane
> >>>
> >>> Eclipse Foundation, Inc.
> >>>
> >>> Phone 613.224.9461 ext 232
> >>>
> >>>
> >>>
> >>> Eclipse Summit Europe, Nov 2-4
> >>>
> >>> http://www.eclipsecon.org/summiteurope2010/
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>>
> >>> rt-pmc mailing list
> >>>
> >>> rt-pmc@xxxxxxxxxxx
> >>>
> >>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >>>
> >>>
> >>> _______________________________________________
> >>>
> >>> rt-pmc mailing list
> >>>
> >>> rt-pmc@xxxxxxxxxxx
> >>>
> >>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >>>
> >>>
> >>> _______________________________________________
> >>> rt-pmc mailing list
> >>> rt-pmc@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >>>
> >>>
> >>> _______________________________________________
> >>> rt-pmc mailing list
> >>> rt-pmc@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >>>
> >>>
> >>
> >> _______________________________________________
> >> rt-pmc mailing list
> >> rt-pmc@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> >
> >
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
