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, patent 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.
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.
Loose coupling and packaging
In order to allow a strongly scalability and flexibility, most of the hosted software of the SPINE 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.
Reference version, definition and access rules
In the frame of the SPINE community the last reference version of the source code is available on the main GIT repositories (available here for SPIS, for example) and corresponds to the version accredited by the SDAB as the official reference community trunk.
If you wish contribute to a software hosted by the SPINE, we recommend you to consider this version as the initial reference source code for your development and future potential merges. In the frame of the SPINE community, all other versions, including potentially newer ones or corresponding to pending developments performed in frame of dedicated projects or activities, should be considered as git forks and/or aspiring contributions only, until they be agreed and merged by the SDAB.
The access to the GIT repository for community reference source code is granted to all registered SPINE members in reading mode. If you wish to contribute, we strongly recommend you to firstly create a dedicated git fork on the SPINE forge, as presented here after.
If you wish be part of the official direct contributors and/or merging officers, with an edition right on the main GIT repositories, please submit a prior demand to the SDAB.
Dedicated development GIT fork
During the development phase, it is mandatory to perform the development on a dedicated GIT fork on the software forge. This branch can be created by going to the reference GIT repository and click on the “fork” icon.
Controlled access to fork during development phase
If a limited access to hosted data and/or branches of software is needed during the development phase of a project or activity, for confidentially or contractual reasons for instance, subject to the available resources (e.g. disk space, band-width…), you may create a GIT fork on the SPINE sever and limit the visibility of your GIT fork to a group of users/developers, if you wish.
To participate to the community life and interact with others community members, we strongly recommend you to inform the SDAB of the creation of you fork and the related context/activity before hand.
It is demanded that this private hosting be used in “prudent-man”.
As initiator of this fork, you will be considered are Fork Manager and you agree to endorse all technical and legal responsibilities related to this GIT fork. The users you will accept to read and contribute to this fork will respectively be considered as Fork Readers and Fork Contributors.
For clarification, we outline that, in this case, Fork Manager will remain fully responsible of all activity and/or hosted data, software and documents on this dedicated GIT fork, especially regarding the legal responsibilities and/or in case of potential infringements of rights or laws, and for all technical question. The Fork Manager will also be in charge to check and make that all Fork Readers and Fork Contributors of his/her fork(s) respect the same rules.
The SDAB and all other SPINE community members will deny all responsibilities in this case and/or in case of losses of hosted data/software/document and/or in case of intrusion and/or violation of confidentiality and/or violation of the GDPR rules. As Fork Manager, you remain fully responsible of the hosted data and/or software and/or documents and the behaviour of the users authorised to modify its GIT fork.
For technical or legal reasons, the SDAB remains free to suspend the access to or suppress the hosted data and/or branches of software.
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 SDAB will review the above listed points and will either accept the contribution as it or with minor changes into the next official software release, request major changes before acceptance, or explain the reason of its rejection. 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.