documents/Eclipse_Using_Proprietary_Tools_Final.html - www.eclipse.org/org - Git at Google

 <html>

 <head>
 <meta http-equiv="Content-Language" content="en-us">
 <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
 <title>Eclipse Foundation Board of Directors Resolution</title>
 <link rel="stylesheet" href="http://www.eclipse.org/default_style.css">
 </head>

 <body>
 <p>The following resolution was passed by the Board of Directors of the Eclipse Foundation on June 21, 2007.</p>
 <p><b>RESOLVED</b>, that the Board hereby instructs each Eclipse project to conform to the following policy for using proprietary tools in their development process, where there is sufficient value to the project to motivate the use of such proprietary tools. The goal of this policy is to ensure that undue barriers to contributors are not introduced as the result of the use of proprietary tools by one or more projects.</p>
 <ul>
 <li>Projects are authorized to use proprietary tools for non-core infrastructure made available free of charge by vendor to all projects within the Eclipse community.</li>
 <li>Vendors must agree to provide free licenses for all Eclipse committers, plus those individuals identified by name by a project leader, for use on the project.</li>
 <li>The vendor has no obligation to provide free support, but may choose to do so at their discretion. (There may be good business reasons to want to get feedback from the Eclipse team, and to ensure that they are happy users.)</li>
 <li>Vendors are not obligated to provide any software. This is at their discretion.</li>
 <li>Licenses provided by the vendors would be for a specific version of the vendor's software and must be perpetual. Access to any upgrades would be at the discretion of the vendor.</li>
 <li>Although it will be a matter of public record that projects at the Eclipse Foundation are using proprietary tools, the Eclipse Foundation will not endorse any vendor's products. The Eclipse Foundation will publicly acknowledge the use of freely provided proprietary software tools on its <a href="http://www.eclipse.org/org/foundation/thankyou.php">"Thank You"</a> page.</li>
 </ul>

 <p>The Board further instructs the EMO to develop a procedure to implement this policy.</p>

 <b>Definitions:</b><br>
 <p>"Non-core infrastructure" means those software development tools and aids which are not part of the generally available Eclipse Foundation project infrastructure, examples of "core infrastructure" would include without limitation: project build infrastructure, CVS, Bugzilla and Mailman.</p>

 <p>"Proprietary tools" means those software development tools made commercially available under a software license not approved by the Open Source Initiative as an open source license.</p>

 <b>Implementation Procedure</b>

 <ol type="1">
 <li>The process of approving a proprietary tool begins upon with a request from a project to the EMO to approve a specific tool for use by Eclipse projects. The request should be sent as an
 email to <a href="mailto:emo@eclipse.org?Subject=Proprietary Tool Approval Request">emo@eclipse.org</a>
  and must include:</li><br>
 	<ul>
 	<li>The name and version of the proprietary tool of interest to the project.</li>
 	<li>A brief description of what the tool does and why it is of interest to the project.</li>
 	<li>The name of a contact person at the vendor that the EMO can work with on the approval.</li>
 	<li>If possible, a link to or a copy of the proprietary license under which the tool is made available.</li>
 	</ul>
 <p>For greater clarity, requests by vendors to pre-approve proprietary tools in the absence of a request by an
 Eclipse project will not be acted upon.</p>

 <li>Within one week after the request has been received by the EMO, the EMO will contact the vendor to ascertain
 their willingness to abide by the requirements of the Eclipse Foundation. E.g.:</li><br>
 	<ul>
 	<li>They must agree to provide free licenses for all Eclipse committers, plus those individuals identified by name by a project leader, for use on the project.</li>
 	<li>Licenses provided by the vendor would be for a specific version of the vendor's software and must be perpetual.</li>
 	<li>Access to any upgrades would be at the discretion of the vendor.</li>
 	<li>Free support services may be optionally offered by the vendor to Eclipse committers.</li>
     </ul>
 <br>

 <li>Once an agreement in principle is reached with the vendor, a legal review will take place to ensure that the licensing terms offered by the vendor are consistent with said agreement. If executed agreements are required, they will be executed by the Executive Director or his designate.</li>
 <br>
 <li>Together, the vendor and EMO will create a document for publication on <a href="http://wiki.eclipse.org">wiki.eclipse.org</a> describing how Eclipse committers and contributors can gain access to the proprietary tool. Note that it is acceptable to the Eclipse Foundation that those using these tools may have to register with the vendor in order to gain access.</li>
 <br>
 <li>Once the agreements have been reviewed, approved and (if applicable) executed, the Eclipse development community will be informed that the proprietary tool is available to them via the <a href="mailto:eclipse.org-committers@eclipse.org">eclipse.org-committers@eclipse.org</a> mailing list and a posting on the
 <a href="news://news.eclipse.org/eclipse.foundation">Eclipse Foundation newsgroup</a>. The document prepared in the
 previous step will be made publicly available to the community via <a href="http://wiki.eclipse.org">wiki.eclipse.org</a>.</li>
 <br>
 <li>The EMO will contact the vendor at least annually to ensure that they wish to continue the relationship and royalty-free licensing terms with the Eclipse project community.</li>
 </ol>

 </body>

 </html>
	<html>

	<head>
	<meta http-equiv="Content-Language" content="en-us">
	<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
	<title>Eclipse Foundation Board of Directors Resolution</title>
	<link rel="stylesheet" href="http://www.eclipse.org/default_style.css">
	</head>

	<body>
	<p>The following resolution was passed by the Board of Directors of the Eclipse Foundation on June 21, 2007.</p>
	<p><b>RESOLVED</b>, that the Board hereby instructs each Eclipse project to conform to the following policy for using proprietary tools in their development process, where there is sufficient value to the project to motivate the use of such proprietary tools. The goal of this policy is to ensure that undue barriers to contributors are not introduced as the result of the use of proprietary tools by one or more projects.</p>
	<ul>
	<li>Projects are authorized to use proprietary tools for non-core infrastructure made available free of charge by vendor to all projects within the Eclipse community.</li>
	<li>Vendors must agree to provide free licenses for all Eclipse committers, plus those individuals identified by name by a project leader, for use on the project.</li>
	<li>The vendor has no obligation to provide free support, but may choose to do so at their discretion. (There may be good business reasons to want to get feedback from the Eclipse team, and to ensure that they are happy users.)</li>
	<li>Vendors are not obligated to provide any software. This is at their discretion.</li>
	<li>Licenses provided by the vendors would be for a specific version of the vendor's software and must be perpetual. Access to any upgrades would be at the discretion of the vendor.</li>
	<li>Although it will be a matter of public record that projects at the Eclipse Foundation are using proprietary tools, the Eclipse Foundation will not endorse any vendor's products. The Eclipse Foundation will publicly acknowledge the use of freely provided proprietary software tools on its <a href="http://www.eclipse.org/org/foundation/thankyou.php">"Thank You"</a> page.</li>
	</ul>

	<p>The Board further instructs the EMO to develop a procedure to implement this policy.</p>

	<b>Definitions:</b><br>
	<p>"Non-core infrastructure" means those software development tools and aids which are not part of the generally available Eclipse Foundation project infrastructure, examples of "core infrastructure" would include without limitation: project build infrastructure, CVS, Bugzilla and Mailman.</p>

	<p>"Proprietary tools" means those software development tools made commercially available under a software license not approved by the Open Source Initiative as an open source license.</p>

	<b>Implementation Procedure</b>

	<ol type="1">
	<li>The process of approving a proprietary tool begins upon with a request from a project to the EMO to approve a specific tool for use by Eclipse projects. The request should be sent as an
	email to <a href="mailto:emo@eclipse.org?Subject=Proprietary Tool Approval Request">emo@eclipse.org</a>
	and must include:</li><br>
	<ul>
	<li>The name and version of the proprietary tool of interest to the project.</li>
	<li>A brief description of what the tool does and why it is of interest to the project.</li>
	<li>The name of a contact person at the vendor that the EMO can work with on the approval.</li>
	<li>If possible, a link to or a copy of the proprietary license under which the tool is made available.</li>
	</ul>
	<p>For greater clarity, requests by vendors to pre-approve proprietary tools in the absence of a request by an
	Eclipse project will not be acted upon.</p>

	<li>Within one week after the request has been received by the EMO, the EMO will contact the vendor to ascertain
	their willingness to abide by the requirements of the Eclipse Foundation. E.g.:</li><br>
	<ul>
	<li>They must agree to provide free licenses for all Eclipse committers, plus those individuals identified by name by a project leader, for use on the project.</li>
	<li>Licenses provided by the vendor would be for a specific version of the vendor's software and must be perpetual.</li>
	<li>Access to any upgrades would be at the discretion of the vendor.</li>
	<li>Free support services may be optionally offered by the vendor to Eclipse committers.</li>
	</ul>
	<br>

	<li>Once an agreement in principle is reached with the vendor, a legal review will take place to ensure that the licensing terms offered by the vendor are consistent with said agreement. If executed agreements are required, they will be executed by the Executive Director or his designate.</li>
	<br>
	<li>Together, the vendor and EMO will create a document for publication on <a href="http://wiki.eclipse.org">wiki.eclipse.org</a> describing how Eclipse committers and contributors can gain access to the proprietary tool. Note that it is acceptable to the Eclipse Foundation that those using these tools may have to register with the vendor in order to gain access.</li>
	<br>
	<li>Once the agreements have been reviewed, approved and (if applicable) executed, the Eclipse development community will be informed that the proprietary tool is available to them via the <a href="mailto:eclipse.org-committers@eclipse.org">eclipse.org-committers@eclipse.org</a> mailing list and a posting on the
	<a href="news://news.eclipse.org/eclipse.foundation">Eclipse Foundation newsgroup</a>. The document prepared in the
	previous step will be made publicly available to the community via <a href="http://wiki.eclipse.org">wiki.eclipse.org</a>.</li>
	<br>
	<li>The EMO will contact the vendor at least annually to ensure that they wish to continue the relationship and royalty-free licensing terms with the Eclipse project community.</li>
	</ol>

	</body>

	</html>