The answer can be quite complex, but generally it is the responsibility of the funding body. Additional information can be found in the legal aspects of the research data.
It all depends on the status of the platform used to generate them. The platform’s terms of use must clarify the issue regarding data.
An FAQ on Couperin’s open science website specifies the scope of application of the law (when you can submit, how, what, etc.).
The UGA covers all or part of the publication fees (APC – Article Processing Charges) only for publishers with whom it has an agreement. You must inform the publisher of your affiliation with the UGA.
Otherwise, the fees are payable by the laboratory or research organisation.
To learn more:
List of publishers for which the UGA subscription entitles you to discounts on APC fees
Information sheet about APCs (french version only)
You should submit your article in the language in which it was published.
One-third of submissions are in French and two-thirds are in foreign languages, and two-thirds of visits to the website are also from outside France.
To help you identify a trustworthy journal, you can consult the practical guide on predatory journals (french version only).
When you deposit your article in HAL, it is automatically protected by copyright. The deposit date and unique identifier guarantee the scientific priority and authorship of the publication. This information has legal value.
An article that is visible in digital form is more easily detectable by plagiarism detection software that relies on online corpora.
I am not required to submit my article to HAL unless my publication has received funding from the European Union or the ANR, or if I am a researcher employed by the CNRS.
The UGA recommends that you submit your articles to HAL (Open Science Charter).
For assistance, you can consult the page on funding agency requirements.
However, submitting my article to HAL will give it greater visibility (indexing by search engines such as Google Scholar).
It depends on the type of funding for the thesis.
For example, in the case of ANR or Horizon Europe funding, the data management plan (DMP) is a deliverable of the research project, the first version of which must be provided six months after the start of the thesis.
In all cases, the DMP is a tool for planning and monitoring data. Its primary purpose is to facilitate the progress of a research project (data collection, organisation, storage, etc.) and the exploitation of the data produced. It is therefore recommended that you draw up a data management plan for your thesis. The CDGA can assist you with this task
Firstly, your thesis supervisors can advise you on their expectations and best practices for data management.
In many UGA laboratories, a data advisor can also help you with data management. You can find a list of laboratories with advisors here.
Two services can support you throughout the data lifecycle during your thesis: the cell Codes Data Grenoble Alpes (CDGA) and the Thesis Reporting and Doctoral Student Support Service.
It is recommended that you deposit your data in a repository corresponding to your discipline (e.g., Nakala for the humanities, CDS for astronomical data, EasyData for environmental sciences). To help you identify a thematic repository, the Research Data College of the Open Science Committee offers a method for identifying trusted thematic repositories, as well as an initial list of repositories, which is evolving and will be gradually expanded. Other resources: CAT Opidor and Re3data.
If there is no thematic repository in your community, we recommend that you deposit your datasets on Data Repository Grenoble Alpes, the UGA institutional space of the national Recherche Data Gouv repository. Your datasets will be moderated, which will improve accessibility.
The cell Codes Data Grenoble Alpes (CDGA) can help you identify an appropriate data repository and deposit your datasets.
Metadata enhances research data by making it more visible through a detailed description of the datasets made available. It therefore ensures greater reusability and allows for citation, giving credit to those who produced the data. Metadata makes it possible to link the various products of a research project (publications, data, theses, codes and software) in order to enhance all aspects of the work.
Many publishers now require the data associated with your publication to be available. They often provide lists of repositories or their own repository. Your publisher cannot force you to use their repository: you are free to choose which repository to disseminate your data through. If you encounter any difficulties or would like advice, you can contact the cell Codes Data Grenoble Alpes (CDGA).
The licence defines the conditions of use for the software. It is therefore essential if you wish to share your code and allow others to use it, modify it and redistribute it. However, for employees or public officials (and their research interns), it is the employer who owns the economic rights and must choose the licence.
As part of the open science movement, the UGA recommends choosing an open source licence.
However, be careful if the code includes other codes: the overall licence must be compatible with the licences associated with the reused codes. In the case of so-called permissive or contaminating licences, the software must be distributed under the same terms as the original licence. This is the case, for example, with the GPL licence.
First and foremost, the code must be accessible. Ideally, a software forge and a public project should be used to disseminate the code, but also to allow others to contribute.
In this case, there is a good chance that the code will be archived on the Software Heritage infrastructure.
All you need to do is report the code on HAL by creating a record. Linking to the code archive via the Software Heritage SWHID identifier is very simple. You can find more information on this page.
Using the citation proposed by HAL allows you to link your publication to the code.
If there is no software record on HAL, you can also cite the code using the Software Heritage identifier.
The UGA offers a software forge, which you can access using your agalan login.
Please note that this forge offers the option of external accounts to meet the needs of collaborative work with people outside the site. In addition, you can use services such as continuous integration with shared runners and GitLab pages.
If the project is international, it is possible to use commercial forges such as github.com, but you must remain very cautious with these sites.
The Open Science Committee’s Source Code and Software College has published a report on the current state of existing forges.
Scripts are codes written in an interpreted language that does not require compilation (such as Python, for example), and are therefore ‘directly’ executable.
This term is used in several contexts:
In web development, a script is a program or piece of computer code that executes a function when a web page is displayed or a user action is performed.
In the case of standalone tools, we often use the term ‘scripts’ to refer to relatively small pieces of code in a single file that have a very specific purpose, such as pre- or post-processing data, visualising it, automating successive commands, etc.
If such programmes are part of the research process leading to a publication, it is equally important for reasons of transparency and reproducibility to disseminate them under a free licence.
Documentation is essential for sharing code, but above all, it is also indispensable for the developer(s) themselves to ensure that the code is understood and can be reused, even over a long period of time.
It incorporates different levels:
the first one is fundamental and concerns the code itself: it involves imposing a few simple programming rules on yourself, particularly for naming variables and functions. It is just as important to comment your code properly. This is the minimum effort you can make for yourself and for others.
the second one is the README file, which is the showcase for the code since it is the file that is displayed on a software repository. It is therefore important to ensure that it contains essential information: dependencies, installation, examples of use.
finally, more advanced documentation (possibly created using automatic tools such as doxygen), tailored to the audience: users or developers (and therefore potentially future contributors) becomes important if the ambition is to grow the community around the code.
Being able to reproduce the results of a publication is one of the key challenges in ensuring transparency and trust in science.
Computational reproduction is particularly complex because software depends on an entire environment, dependencies, and possibly the hardware used.
To maximise the chances of success, it is essential to follow good programming practices: use a software forge, document your code and algorithms thoroughly, and identify the version used precisely (e.g. via a commit number or SWHID, Software Heritage identifier).
There are also reproducible packaging tools such as Guix or nix. The use of containers can also help maintain a stable environment for reproducing results.