Title:              How to Incorporate Non-EPL Content into TPTP

Author(s):    Paul Slauenwhite (paules@ca.ibm.com)

Version:        February 1, 2005

Since:            January 19, 2005

 

Contents:

 

  1. Introduction
  2. Process
  3. Contacts
  4. References

 

Introduction:

           

Occasionally, the Eclipse Test and Performance Tools Platform (TPTP) Project Developers, Committers and Project leads may want or need to incorporate non-EPL content into TPTP to achieve architectural goals.  For example, the org.eclipse.hyades.logging.log4j plug-in provides Logging Agent and Common Base Event support for the Jakarta Log4J logging facility provided by the Apache Software Foundation.  The Jakarta Log4J logging facility is required for compilation and execution of the code provided in the org.eclipse.hyades.logging.log4j plug-in.  As such, the Jakarta Log4J binary code is contained in CVS for compilation and shipped with TPTP for run-time compatibility under the org.apache.jakarta_log4j_logging plug-in.

 

Prior to committing any non-EPL content in the TPTP Project CVS, approvals must be secured from the TPTP PMC and the Eclipse EMO and BOD.  This document details the steps that TPTP developers, committers and project leads would follow to incorporate non-EPL content into TPTP.  The content in this document is based on the experiences of incorporating the Jakarta Log4J logging facility into TPTP.  As such, this document may stale and may not be exhaustive or faultless over time due to evolvement of TPTP and Eclipse project practices and processes.  Instead, the information contained in this document should be used as a reference with the tacit assumption that the official Eclipse Intellectual Policy (IP) policy governs.

 

 

Process:

 

1.       Determine if the non-EPL content is absolutely necessary to satisfy the architectural goals of the component, its project, the TPTP project and the Eclipse project.  That is, no internal substitute content exists in the TPTP or Eclipse projects that may be utilized or modified to fulfill the requirement.  In some cases, designing and implementing new substitute content for the TPTP project may be more beneficial in the long term than using non-EPL content.  Internal content has the advantages of increased maintainability, controllable pedigree and a natural alignment with the architectural goals of the component, its project, the TPTP project and the Eclipse project.

 

2.       Tabulate a checklist of vital information to evaluate the request to incorporate non-EPL content into TPTP.  The checklist should include the following information as required by the Eclipse Foundation Intellectual Property (IP) Policy:

 

a.       TPTP project(s), component(s) and plug-in(s) requesting the non-EPL content.

b.       Committer(s) and Project Lead(s) requesting the non-EPL content.

c.       Version or version series of TPTP to incorporate the non-EPL content.

d.       Package, component and/or given name including governing organization, distributor and project leaders.

e.       Version or version series of the non-EPL content to be included in TPTP.

f.        History (e.g. project conception date and version history) and origins of the non-EPL content to determine its pedigree (e.g. free of General Public License (GPL) content and any other infringements).

g.       List any pedigree and architectural concerns with the non-EPL content and their implications for the component, its project, the TPTP project or the Eclipse project.

h.       Author(s) and contributor(s) to the non-EPL content.

i.         Current license name (e.g. CPL), version (e.g. v1.0), text as an appendix and determination if the author(s) and contributor(s) of the non-EPL content will transition the current license to Eclipse Public License (EPL).

j.         Functionality provided by the non-EPL content.

k.       List strategic reason(s), tangible benefit(s) and necessity for including the non-EPL content in TPTP

l.         Explanation of how and where the non-EPL content will be packaged in TPTP.

m.     Explanation of how (e.g. leveraged functionality) the non-EPL content is utilized in TPTP.

n.       Possible alternatives to the non-EPL content and their disadvantages.

o.       List of non-EPL resources including formats (e.g. source code language), configuration (e.g. source or object code) and intended packaging in TPTP.

p.       List any modifications and/or contributions that have been or will be made by TPTP committers and if the modifications will be contributed back to the non-EPL organization.

 

3.       Contact the TPTP Project Management Committee (PMC) Lead (see Contacts) and request to incorporate the non-EPL content into TPTP.  The PMC must decide if the non-EPL content is required and justifies the associated pedigree and licensing issues.  As such, provide the information tabulated in the above step to the TPTP PMC Lead.

 

4.       The Eclipse Foundation must approve the inclusion of all non-EPL content in any Eclipse project.  Upon PMC approval, the TPTP PMC Lead will arrange to present the information sent in the above step to the Eclipse Management Organization (EMO) approval.  The EMO will subsequently arrange for voting and approval by the Board of Directors (BOD) of the Eclipse Foundation at their next meeting.  If necessary, the Eclipse Foundation will engage the appropriate individuals to perform a pedigree review.

 

5.       The TPTP PMC Lead will provide the date of the Eclipse Foundation BOD meeting that the request will be considered.  On or shortly after this date, the TPTP PMC Lead will contact the Committer(s) or project lead(s) requesting the non-EPL content with the outcome of the EMO and BOD decisions.

 

6.       If the request to incorporate non-EPL content into TPTP has been successfully approved by the Eclipse Foundation:

 

a.       Determine the TPTP plug-in(s) and their ID(s) that will contain the new non-EPL content.

b.       Prepare the appropriate legal documentation (e.g. about.html) containing the following information:

 

1.       Version or version series of the non-EPL content to be included in TPTP.

2.       Configuration (e.g. source or object code) of the non-EPL resources.

3.       List any modifications and/or contributions that have been or will be made by TPTP committers.

4.       List of the non-EPL resources and their intended packaging (e.g. relative paths in the TPTP plug-in(s) directory).

See the References section for an example of an about.html file from the Apache Jakarta Log4J (org.apache.jakarta_log4j_logging) plug-in in TPTP.

c.       Check-in the new non-EPL content into the TPTP CVS repository, including the appropriate legal documentation (e.g. about.html). 

d.       Modify the plug-in dependencies, build scripts and packaging scripts to include the new non-EPL content.

e.       Create testing resources (e.g. test suites and cases) to test the new non-EPL content and any TPTP resources utilizing the new non-EPL content.  See the References section for more information on the TPTP Testing Strategy.

 

 

Contacts:

 

For an inclusive list of TPTP contacts, please see the TPTP Project Management Committee site (see References).

 

 

References:

 

[1] About.html (org.apache.jakarta_log4j_logging), http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform/org.apache.jakarta_log4j_logging/about.html?rev=HEAD&content-type=text/html&cvsroot=TPTP_Project.

 

[2] Eclipse Project, http://www.eclipse.org.

 

[3] Eclipse Foundation Intellectual Property Policy, http://www.eclipse.org/org/documents/Eclipse%20IP%20Policy2003_12_03%20Final.pdf.

 

[4] Eclipse Project Legal Documents, http://www.eclipse.org/legal/main.html.

 

[5] Eclipse Public License, http://www.eclipse.org/org/documents/Eclipse%20EPL%202003_11_10%20Final.pdf.

 

[6] TPTP Project, http://www.eclipse.org/tptp.

 

[7] TPTP Project Management Committee, http://www.eclipse.org/tptp >> Project Management Committee.

 

[8] TPTP Testing Strategy, TPTP_Testing_Strategy.html.