FAQ

HAL is an open archive, i.e. a platform that allows both the permanent archiving and the open access diffusion of scientific production. It was created in 2001 by the CNRS and continues to be maintained by the Center for Direct Scientific Communication (CCSD).

National and multidisciplinary platform, HAL also allows the creation of institutional or thematic instances. HAL is at the heart of the Open Science strategy at the national level (National Plan for Open Science, CNRS, French national agency for Research ANR, etc.) as well as at the UL.

The HAL Univ. Lorraine portal officially opened in May 2016. It became the official bibliography of the University in 2018.

When the project was launched in 2014, 4 solutions were tested: Dspace, HAL, Islandora and Okina (based on Drupal). HAL, that emerged as the winner of this test phase by meeting more than 80% of the expected functionalities listed by our pilot laboratories, was logically chosen by the project steering committee. Identified as a national archive by the Ministry, HAL is used by more than 150 institutions of the French higher education and research and thus facilitates the management of publications in the joint research units/UMR. Since then, plenty functionnalities have been added (to learn more : https://factuel.univ-lorraine.fr/article/hal-ul-bientot-10-ans-des-fonctionnalites-etoffees/)

The article 30 of the Law For a Digital Republic authorises you to deposit the version accepted for publication of your journal article in HAL, whatever contract signed with the publisher. If the publisher requires it, you can set an embargo period on the file when you deposit in HAL. The maximum duration of the embargo is 6 or 12 months depending of your research area. See the application guide (in French).

The accepted version is the final version of your article, that includes revewers’ corrections. It can also be called final draft post-refereeing or accepted article or accepted author manuscript. It content is identical to the publisher’s PDF whithout the journal layout.

The Right Retention Strategy was developed by the Coalition S, a group of international research funders, including the French national agency for Research ANR. It consists of no longer transferring intellectual property rights to a publisher, and of allowing immediate open access to articles by depositing them in HAL at no cost, regardless of the distribution model of the journal in which they are published. See our memo (in French) and the official resources (in English).

When in doubt, contact: 

Article 30 of the Law for a Digital Republic (LRN) authorises you to submit the accepted version of your articles (without the publisher’s layout), regardless of the contract signed with the publisher, with a maximum embargo of  6 months or 12 months after publication.

For documents other than articles, the contract signed with the publisher applies. However, this is negotiable.

See the practical memo (in French) https://zenodo.org/record/6506651/files/copo_fiche-ao-droits_2022.pdf

“From a single deposit in HAL” infography

From a single deposit in HAL :

• I perennially archive my production
• I am referenced by search engines susch as Google Scholar
• I can be read by many people, in particular by the citizens who have contributed to finance my research
• I dynamically update my online CV and ORCID account
• I dynamically feed my personnal website and/or that of my research unit
• I export the list of my publications or those of my unit in a few clicks thanks to ExtrHAL

The Research Support Network is a team of librarians spread across all the University’s campuses. Its members are at your service to provide training and support, carry out quality control of UL deposits and answer any questions you may have about HAL. Don’t hesitate to contact them:

They can intervene in your teams/units in the way that seems most appropriate to you: presentation, workshop, focus on a specific point, permanence in the units, individual meeting, face-to-face or remotely.

Moreover, 1 hour online workshops are scheduled regularly (maximum of 5 people to ensure maximum interaction).

Program and registration

If you need help choosing a data management tool, please contact the ADOC Lorraine data workshop:  

Drawing up a data management plan for a project or structure

All the institutions responsible for the Lorraine university site recommend the use of DMP OPIDoR.

Producing data

All the institutions advise LimeSurvey (LimeSurvey UL, LimeSurvey Inria, LimeSurvey AgroParisTech, LimeSurvey INRAE) for surveys and EXPLOR for intensive computing.

All institutions provide scientific platforms on which you can find presentations here:

• Université de Lorraine
• Inria
• AgroParisTech
• INRAE

Managing data

All institutions advise FileSender for sending big datasets and Gitlab for managing source code (Gitlab UL, Gitlab Inria, Gitlab INRAE).

Other thematic services are provided:

• Université de Lorraine: electronic laboratory notebook with eLabFTW / samples managing with GRR / managing of access for external members of Université de Lorraine with Invités Numériques
• INRAE: hosting of postgresql or mysql databases  (https://cat.opidor.fr/index.php/BD_PostgreSQL) by the IT of INRAE / hosting of Postgresql databases by the SILVA research unit. Many other services are available on request (they require an INRAE account), their description being provided on the Ariane INRAE portal particularly in the ‘Collective IT Infrastructures’ category. INRAE is also supporting a tool developed in-house for the samples management also described in the Ariane portal.

Storing data

• Université de Lorraine: B’UL for collaborative working and data under 20 GB (OTELo cloud for the OTELo cluster) / PETA for high-volume data.
• Inria: MyBox for collaborative working and data under 10 GB (volume can be extended on request).
• AgroParisTech: SeaFile for collaborative working and data under 100 GB.
• CNRS: sDrive for collaborative working and data under 100 GB / ShareDocs (IR* Huma-Num; for data storage and sharing, day-to-day work; data volumes of up to approx. 1 terabyte) / Huma-Num Box (IR* Huma-Num; for large volumes of cold or warm data).
• INRAE: High-performance file storage solutions, capacitive storage, Sharepoint, Nextcloud and local Nas are offered by the INRAE IT Department.  To request these services or access a description, simply go to the Ariane portal.

Publishing data

All institutions recommend that finalized data be deposited in atrusted disciplinary repository (ask the data workshop  ADOC Lorraine for advice) ; failing which, we recommend that you deposit Recherche Data Gouv (institutional spaces Université de Lorraine, Inria, INRAE, CNRS).

Valorizing data

• Université de Lorraine: numerical platform CENHTOR for SHS research projects. Scope: interdisciplinary projects, research data, exploitation (tool platform) and enhancement of corpora and databases, support services for data deposit and editorialization, data curation / thematic databases for other disciplines using open-source software OMEKA S / virtual server hosting.
• CNRS: the NAKALA data repository embeds a NAKALA-PRESS publishing system, enabling the editorialization of a customizable website based on a collection of data deposited in the repository.
• INRAE: various services (web applications, R Server, etc.) based on the INRAE IT Department’s virtual machine supply service. For example, the forestry water balance model application BILJOU.

Research data represent all the data (raw or elaborated) that constitute the primary material of a scientific research activity or project. The multiplicity of materials (sounds, videos, lines of code, thermal surveys…) justifies the complexity of giving a unique definition.

Nevertheless, there is general agreement on the most commonly accepted definition, that of the OECD, which describes research data as “factual records (numbers, texts, images and sounds), which are used as primary sources for scientific research and are generally recognized by the scientific community as necessary to validate research results”.

Data are the foundation of scientific research and the basis for the development of new hypotheses.

Thus, good management allows to:

• reduce the risk of loss and secure data with recommendations, choice of tools and adapted hosting,
• guarantee the origin and traceability of the data handled by documenting these steps,
• optimize the organization of the mass of data produced through best practices.

The final objective is to provide the researcher with a reasoned approach to his or her data in order to derive maximum benefit from it during the project but also in the years to come.

Publishing data more widely allows :

• a re-use of the unique sets because of the costs linked to their production,
• a reproducibility of the research presented in the associated publications,
• a re-exploitation by students as didactic material,
• an emergence of new research tracks to boost innovation,
• and an enrichment of the world scientific heritage.

Opening your data brings many benefits:

• Get more citations on publications linked to data (source The citation advantage of linking publications to research data)
• Associate your name with the data you have produced
• Meet the requirements of many journals and funders
• Expand your professional network
• Keep your data safe and secure
• Save time and money by reusing other researchers’ data; save time for other researchers
• Contribute to the reproducibility of research results
• Work for the transparency of the scientific process
• Anticipate the evolution of evaluation, which will also concern research data (see the Paris call for research evaluation 2022)

Many journals request access to research data during the peer-review process. DOREL allows to give access to deposited but not yet published data, via the private URL function. This way, reviewers can see the data without it being accessible to everyone, and files can be modified as much as necessary before publication (and thus final DOI attribution). Need help? Write to

DOREL allows to make a link from the data to the associated publications. HAL also allows to make the link from the publications to the data.

Research data are often accompanied by scripts (written in Stata, R, MATLAB, Python…). In order to ensure the good readability of the data, it is recommended to deposit the scripts with the data in a repository. The advice of the Dataverse guide can be followed for DOREL.

Note that full-fledged software can be deposited in HAL and in Software Heritage to guarantee their durability. See here the instructions (in French).

Software (or computer program) is the description, in one or more computer languages, of a process for processing specific instructions that you want a computer to perform. Programs come in the form of binary code (or executable code) and source code (instructions that can be read by humans). This definition includes any algorithm expressed in an executable computer language. Software may also include documentation and examples of use.

Find out more (in French): “Source Codes and Software” from the National Committee for Open Science (CoSO)

As part of its Open Science policy, the Université de Lorraine encourages the disclosure of all codes, scripts, and software developed in the course of research, provided that this approach is compatible with the project (in particular due to possible clauses linked to funders or if a path to economic exploitation through proprietary software has already been chosen).

• To promote transparency

The primary objective is to promote transparency in the methods used to obtain published results, as well as their reproducibility, by making the source code and associated data accessible on a software forge and data warehouse.

Since these are products of research, it is important to prioritize their open access in order to contribute to the quality, integrity, and dissemination of research. As with open source, the goal of open science is to transparently disseminate a useful IT tool in a specific field or for a particular community.

• To promote your work and claim authorship

Making the code available allows you to both promote it and claim authorship.

The authors of the solution can then benefit from contributions, citations, or partnerships. The promotion and recognition of the development time of these code-based tools in a researcher’s career is also becoming increasingly important.

For source codes and software, it is important for authors to consider their scope and potential reuse and to consider an appropriate distribution method.

The publication of source codes and software must therefore be preceded by careful consideration of how the project can be promoted, depending on the target audience. In particular, it is important to consider whether or not to promote the project economically, which software license to choose, and what information to publish online (documentation or dedicated website). The UL’s research support services can assist you : .

Depending on the funding and partnership(s) established in the production of this type of IT object, the source code must be made available with an appropriate license or lead to the adoption of a specific strategy that allows the rights to use and modify the initial code to be retained. When the work involves industrial or economic partners, the strategy and choice of appropriate license(s) for your computer code are all the more important if you want to control its future.

• For researchers

By making the code you used available, you enable other researchers to verify, reproduce, replicate, or reuse your research approach.

• For developers

Another important point is to allow any qualified person to take over and improve a past or present tool for future applications in a rapidly evolving scientific context (standards, requirements, formats, processes, etc.). The development cycle of software or other IT objects is not fixed in time. It can be reused, evolve, and even outlive its author(s) (notably thanks to the features of code repositories that allow copies of the original code to be made).

• For future generations

Making your code or software available allows future generations of researchers to benefit from previous development efforts, expertise, and the transfer of knowledge and processes in a specific field of application.

This is why documentation related to the use and reproduction of results using computer code is crucial. In addition to documentation, the execution environment and dependencies related to the code are also very important. At a minimum, the sources and resources necessary for using computer code must be cited, and ideally a virtualized execution environment containing the necessary elements should be provided (this is referred to as containerization or virtualization, depending on the case).

It is recommended that the source code (once mature) be made available on a software forge, such as the one offered by UL. The UL forge is automatically harvested by the universal source code archive: SoftwareHeritage.org for code repositories in “public mode.” Regardless of archiving, you can reference your source code on the HAL platform to improve its visibility and facilitate citation.

Since 2018, HAL-UL has been the official bibliography of the Université de Lorraine. Codes are among the research products that can be referenced there. Depositing source codes in HAL promotes their dissemination and citability thanks to metadata (domain, research fields, keywords, identifiers). It facilitates links between data, codes, and publications. Proper referencing in HAL also increases their visibility and sharing on the web. HAL also manages publication versioning to update source code that has been reused or updated during an ongoing development version.

As part of its SO policy, UL encourages the deposit of source codes in HAL and their archiving in Software Heritage. For more information :

• Submitting software source code (in French)
• HAL summary sheet > submitting software to HAL

If you have an ORCID account listed in your HAL profile, the codes referenced in HAL can be transferred there, just like your other publications.

More information : HAL summary sheet > link your ORCID to HAL

Software Heritage archives publicly accessible source codes. HAL facilitates the citation of source codes and their display on websites (personal, research units) and promotes links between publications, data, and codes.

Software Heritage is a non-profit infrastructure created in 2016 by INRIA. It is supported by a panel of institutions and industrial partners around the world in collaboration with UNESCO. The visible part on the internet, softwareheritage.org, is a platform with a specific interface comprising a website, documentation, and a dedicated API, as well as a system for assigning unique identifiers (SWHID) to the deposited code.

“Collect, preserve, share”: Software Heritage’s ambition is to enable the creation of a universal archive for all code produced worldwide by recovering what is possible and storing it in a sustainable manner. The platform does not archive binary data, but rather readable source code deposited in software forges such as Gitlab or Github, or manually triggered by a user in connection with specific repositories (Debian, NPM, Pypi, etc.). Software Heritage explores referenced code platforms by default, but specific harvesting points can also be submitted to the archive on request.

Once archiving is complete, a unique identifier is generated: the SWHID. This allows you to reference the code accurately and transparently for distribution across the web. In addition, the SWHID facilitates the referencing of your source codes in HAL (or can also be generated by a HAL deposit of your code in the form of a zipped archive).

We talk about open source code when code developed as part of research work is published on a software forge or website and is freely accessible. Before code is posted online, several factors and conditions must be met:

• the code must be sufficiently stable and functional;
• the associated documentation must explain the purpose of the code and provide examples to enable its reuse, as well as information on permitted contributions;
• consideration must have been given to the potential/desired economic value in order to choose an appropriate license.

Other factors must also be considered, such as the possible evolution of the developed code: integration into other programs or libraries, or even its reuse in a larger project, etc. The code’s ability to be used by other disciplines should not be overlooked. The documentation should demonstrate its potential usefulness in order to make it easier for non-specialists to integrate it into their own work in their discipline.

If the code is not intended to evolve further (end of research project on this topic), opening it up can allow people who wish to adapt or improve it for their own needs to contribute. To do this, once the source code has been made open, it is necessary to specify the contributions that can be made in this context. This can be done by adding a specific file, such as a CONTRIBUTORS or CONTRIBUTING file, to the code repository, specifying the rules to be followed by future contributors.

Furthermore, the license plays an essential role in the possible evolution of the original code and its sharing through contributions to the community. For example, for open source code, certain licenses require that modifications made by contributors to the project be redistributed under the same license conditions, so that everyone can benefit from the improvements made in new versions.

Regarding the promotion of the source code produced: it can be very beneficial to associate it with a scientific publication related to the field or to data directly used or produced by the code or software. Scientific data also helps maximize the visibility of the work carried out and associated with the source code produced. To do this, you can cite the persistent identifiers for the publication, data, and associated code whenever possible, as well as any associated authors and successive contributors. Official websites that list scientific publications will be able to more easily link these three types of output and highlight them when someone searches for a particular topic.

Regarding publication on the HAL open archives: you can submit a specific file (called a “Notice” in HAL language) on source code to accompany a scientific article that references it, or spontaneously to report the existence of a computer tool developed as part of your research. This could be a calculation script, a software module or library, or a complete program.

At present, the HAL platform only allows freely accessible code to be referenced. If your code is not freely accessible, it will not be possible to display it in HAL. However, you can manually create a reference on your ORCID account in the “Works” section, where there is a “Software” type.

A growing number of developers are now using generative AI tools to assist in the production of computer code. Therefore, it is important to bear in mind national and international recommendations on the use of generative AI in research, which identify three main issues that apply to the specific case of code, software, and their openness :

• Reliability : Is the generated code truly functional? Does it depend on a specific environment to work? Am I able to explain and justify how it works? Is the code optimized?
• Personal data : Does the work carried out using generative AI lead me to share confidential and/or non-anonymized data with a third-party service that may reuse or even sell this data? Is the use of generative AI to develop data compliant with the General Data Protection Regulation (GDPR) and, more specifically, with the project’s Data Management Plan (DMP)?
• Transparency : Have I taken care to specify that I used generative AI to assist me in producing code, and if so, which one? Have I documented the code? Who does it belong to? (If it is not generic code, but research code, the sources must be citable at a minimum.)

In addition, given that environmental impact is a growing concern and considering the resources required to operate generative AI, the use of frugal models should be prioritized.

A second aspect concerns the production of open generative AI models and tools. Researchers involved in such an approach are therefore required to publish and make available:

• the code;
• the weights and weightings used (parameters and version of the model used, as well as the prompt, in a fully transparent manner);
• the data provided to the AI.

A third important aspect is to check the various licenses of the software components that will be used and possibly integrated with the help of generative AI, and to verify what impact this may have on the nature of the license of the generated software (concept of copyleft and distribution). I have a project or code: who can help me consider opening it up?

Under French law, source code that is not accompanied by a license is protected by copyright, which prohibits any use, modification, or distribution without the express permission of the author.

Any source code considered sufficiently original (i.e., considered a work of the mind as opposed to generic code) is protected by copyright. Consequently, without specific indication from the author, no one is authorized to do anything with it (except for quotation and private use). It is therefore preferable to choose and explicitly specify the use of a license in your source code. It is also important to consider from the outset the possible uses of the software and its future development. If you do not have any particular ideas on the matter, it may be worthwhile to assume that if your solution is highly successful, you will have a suitable license to protect the code against any misuse or threats to its use.

During software development, it is also very important to check the uses of external source codes that have contributed to the project and the compatibility of other licenses with it.

In some cases (strong copyleft license on reused code), you will have no choice but to publish under an equivalent or identical license. It may be wise to allow for additional internal development time during your project to avoid incorporating external code with an incompatible or overly “contaminating” license.

Distributing your software or source code freely, i.e. under an open source license, allows you to collaborate with researchers from all backgrounds and create important projects in higher education and research.

Sharing your source code under a free and appropriate license allows for:

• Transparency in the processes used to obtain results
• Guaranteed reproduction of the results presented
• Reuse based on a reliable reference framework
• Comparisons based on different scientific approaches

From a researcher’s point of view, using free software allows you to :

• Report any malfunctions (bugs) to the creators/maintainers
• Study and modify the source code to propose corrections and improvements
• Adapt the software or source code to your needs
• Be part of a community that exchanges ideas on a specific scientific theme or issue

These types of interactions are therefore very useful if you are developing software or a library and want to share and receive contributions from others.

Finally, it is important to remember that, in the context of its work, the Université de Lorraine owns what are known as economic rights (to publish, distribute, and disseminate), while the creators of the code or software retain the copyright(s). Therefore, if you wish to distribute your software under an open source license or make it available in the public domain, make sure you have the agreement of your organization to avoid any subsequent disagreement regarding its availability.

Without a license, modifications, distributions, and executions of the code are not legally authorized. Furthermore, if no license is explicitly specified, someone viewing the code (on a forge, Software Heritage, HAL, a web page, etc.) may not know whether this omission is intentional or unintentional. Furthermore, the terms of use of the service hosting the code (such as a forge) may provide for a default license that applies to the deposited code, adding an additional source of confusion.

Choosing an open source license (as opposed to making the code available in the public domain, which is a waiver of authorship and copyright) allows anyone to reuse the code under certain conditions, while retaining the copyright(s).

The choice of license for code or software depends on the authors’ initial considerations regarding the economic and academic distribution model they wish to adopt before releasing it. This choice must also take into account the software’s target users.

This requires a preliminary analysis of the possible ways of exploiting the software, depending on its field of application, the future target users, and existing competing solutions. This approach allows the license to be aligned with the strategic objectives of the project, whether commercial, collaborative, or academic.

There are three main types of licenses and approaches to consider :

• Open source license: promotes collaboration, transparency, and code reuse
• Proprietary license: restricts access to and use of the code, often for commercial or intellectual property protection reasons
• Hybrid model: combines both approaches, for example by opening up the application core while keeping certain modules under a proprietary license

When choosing a license, it is essential to explicitly define the rights granted to users, often referred to as degrees of freedom (DOF). These rights mainly concern:

• Use: rights related to the compilation and execution of source code (e.g., for personal or professional use, or for integration into other software)
• Study: access to the internal workings of the software, particularly for analysis, auditing, or educational purposes
• Distribution: conditions for redistribution (free or paid) and marketing, including terms for sharing the source or binary code
• Modification: authorization or restrictions concerning improvements (corrections, optimizations) or major modifications (redesign, adaptation to new uses)

Copyleft is a legal mechanism built into certain licenses (such as the GPL or AGPL) that aims to guarantee the freedom of software or source code, including modified or derivative versions. Unlike copyright, which restricts usage rights, copyleft requires that any derivative work retain the same freedoms as the original.

For software or source code to remain free under copyleft, its license must explicitly allow users to study, modify, and redistribute the code (degrees of freedom, or DOF). It must also require that any modified or derivative versions be distributed under the same conditions of freedom (this is the “viral” or “contagious” effect of copyleft).

Copyleft protects free software from private appropriation (for example, integration into proprietary software without sharing modifications). It thus ensures that improvements benefit the entire community, maintaining an open and collaborative ecosystem.

There are a large number of OS licenses, with varying degrees of copyleft. There are three main categories:

• Licenses with “strong” copyleft (e.g. GNU GPL): obligation to republish under an identical or compatible license. These are known as “contaminating” licenses, meaning that the license applies to all aspects. The license in question will be imposed on any new software that incorporates it as a derivative (adaptation, modification of code) or associates it in composition.
• Licenses with “weaker” copyleft (e.g., Lesser GPL): the original license is applied, but additions are possible with other types of licenses, the aim being to extend or clarify certain aspects due to the evolution and/or incorporation of new code(s). The license in question will be imposed on any new software that incorporates it as a derivative, but it will be permissive in composition.
• Without copyleft (BSD, MIT). These are referred to as “permissive” or “very permissive” licenses because there are very few obligations for users. Additions and modifications are possible, and it must therefore be accepted that in this case, proprietary use may be made of the software without any specific compensation for the open source community, which may not benefit from the modifications made. This software license is permissive in terms of derivation and composition.

Diagram showing the combined and separate effects depending on the level of copyleft in free software

There is an official list that lists all the licenses recommended in the French public sector.

You can find all existing licenses and their identifiers at this address : https://spdx.org/licenses/

Note: some licenses are more suited to the interpretation of French law, e.g., CeCILL-C.

When you publish your source code or software and make it available online to everyone, you must first include a specific license file in your repository or software archive.

This file is usually placed at the root of the project and can have various names (usually in English):

• LICENSE (with or without the extension .txt, .md)
• COPYING (with or without the extension .txt, .md)
• “LICENSE_ID” for example: GPL-3.0-or-later.txt

There are no rules, just naming conventions adopted by a large community of online users (developers).

The presence of the license is essential for depositing and referencing code on platforms such as HAL or Software Heritage. It is also important to include this information when you use a software forge. This allows users to know what they can do with it.

A common practice is to include headers in each source code file, specifying the copyright, date, license used (with a link to the license text, if applicable), and possibly a contact address. In the event of doubt or a dispute, this will provide a valid reference for ruling on rights issues.

For greater clarity regarding licenses, it is also useful to specify the license identifier in your software project. This information is usually specified in the ‘codemeta.json’ file in the repository (or in the CFF citation file). You can find license identifiers at this reference address: https://spdx.org/licenses/.

All source code and software is considered intellectual property and is therefore protected by copyright. In specific cases, software may be patentable under certain conditions in France, provided that it meets the criteria required for industrial characterization.

Software remains an object at the crossroads between intellectual property and technical invention. It is copyright that protects the content of the software.

In specific cases, software may be patentable provided that it is part of a new technological invention involving industrial use. In this case, it is part of a more comprehensive invention that can be patented. However, it is not the software itself that is patented.

Beyond its translation into computer instructions (the software part), the invention includes ideas, procedures, specific concepts, and methods of operation specific to a scientific field applied to industry.

To put it simply, copyright protects software and patents protect inventions. The treatment of software patentability in Europe currently differs from that in other countries such as the United States and Japan.

Copyright for software is obtained without any special formalities, provided that the work is considered sufficiently original (as opposed to generic or already existing). In some cases, it may be useful to file a declaration of invention with your employer to determine the strategy and level of valuation that can then be considered.

It should also be understood that, with regard to software, patents constitute an ecosystem of documents that are difficult to interpret without the help of a lawyer. It is quite complicated to find what you are looking for explicitly in patent registers when it comes to software.

The use of software patents is not recommended for open source projects. If software were covered by a patent, it would be necessary to systematically verify that its publication and distribution did not infringe any existing intellectual property rights. Such a constraint would considerably complicate the sharing of software, whereas open source aims precisely to disseminate it as widely and freely as possible.

The Software and Codes Committee (CoLoC) can assist you with this aspect, as well as with all stages of your project. To contact the CoLoC: