The contribution of open-source projects of the SPINE community is open to all registered SPINE member. Contribution is understood here for all elements relative to the open-source projects hosted by SPINE, including but not limited to software components, documentation, input data, reference results, documentations.
However, in order to maintain the software quality and allow a clear tracking of the IPR, the contributions should respect the following rules:
- IPR: The Intellectual Property Rights should be clearly identified and the contributor should grant he/she has the full intellectual, and if relevant industrial rights, paten and trademark, property relative to the contribution. The contributor is also invited to clearly identify in which contractual context the developments have been done (e.g. internal research effort, personal work and individual contribution, contract number or public funding reference…). The contributor should grant the SPINE community and other authors/owners of the targeted project that by his/her contribution not to slander, impair or infringe the rights of third parties. The contributor is strongly invited to perform establish a proof of anteriority before submit his/here contribution.
- Credits: The contributor is kindly invited to list the complete credits, as individual developers / involved persons as well legal entities. SPINE attempts to be a community of expertise as well a support platform to tools, reference to the involved developers, experts, researchers and student is strongly encouraged.
- Licensing: The contributor should agree to provide his/here contribution under the GPL license.
- Source code availability: According to the open-source approach, the contributor should grant an access to the corresponding source code for the duration of the intellectual property or, in alternative, agree to store a copy of his/her contribution on the SPINE community forge. A dedicated branch can be open for free on the related GIT tool or exchange areas of the community on simple demand.
- Purpose of the contribution: The contributor is kindly invited to present, at least through a simple summary or ideally through a scientific communication, during a SPINE meeting for instance, the purpose and the objectives of his/her contribution.
- Dedicated development branch: During the development phase, it is strongly recommended to perform the development on a dedicated branch on the GIT repository. This branch can be opened on the GIT tool of the community on simple demand (see contact_at_spis.org).
- Loose coupling and packaging: In order to allow a strongly scalability and flexibility, most of the hosted software of the SPIEN community, like SPIS, are based on a modular design, including an OSGi based approach to allow loose coupling and dynamical loading of sub-modules. The contributors are strongly invited to follow the same approach and gather / package their contributions under the form of clearly identified OSGi bundles. Please contact the core development team.
- Software quality: For software components, a particular attention is given on the source code quality. It is strongly recommended to follow the SUN/Oracle recommendations for Java programming and respect the standard design pattern. Please see the Code Quality page or contact the core team for all question and further information.
- Validation and non-regression test cases: The contributor is strongly invited to validate as much as possible his/her contribution regarding the underlying physic and numerical models. Tests cases and examples are very welcome to let the community to evaluate these contributions. For SPIS software developments, it is demanded that the contributions comply with the SPIS non-regression tests-cases.
- Limited access during the development phase: If a limited access to the hosted data and software is needed during the development phase, for confidentially or contractual reasons,
- Submission to the SDAB for integration into the official releases: For final and official integration into the targeted hosted software, the contribution should be submitted to the SDAB for official acceptance. The SADB will review the above listed points and will accept (or not) the contribution into the next official software release. The SDAB meets about one or two times per year on the basis of a best effort. Please be indulgent, the acceptance / integration process might be a quite long process in spite of the whole good will and efforts.
For all question relative to the contributions rules, please contact the SDAB.