| <?php |
| /** |
| * Copyright (c) 2005, 2018 Eclipse Foundation and others. |
| * |
| * This program and the accompanying materials are made |
| * available under the terms of the Eclipse Public License 2.0 |
| * which is available at https://www.eclipse.org/legal/epl-2.0/ |
| * |
| * Contributors: |
| * Denis Roy (Eclipse Foundation) - Initial implementation |
| * Eric Poirier (Eclipse Foundation) |
| * |
| * SPDX-License-Identifier: EPL-2.0 |
| */ |
| ?> |
| <div id="midcolumn"> |
| <h1><?php print $pageTitle; ?></h1> |
| <h2>For informational purposes only</h2> |
| <p> |
| This FAQ provides answers to commonly asked questions related to the |
| transition of Eclipse projects from the <a |
| href="http://www.ibm.com/developerworks/library/os-cpl.html" |
| target="_blank" |
| >Common Public License version 1.0</a> to the <a |
| href="../../org/documents/epl-v10.php" |
| >Eclipse Public License (EPL)</a>. Details can be found in the <a |
| href="http://www.eclipse.org/legal/CPL2EPLTransitionPlan.pdf" |
| >CPL to EPL Transition Plan</a> (.pdf). |
| </p> |
| <p>This FAQ is provided for informational purposes only. It is not part |
| of, nor does it modify, amend, or supplement the terms of the CPL or |
| EPL. The CPL and EPL are legal agreements that govern the rights |
| granted to material licensed under it, so please read them carefully. |
| This FAQ should not be regarded as legal advice. If you need legal |
| advice, you must contact your own lawyer. This document was last updated on |
| August 26, 2004.</p> |
| <ol> |
| <li><strong>Why is the Eclipse Foundation changing licenses?</strong><br /> |
| The EPL was written specifically for the <a href="../../org/">Eclipse |
| Foundation</a>. First, it changes the Agreement Steward, formerly |
| IBM for the CPL, to now be the Eclipse Foundation for the EPL. |
| Second, it addresses concerns that some Eclipse Foundation members had |
| with a clause in the CPL that deals with possible patent litigation. |
| Many members and prospective members had concerns with this clause, and |
| viewed it as overly broad. For more information on this please refer |
| to the <a href="../eplfaq.php">EPL FAQ</a>.</li> |
| <li><strong>Can you summarize the plan briefly?</strong><br /> The plan is |
| to license the current release of each Eclipse project, together with any |
| maintenance updates, under both the CPL and EPL for approximately 6-8 |
| months. This transition period will be roughly aligned with major releases |
| of the Eclipse Platform. This will give the community adequate time |
| to adjust to the changes. </li> |
| <br /> |
| <li><strong>What if a project can’t meet the timelines in the plan?</strong><br /> |
| If any projects find the timeframes to be impractical or feel the plan |
| imposes an unreasonable burden for other reasons, they should request an |
| exception to the plan from the EMO. The EMO is prepared to work with |
| projects, and with the Eclipse community generally, to mitigate the impact |
| of the license transition process.</li> |
| <br /> |
| <li><strong>How will inbound contributions be handled?</strong><br /> Under |
| the plan, the <a href="../termsofuse.php">Web Site Terms of Use</a> will |
| be changed to specify that by default, inbound contributions will be |
| contributed under both EPL and CPL during the transition period. |
| This is necessary to support dual licensed maintenance streams of current |
| releases. </li> |
| <br /> |
| <li><strong>What if I want to contribute code under only the EPL or CPL to a |
| dual licensed stream?</strong><br /> Contributions under a single |
| license will be possible but not encouraged and will be handled as special |
| cases (similar to the process currently used by the PMCs and EMO to deal |
| with third party code contributed under a license other than the |
| CPL). Approval requires a strong technical argument for including |
| the code, explaining what the functionality is, why it is needed, and why |
| other options that fit the dual license framework are infeasible.</li> |
| <br /> |
| <li><strong>What about previous releases like Eclipse Platform 2.x?</strong><br /> |
| Past release streams that were licensed under CPL only and are still in |
| use (e.g. Eclipse 2.x), will continue to be supported as CPL only.</li> |
| <br /> |
| <li><strong>Will new development streams be dual licensed also?</strong><br /> |
| No, all new development streams going forward (e.g. Eclipse 3.1) will |
| operate under EPL only. </li> |
| <br /> |
| <li><strong>When will the re-licensing process be completed and the |
| transition period end?</strong><br /> This is a two-stage process, with |
| two important dates. The plan for the re-licensing process is for it |
| to be completed for all projects by December 31 2004. By that date, |
| and for every project, CPL only development will cease, the current |
| release will be offered under dual license, and new development will be |
| EPL only. At some <strong>switchover date</strong> (currently expected to |
| be in 1H05), all Eclipse development (including maintenance) will move to |
| EPL only. The exact date of the switchover will depend on individual |
| project schedules.</li> |
| <br /> |
| <li><strong>When will we see EPL versions of major Eclipse projects?</strong><br /> |
| For now, major projects will prepare dual licensed releases. The |
| Eclipse Foundation will be contacting all contributors to obtain their |
| agreement to publish under both EPL and CPL.</li> |
| <br /> |
| <li><strong>What is the Re-Licensing Committee?</strong><br /> The Eclipse |
| Foundation Board of Directors has created a committee called the |
| Re-Licensing Committee to monitor the progress of the transition. </li> |
| <br /> |
| <li><strong>I am a committer and I received an email asking me to identify |
| contributors whose code I committed. Why am I getting this?</strong><br /> |
| Contributors to an Eclipse project provided their contribution under the |
| CPL. We are seeking their agreement to dual license their |
| contribution under both the CPL and EPL. To facilitate this process |
| Eclipse is asking all committers to identify the contributors they |
| personally know about. We would like to get their contact |
| information (employer, address, etc.), and also would like to know what |
| they worked on and roughly how much code they contributed. All of |
| this will help us to first, decide exactly who needs to be contacted and |
| second, collect the required agreements.</li> |
| <br /> |
| <li><strong>What is the Eclipse Foundation going to do with the personal |
| data it is collecting?</strong><br /> We intend to build a contributor |
| database so that in future we can do a better job of managing and |
| recognizing contributions.</li> |
| <br /> |
| <li><strong>What is an "individual committer"?</strong><br /> Most |
| committers working on Eclipse projects currently are employed by an |
| Eclipse Member Organization, and are working on Eclipse in the course of |
| their regular employment. Individual committers are those who fall |
| outside this category. If the individual committer personally owns |
| his/her contributions, then he/she may simply agree to re-contribute under |
| the EPL. If some other entity owns the contribution, such as their |
| employer, then he/she must obtain the permission of that entity to |
| re-license the contribution.</li> |
| <br /> |
| <li><strong>Once all the required agreements are obtained, what options does |
| a project have to actually implement the re-licensing for |
| projects/builds that will be licensed under the EPL?</strong><br /> The |
| Eclipse Foundation is currently suggesting projects use one of two |
| options. </span><span style='font-family: Arial'>Option #1 is to |
| modify <strong>all files including source files</strong> to change all |
| legal notices, abouts, feature licenses, feature update licenses, and |
| the Software User Agreement, to refer to "EPL"; rather than |
| "CPL" but only for those projects/builds that will be licensed |
| under the EPL. For those projects/builds that will be licensed |
| under the CPL, no changes are required. Option #2 is similar to |
| Option #1 except <strong>source files will NOT BE UPDATED</strong>. |
| This means that the CVS repository and source builds for the stream will |
| contain source files with effectively "incorrect" license |
| notices that will be "overridden" by the Abouts, Software User |
| Agreement and other legal documentation. The use of this mechanism |
| and the status of each project will be well publicized and documented on |
| the website </li> |
| <br /> |
| <li><strong>What if I’m still confused about what my options are with |
| respect to the re-licensing process?</strong><br /> Contact your PMC |
| Lead or the EMO, they will help you sort things out.</li> |
| <br /> |
| <li><strong>What if a project can’t get this all done by the December |
| 31 deadline?</strong><br /> The Re-Licensing Committee has the authority |
| to approve exceptions to the plan, on the recommendation of the EMO, that |
| would allow a project more time. The criteria for considering an |
| exception are: the size of the project; cost to completely change all |
| source files; project schedules; available resources; and impact on the |
| Eclipse community.</li> |
| <br /> |
| </ol> |
| </div> |
