2017-10-26
| VERSION | DATE | REASON |
|---|---|---|
| 1 | 2010/09/21 | Creation |
| 2 | 2012/09/27 | PMC vote further to July 2012 meeting |
| 3 | 2012/10/26 | Updated links |
| 4 | 2017/10/26 | Change rules for urgent patch releases |
OREKIT is a free low level space dynamics library written in Java. It provides basic elements (orbits, dates, attitude, frames…) and various algorithms to handle them (conversions, analytical and numerical propagation, pointing…).
OREKIT is developed under APACHE V2.0 license. All contributions to OREKIT have to be compliant with the terms and conditions of this license. This license belongs to the “Business Friendly” category. It allows use, modification and redistribution. It does not impose further obligation to derived products.
The following document describes the governance model under which OREKIT is run. It has been established on the meritocratic governance model proposed by OSS Watch, under Creative Commons License: Attribution Share Alike.
Read more: http://oss-watch.ac.uk/resources/meritocraticgovernancemodel
OREKIT is a consensus-based community project. Anyone with an interest in OREKIT can join its community, contribute to its design and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within OREKIT community.
Users are community members who have a need for OREKIT. They are the most important members of the community and without them OREKIT would have no purpose. Anyone can be a user; there are no special requirements.
OREKIT asks its users to participate in the project and community as much as possible. The objective of the users’ contributions is to enable OREKIT to be in phase with the needs of the users. Common user contributions include (but are not limited to):
Users who continue to engage with OREKIT and its community will often become more and more involved. Such users may find themselves becoming contributors, as described in the next section.
Contributors are community members who contribute in concrete ways to OREKIT. Anyone can become a contributor and contributions can take many forms, such as those outlined below and in the above section on users. There is no expectation of commitment to the project, no specific skill requirements and no selection process. In addition to their actions as users, contributors will also find themselves doing one or more of the following:
Contributors must clearly notify they agree with the fact that their patches will be integrated in OREKIT under APACHE V2.0 license. For this, they have to tick the appropriate box when they attach their patch to a bug report in the anomaly management tool in order to confirm that their contribution will be governed by the APACHE V2.0 license terms and conditions, otherwise their contribution will not be part of OREKIT.
Contributors engage with OREKIT through the issue tracker and mailing list, or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section). The developer mailing list is the most appropriate place to ask for help when making that first contribution.
As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership, as described in the next section.
An active contributor is a contributor who has:
Committers are community members who have shown that they are committed to the continued development of OREKIT through ongoing engagement with OREKIT and its community. Committership allows contributors to more easily carry on with OREKIT related activities by giving them direct access to OREKIT resources. That is, they can make changes directly to OREKIT outputs, without having to submit changes via patches.
This does not mean that a committer is free to do what he wants. In fact, committers have no more authority over OREKIT than contributors. While committership indicates a valued member of the community who has demonstrated a healthy respect for OREKIT aims and objectives, their work continues to be reviewed by the community before acceptance in an official release. The key difference between a committer and a contributor is when this approval is sought from the community. A committer seeks approval after the contribution is made, rather than before.
Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. OREKIT employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole, but there is no need to detail them here. By the time a contributor is invited to become a committer, they will have become familiar with the project’s various tools as a user and then as a contributor.
Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that he has an understanding of OREKIT, its objectives and its strategy. He will also has provided valuable contributions to OREKIT over a period of time.
To obtain rights for base access, committers will have to sign a commitment (Individual Contributor License Agreement -ICLA- or Corporate Contributor License Agreement -CCLA-) indicating that every contribution to OREKIT they will register in the base is covered by APACHE V2.0 license.
New committers can be nominated by any existing committer. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Committer voting is one of the few activities that takes place on the project’s private management list. This is to allow PMC members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation of any ‘no’ votes against them, regardless of the outcome of the vote. This explanation will be provided by the PMC Chair (see below) and will be anonymous and constructive in nature.
Nominees may decline their appointment as a committer. However, this is unusual, as the project does not expect any specific time or resource commitment from its community members. The intention behind the role of committer is to allow people to contribute to the project more easily, not to tie them in to the project in any formal way.
It is important to recognize that committership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC (see next section) in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.
A committer who shows an above-average level of contribution to OREKIT, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the PMC. This role is described below.
The PMC has additional responsibilities over and above those of a committer. These responsibilities ensure the smooth running of the project. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.
Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project’s private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.
Any member of the PMC is free to leave after having informed the PMC of his decision.
The PMC Chair is a single individual, voted for by the existing PMC members. Once someone has been appointed Chair, the PMC Chair remains in that role until he or she chooses to retire, or the PMC casts a two-thirds majority vote to remove the PMC Chair.
The PMC Chair has no additional authority over other members of the PMC: the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC member. All non-sensitive project management discussion takes place on the project contributors’ mailing list. Occasionally, sensitive discussion occurs on a private list.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
Decision making typically involves the following steps:
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the project contributors’ list or submit a patch implementing the idea to the issue tracker (or version-control system if they have commit access). This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in OREKIT community have a shared vision, there is often little need for discussion in order to reach consensus.
In general, as long as nobody explicitly opposes a proposal or patch, it is recognized as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.
Lazy consensus is a very important concept within OREKIT. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.
For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.
Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. This section describes how a vote is conducted. Section 2.4.4 discusses when a vote is needed.
If a formal vote on a proposal is called (signaled simply by sending a email with ‘[VOTE]’ in the subject line), all participants on the project contributors’ list may express an opinion and vote. They do this by sending an email in reply to the original ‘[VOTE]’ email, with the following vote and information:
To abstain from the vote, participants simply do not respond to the email. However, it can be more helpful to cast a ‘+0’ or ‘-0’ than to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.
Every member of the community, from interested user to the most active developer, has a vote. The project encourages all members to express their opinions in all discussion and all votes. However, only committers to the project (as defined above) and/or PMC members have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of all community members are considered. While only committers and PMC members have a binding vote, a well-justified ‘-1’ from a non-committer must be considered by the community, and if appropriate, supported by a binding ‘-1’.
When a [VOTE] receives a ‘-1’, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is rescinded or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the PMC will decide the forward course of action.
In summary:
Different actions require different types of approval, ranging from lazy consensus to a majority decision by the PMC. These are summarized in the table below. The section after the table describes which type of approval should be used in common situations.
| Type | Description | Duration |
|---|---|---|
| Lazy consensus | An action with lazy consensus is implicitly allowed, unless a binding -1 vote is received. Depending on the type of action, a vote will then be called. Note that even though a binding -1 is required to prevent the action, all community members are encouraged to cast a -1 vote with supporting argument. Committers are expected to evaluate the argument and, if necessary, support it with a binding -1. | N/A |
| Lazy majority | A lazy majority vote requires more binding +1 votes than binding -1 votes. | 120 hours |
| Consensus approval | Consensus approval requires more binding +1 votes than binding -1 votes and at least three binding +1 votes. | 120 hours |
| 2/3 majority | Some strategic actions require a 2/3 majority of PMC members; in addition, 2/3 of the binding votes cast must be +1. Such actions typically affect the foundation of the project (e.g. adopting a new code base to replace an existing product). | 168 hours |
Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. However, some activities require a more formal approval process in order to ensure fully transparent decision making.
The table below describes some of the actions that will require a vote. It also identifies which type of vote should be called.
| Action | Description | Approval type |
|---|---|---|
| Release plan | Defines the timetable and actions for a release. | Lazy majority |
| Product release | When a release of one of the project’s products is ready, a vote is required to accept the release as an official release of the project, except for patch releases (see below). | Lazy majority |
| New committer | A new committer has been proposed. | Consensus approval of PMC |
| New PMC member | A new PMC member has been proposed. | 2/3 majority of the PMC |
| Committer removal | When removal of commit privileges is sought. | 2/3 majority of the PMC |
| PMC member removal | When removal of PMC membership is sought. | 2/3 majority of the community limited to active contributors, committers and PMC members |
| PMC rules changes | When the rules defined in this document are changed. | 2/3 majority of the PMC |
Version numbers for releases follow the traditional major.minor[.patch] numbering model. Major number are changed when changes that induce upward incompatibilities for users appears. This typically corresponds to changes in existing public Application Programming Interface that users may already use in their code. Minor number changes without change to major number when users can use the new version directly without changing their code. This typically corresponds to adding new features not present before (or adding new methods in existing features) and fixing bugs. Patch number are generally not used, but may be added for bug-fixing only releases, without feature changes.
Votes is generally required for releases that involve functional changes, like new features added. However, in order to speed up release of urgent corrections, votes are not required for releasing patch versions that only involve bug fixes. Such releases can be decided directly by the development team, which must discuss it on the developers mailing list and vote for this urgent release directly on the mailing list, with vote delays adapted to the urgency. The PMC must be notified of the situation and be given at least a 24 hours delay during which the PMC can deny the urgency and ask for a formal release vote.
Anyone can contribute to OREKIT, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, or might supply patches.
The developer mailing list is the most appropriate place for a contributor to ask for help when making their first contribution.
All contributors of ideas, code or documentation to OREKIT complete, sign, and submit (via postal mail or email) an Individual Contributor License Agreement (ICLA) (see Annex). The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to OREKIT and thereby allow PMC to defend the project should there be a legal dispute regarding the software at some future time. A signed ICLA is required to be on file before an individual is given commit rights to OREKIT project.
For a corporation that has assigned employees to work on OREKIT, a Corporate CLA (CCLA) (see annex) is available for contributing intellectual property via the corporation, that may have been assigned as part of an employment agreement. Note that a Corporate CLA does not remove the need for every developer to sign their own ICLA as an individual, to cover any of their contributions which are not owned by the corporation signing the CCLA.
CLAs may be submitted by traditional postal mail or by emailing a scan of the signed copy to PMC. It is also possible to fill out the PDF document or edit the text document, create a detached GPG signature, and send both the document and the detached signature via email to PMC.
When an individual or corporation decides to donate a body of existing software or documentation to OREKIT, they need to execute a formal Software Grant Agreement (SGA) (see annex) with OREKIT PMC.
The following agreements have been established using models proposed by the Apache Foundation, under Copyright © 2010 The Apache Software Foundation, Licensed under the Apache License, Version 2.0.
OREKIT Project
Individual Contributor License Agreement (“Agreement”) V2.0
PDF version: https://www.orekit.org/doc/icla.pdf
Thank you for your interest in OREKIT project. In order to clarify the intellectual property license granted with Contributions from any person or entity, OREKIT project must have a Contributor License Agreement (“CLA”) on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection OREKIT project and its users; it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to cla@orekit.org.
Please read this document carefully before signing and keep a copy for your records.
Full name: ………………………………………………………….
Mailing Address: …………………………………………………….
……………………………………………………………………
Country: ……………………………………………………………
Telephone: ………………………………………………………….
Facsimile: ………………………………………………………….
E-Mail: …………………………………………………………….
You accept and agree to the following terms and conditions for Your present and future Contributions submitted to OREKIT project. In return, OREKIT Project shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its nonprofit status and bylaws in effect at the time of the Contribution. Except for the license granted herein to OREKIT and recipients of software distributed by OREKIT, You reserve all right, title, and interest in and to Your Contributions.
“You” (or “Your”) shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with OREKIT. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
“Contribution” shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to OREKIT Project for inclusion in, or documentation of, any of the products owned or managed by OREKIT (the “Work”). For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to OREKIT or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, OREKIT Project for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”
Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to OREKIT project and to recipients of software distributed by OREKIT a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to OREKIT Project and to recipients of software distributed by OREKIT a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to OREKIT Project, or that your employer has executed a separate Corporate CLA with OREKIT project.
You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NONINFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
Should You wish to submit work that is not Your original creation, You may submit it to OREKIT Project separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as “Submitted on behalf of a third-party: [named here]”.
You agree to notify OREKIT Project of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
Please sign: ……………………………. Date: ……………………
OREKIT Project
Software Grant and Corporate Contributor License Agreement (“Agreement”)
PDF version: https://www.orekit.org/doc/ccla.pdf
Thank you for your interest in The OREKIT Project. In order to clarify the intellectual property license granted with Contributions from any person or entity, OREKIT Project must have a Contributor License Agreement (CLA) on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of OREKIT Project and its users; it does not change your rights to use your own Contributions for any other purpose.
This version of the Agreement allows an entity (the “Corporation”) to submit Contributions to OREKIT Project, to authorize Contributions submitted by its designated employees to OREKIT Project, and to grant copyright and patent licenses thereto.
If you have not already done so, please complete and sign, then scan and email a PDF file of this Agreement to OREKIT Project.
Please read this document carefully before signing and keep a copy for your records.
Corporation name: ……………………………………………………
Corporation address: …………………………………………………
……………………………………………………………………
……………………………………………………………………
Point of Contact: ……………………………………………………
E-Mail: …………………………………………………………….
Telephone: ………………………… Fax: ………………………….
You accept and agree to the following terms and conditions for Your present and future Contributions submitted to OREKIT Project. In return, OREKIT Project shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its non profit status and bylaws in effect at the time of the Contribution. Except for the license granted herein to OREKIT Project and recipients of software distributed OREKIT Project, You reserve all right, title, and interest in and to Your Contributions.
“You” (or “Your”) shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with OREKIT Project. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
“Contribution” shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to OREKIT Project for inclusion in, or documentation of, any of the products owned or managed by OREKIT Project (the “Work”). For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to OREKIT Project or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, OREKIT Project for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”
Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to OREKIT Project and to recipients of software distributed by OREKIT Project a perpetual, worldwide, nonexclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to OREKIT Project and to recipients of software distributed by OREKIT Project a perpetual, worldwide, nonexclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) were submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.
You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).
You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NONINFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
Should You wish to submit work that is not Your original creation, You may submit it to OREKIT Project separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as “Submitted on behalf of a third-party: [named here]”.
It is your responsibility to notify OREKIT Project when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation’s Point of Contact with OREKIT Project.
Please sign: ……………………………… Date: ………………….
Title: ……………………………………………………………..
Corporation: ………………………………………………………..
Schedule A
[Initial list of designated employees. NB: authorization is not tied to particular Contributions.]
Schedule B
[Identification of optional concurrent software grant. Would be left blank or omitted if there is no concurrent software grant.]
OREKIT Project
License Agreement
PDF version: https://www.orekit.org/doc/software_grant.pdf
This License Agreement is entered into as of the ….. day of ……………, …….. by …………………………… (“Licensor”), in favor of OREKIT Project.
WHEREAS, Licensor owns or has sufficient rights to contribute the software source code and other related intellectual property as itemized on Exhibit A (“Software”) under the terms of this agreement to OREKIT Project.
NOW, THEREFORE, FOR GOOD AND VALUABLE CONSIDERATION, the receipt and legal sufficiency of which are hereby acknowledged, the parties hereto, intending to be legally bound, agree as follows:
a non-exclusive, worldwide, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense, internally and externally, the Software and such derivative works, in source code and object code form; and,
a non-exclusive, worldwide, royalty-free, irrevocable patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Software in source code and object code form. “Licensed Patents” mean patent claims owned by Licensor which are necessarily infringed by the use or sale of the Software alone.
Licensor represents that, to Licensor’s knowledge, Licensor is legally entitled to grant the above license. Licensor agrees to notify OREKIT Project of any facts or circumstances of which Licensor becomes aware and which makes or would make Licensor’s representations in this License Agreement inaccurate in any respect.
This Software is provided AS-IS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. NEITHER THE LICENSOR NOR ITS SUPPLIERS WILL BE LIABLE TO OREKIT PROJECT OR ITS LICENSEES FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE WORK OR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
This License Agreement is the entire agreement of the parties with respect to its subject matter, and may only be amended by a writing signed by each party. This License Agreement may be executed in one or more counterparts, each of which shall be considered an original.
IN WITNESS WHEREOF, Licensor has executed this License Agreement as of the date first written above.
LICENSOR:
Signed By: ………………………………………………………….
Print Name: …………………………………………………………
Title: ……………………………………………………………..
Representing: ……………………………………………………….
……………………………………………………………………
Contact Name: ……………………………………………………….
Contact Email: ………………………………………………………
Exhibit A
List of software and other intellectual property covered by this agreement: