Introduction by Malcolm Bain
International annual conference cycle, the European Open Source & Free Software Law Event (EOLE) aims to promote the share and dissemination of legal knowledge related to free software, as well as the development and promotion of good practices. Initiative born in 2008 from practitioners’ needs, EOLE has for purpose to develop a legal doctrine dedicated to the dissemination of neutral and qualitative information.
Current situation of FOSS compliance
Open source based on licensing : we need to look at licence and see if there is an impact. The question is raided : How can we do compliance together ?
Industry has done professionalization and industrialization of compliance processes, by working with lawyers, dev, compliance officers, etc. and involving several processes and tools.
- Processes : Open Chain, ReUSE,
- Tool development : SPDX, OCR, Fossology, Simply Defined ValidOS.
But, main issues are :
- Individualist rather than collaborative (lack of collective approach),
- Repetitive and nonsystematic,
- « Risk » driven (law cases) instead of positive contribution to FOSS ecosystem,
- Lacking collective approach: vision, understanding, results,
- A major challenge for lawyers.
The main goal here is to make the compliance easier and more collaborative.
Goals of the workshop
Why this subject? A lot of open source research project used and republished in research
- Think how Research Organisations and researchers may participate in FOSS compliance process and how best can they contribute,
- Think of the role of Researchers regarding Open Source compliance,
- Identify short and midterm targets and collaborative projects to support collaborative compliance.
Specific challenge
- We need skills to do Open Source compliance,
- Compliance is much more collaborative when we use a platform.
What is the risk for the research, the university, the users ?
- Legal: licence compliance, copylefting your code, complying with grant or contract requirements,
- Technical: not easy to patch and update, security issues, maturity issues, provenance… etc.
- Tech transfer: code that is not transferable (incompatible licence, or licensing incompatible with transfer model / licence requirements).
This impact on all dimensions of the quality of the research.
Exchanges with the participants – Moderated by Malcolm Bain
During the second part of the workshop, the debate was open so that each participant could speak and share their experiences in 2 exercises (1 – Breakout session and 2 – Brainstorming Circle).
1 – Break-out session – How do you do ?
Objectives : Share current common level and experience in open source management (compliance).
The aim of this first session was to get the players around the table talking and, above all, to remind them of the context in which they find themselves. This round table discussion was conducted in small working groups and then shared with all participants.
Main elements reported during the session
- Open source software are bound to publications, nobody is checking the compliance. In some cases, it is in the hands of professor and researchers and technology are there to support the process.
- Different levels of autonomy, some can choose licences (ex: GPL by default in University of Luxembourg), others are bound to what the editor of the paper has chosen, Some institutes, universities, have already intellectual property (IP) policies in place while others have to do it all manually. So that, there is a need of commons policies on the subject because there are few places with Open Source compliance management :
- When IP policies are in place :
- there are people to help to choose the licence, software reporting systems to know which software to use,
- there are templates to support Open Source compliance activity and processes.
- When IP policies are not in place or are not clear :
- processes are not always sophisticated and elaborated, which can lead to chaos,
- there are not many resources to make compliance,
- sometimes, the work is done manually thanks to tools like Scancode, and because of that, not everything is reported.
- When IP policies are in place :
- There are Git Repository centralization for researchers,
- There is a need of an awareness work on the compliance subject, but it is still a long way to go,
- The use of Open source is not valorized in research.
Discussion
The following questions have been discussed : do you have the awareness to use these distributions ? Are research PI aware of that ?
Here are the key elements that have been noted :
- Putting a licence is a first step.
- The copyright holder often does not know about open source compliance.
- Compliance is difficult for software in general, as companies will rewrite software anyhow. So that, there is a need from the researchers to document what is what,
- The analysis is complex to do :
- When you involve a legal department, it becomes more complicated than to do it by ourselves,
- Analysis with Blackduck is complex,
- There is a question of responsibility when you do a compliance analysis, the difficult is to be sure that something isn’t missing (checking the dependencies for example),
- The checking can be done at different steps of the process depending on the nature of the project
- It can be different whereas the nature of the project, it can be at its early development or once the project is mature.
- What happens if you sell the product ? There is a need of preliminary check on all software packages. This and will help the negotiation position.
2 – Working session – Challenges and aims
Objectives : Discuss together and the challenges and aims raised to do Open Source compliance in research and academia.
Rules : You have to fill the post-it in the brainstorming circle, taking in account the different categories.
- Red circle : Why it is important (and it is a challenge) to imagine FOSS compliance through community approaches in ROs?
- Orange circle : How can ROs provide some input for solving compliance issues on a collaborative basis ?
- Green circle : What can ROs do ? What kind of concreae action can ROs do in order to answer to previous questions ?
Why – Arguing for an open approach to Open Source compliance
The challenge to imagine FOOS compliance through community approaches in research organisations
- Mitigate legal risks & litigations,
- Make research results applicable & useful for society, industry and public,
- Reduce overhead cost of compliance for research results and lower the cost of compliance check to do it with current public institution resources,
- Challenges : capacity to do it, low visibility of the problem, lack of personnel.
A collaborative effort to create trust
- Need to create something that would ease our lives and push the subject in the working circles. European money could fund it,
- Importance of trust of the research to do compliance. But it raises the question about the tool to use to do so,
- Sharing of responsibilities : who is assigned to do the final check ?
A context calling for this need
- Open Source software are bound to publications, there nobody is checking the compliance. In some cases it is in the hands of researchers and professors with technologies,
- Different levels of autonomy : some can choose licences, others are bound to what the editor of the paper has chosen. Some institutes, universities, have already intellectual property (IP) policies in place while others have to do it all manually.
- When IP policies are in place : there are people to help to choose the licence, software reporting systems to know which software to use and there are templates to support Open Source compliance activity in processes.
- When IP policies are not in place or are not clear : processes are not always sophisticated and elaborated which can lead to chaos, there are not many resources to make compliance, the compliance is done manually (thanks to tools likes Scancode) and because of that not everything is reported,
- The use of Open source is not valorized in research : need of an awareness work on the compliance subject, but it is still a long way to go.
You can participate in the discussion by adding you ideas on our forum !
How – Stimulate establishment of good practices in research to help researchers with Open Source Compliance
- Putting a licence is a first step : the copyright holder often does not know about Open Source Compliance,
- Need from the researchers to document what is what,
- The analysis is complex to do in particular when you involve a legal department,
- The checking can be done at different steps of the process depending on the nature of the project : at its early development ? Once the project is mature ?
- When you sell the product, there is a need of preliminary check on all software packages.
Need of a community approach
- Need of exchanges of knowledge to reduce the workout and build something together thanks to a framework. This can at least be done at a European level,
- Get closer to Open Source Research group and existing initiatives (ex : https://oss.cs.fau.de/),
- Distribution of responsibilities can be discussed to help researchers to be more aware and have a better way to work,
- Need to sensibilize : researchers need to be involved in the process, create ambassadors and have a voice.
You can participate in the discussion by adding you ideas on our forum !
What – Sharing legal knowledge and understanding about Open Source licences
Share concrete material
- Share learning materials for researchers,
- Create common repositories for compliance checked components,
- Launch a dialogue with intellectual property experts and jointly develop a process.
- Share existing documents such as policies, processes, templates and sBOMS,
- Specify compliance as a research goal and share the results,
- Create a process (with Open Source tools) of software documentation that will allow automatic compliance checking,
- Develop standards and share tools : edit guidelines for researchers with lists of permissive licences and copyleft licences in order to know what to do,
- Provide access to guidelines and checklists.
How could it be shared ?
- Through documentation and awareness,
- Sharing in a version control system,
- Share a minimal protocol to do compliance : what are the steps we go through ? What is sufficient compliance ? Are they tools to automatise it ?
- Intellectual property experts are stakeholders for the process.
You can participate in the discussion by adding you ideas on our forum !
During the session, all the participants were able to add their contributions to the various circles. Here is a report of what was added according to the 3 categories (each represented by a coloured circle).
Final comments and discussion
To close this workshop, a final debate was launched to allow all the stakeholders to express their views and add a final comment. You will find the key points of this discussion below.
A collaborative effort to create trust
- There is a need to create something that would ease our lives and push the subject in the working circles
- Get European money to fund it.
- Importance of trust of the research, of ourselves, to do compliance.
- What tools do we use to build trust ?
- To do so, there is a need of a collaborative effort.
- How to share responsibilities ? Who is assigned to do the final thing/check ? If everyone is responsible, no one is responsible,
- Have a report of good and bad practices.
Research needs to understand what it is important and beneficial to them
- Need to sensibilize : what is the value of what we do ?
- Go out of its ivory tower and try to involve and talk with different people to let them join in.
- Creating ambassadors and have a voice.
- Creating addition value, which is important in case of commercialisation
- Use of licences : depending on what licence you use, you have to match it correctly.
- Pressure of community to use such of licence, driven by the community
- Success Factors / What are the compliance issues and how big they are (retrospectively)
- How to increase the value of the software ? Pre-check the validity ?
Valorize working examples and do more teaching about Open Source compliance for concerned students.
- Software project in Germany : Tool to built software register for yourself. Also a software evaluation tool (input, tolerance level)
- Need at teaching level to help people understand it
- Need to understand and study programming language, how they are built,
- Improvement of the knowledge level of IP of student,
- Teach how Open Source is working and what it is,
- Have success example.