dev_process/three-laws-of-eclipse.php

<?php  																														require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/app.class.php");	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/nav.class.php"); 	require_once($_SERVER['DOCUMENT_ROOT'] . "/eclipse.org-common/system/menu.class.php"); 	$App 	= new App();	$Nav	= new Nav();	$Menu 	= new Menu();		include($App->getProjectCommon());    # All on the same line to unclutter the user's desktop'
/* 221934 - this page to remain on eclipse.org */

$pageTitle 		= "The Three Laws of Eclipse";

include( '../_commonLeftNav.php' );

ob_start();
?>
    <div id="maincontent">
	<div id="midcolumn">

<div style="
float: right;
width: 230px;
text-align: center;
font-size: 70%;
">
<img src="images/roboto-flower-220.png" width="220" height="220"><br> 
<em>(Thanks to <a href="http://scamper.com/portfolio/ill6.html">Scamper Design</a> 
for the use of the robot flower image. All rights reserved.)</em>
</div>	
<h1>The Three Laws of Eclipse</h1>
<p><em>(With a tip of the hat to <a href="http://en.wikipedia.org/wiki/Three_Laws_of_Robotics">Isaac Asimov</a>.)</em></p>

<ol>
<li>A committer may not, through action or inaction, violate IP cleanliness
<li>A committer may not, through action or inaction, disenfranchise contributors
<li>A committer may not, through action or inaction, surprise the membership
</ol>

<h2>(1) A committer may not, through action or inaction, violate IP cleanliness</h2>
<p>In addition to great open source code, one of the best features of the Eclipse Projects is
their IP cleanliness. This cleanliness comes from:
<ul>
<li><em><b>Clean Code.</b></em> Making sure that all incoming code is legally contributed. 
(See the <a href="/projects/dev_process/ip-process-in-cartoons.php">IP policy in cartoon form</a>.)
	<ul>
	<li>Code written by committers is safe. 
	<li>Code written by contributors submitted via bugzilla patches is safe because of
	 the website <a href="/legal/termsofuse.php">terms of use</a>. 
	<li>If a committer suspects
	that incoming code might not be safe, it is his or her duty to ask the contributor to prove that the
	contributor has the rights to contribute that code.
	<li>Code found in dark alleys is not safe.
	</ul>
	<p>
<li><em><b>Approved Libraries.</b></em> Making sure that all third-party code included,
or merely referenced, 
is cleared by Eclipse Legal through a contribution questionnaire. The legal department checks many things, two of
the major ones being: (a) is the license compatible with the EPL? (b) does the third-party project have 
a traceable trail of their contributors?<p>
<li><em><b>Paper'ed People.</b></em> Making sure that all committers 
have <a href="/projects/dev_process/new-committer.php#Paperwork">committer agreements</a>
covering each of the committer's projects. The agreements say "I have the rights to write code
for Eclipse and my employer agrees that I have those rights".
</ul>

<h2>(2) A committer may not, through action or inaction, disenfranchise contributors</h2>
<p>Eclipse is a community in the best open source principles: open, transparent, and driven by a meritocracy.
We maintain this community by ensuring that everyone has equal opportunity to participate:
<ul>
<li><em><b>Public Queue.</b></em> All bugs and tasks are tracked at the public eclipse.org bugzilla.
Anyone and everyone can see and participate in that queue.<p>
<li><em><b>Available Tools.</b></em> All the source code and all the tools used to build a project are 
available for everyone to use.<p>
<li><em><b>Transparent Elections.</b></em> Elections for new committers are open and public, with full
records and justifications. Nominations include url references to the candidate's contributions
(or, for new committers to new projects, bios and backgrounds).
Committers are not elected "just because they work for the company".
</ul>

<h2>(3) A committer may not, through action or inaction, surprise the membership</h2>
<p>The Eclipse membership is a key part of the larger Eclipse eco-system. 
With members and project in a symbiotic relationship, it
is important for both sides to avoid surprising the other. Committers minimize surprises through:
<ul>
<li><em><b>Open Plans.</b></em> Planning and status reports and meetings are open to all. Most projects use the wiki.<p>
<li><em><b>Public Reviews.</b></em> At major events in a project lifecycle, 
<a href="/projects/dev_process/development_process.php#6_3_Reviews">reviews</a> are held to inform
the membership. Major events include any N.N release (e.g., 0.5, ..., 1.0, 1.2, ..., 2.1, 2.2, ...) 
(but not N.N.x bug fix releases).<p>
<li><em><b>Prominent Announcements.</b></em> When starting a major new feature or effort that
does not require a formal review, committers send 
an <a href="/projects/dev_process/notifying-membership.php">announcement</a>
alerting the members to potential future new cool stuff.
</ul>


<?php include( '../_commonFooter.php' ); ?>

</div>
</div>

<?php
	# Paste your HTML content between the EOHTML markers!	
	$html = ob_get_contents();
	ob_end_clean();

	# Generate the web page
	$App->generatePage($theme, $Menu, $Nav, $pageAuthor, $pageKeywords, $pageTitle, $html);
?>