Watch the accompanying video: https://youtu.be/DIFIMagyYvc

1. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101017529.
Copernicus - eoSC AnaLytics Engine
C-SCALE tutorial: Licensing Open-Source
Software
Xavier Salazar, EGI Foundation
Xavier.salazar@egi.eu
C-SCALE tutorial: Licensing Open-Source Software | 26th May 2023 | Online

2. Outline
• Introduction
• Different types of Open
• Importance of Open Source in Horizon Europe
• Difference between IP & IPR
• Main Principles of SW Licensing
• Open-Source SW Licensing
• Examples within C-Scale
• Discussion on sustainability
2
C-SCALE tutorial: Open-Source SW Licensing | 26th May 2023 |
Online

3. Introduction - Diferent Types of Open
3
Open Science
Open
Access
Open
Innovation
Open
Source
Free
Open Science refers to the practice of making
scientific research and data accessible to
everyone, including fellow researchers,
policymakers, and the general public
Open Innovation is a
collaborative approach to
innovation that involves actively
seeking external ideas,
technologies, and expertise to
complement internal research
and development efforts
Open Access refers
to the unrestricted
online availability of
scholarly research
literature, typically in
the form of journal
articles, research
papers, or theses
Open Source refers to software that is released with
a license granting users the freedom to view, modify,
and distribute the source code

4. Open Science in European Projects
4
“Open science” means an approach to the scientific process based on open
cooperative work, tools and diffusing knowledge
(Horizon Europe Regulation and Model Grant Agreement)
The concepts of Open Science, Open Innovation, Open to the World should
ensure excellence and impact of the Union´s investment in research and
innovation, while safeguarding the Union´s interests
(Recital 7 Horizon Europe Regulation)
The work programme may provide for additional incentives or obligations for the
purpose of adhering to open science practices
(Horizon Europe Regulation, article 39)

5. Mandatory Open Science Practices in the Grant
Agreement
• Some open science practices are mandatory for all beneficiaries per the grant agreement.
• Open access to scientific publications under the conditions required by the grant agreement;
• Responsible management of research data in line with the FAIR principles of ‘Findability’, ‘Accessibility’,
‘Interoperability’ and ‘Reusability’, notably through the generalised use of data management plans, and
open access to research data under the principle ‘as open as possible, as closed as necessary’, under
the conditions required by the grant agreement;
• Information about the research outputs/tools/instruments needed to validate the conclusions of
scientific publications or to validate/re-use research data;
• Digital or physical access to the results needed to validate the conclusions of scientific publications, unless
exceptions apply;
• In cases of public emergency, if requested by the granting authority, immediate open access to all research
outputs under open licenses or, if exceptions apply, access under fair and reasonable conditions to legal
entities that need the research outputs to address the public emergency.
5

6. Importance of Open Source in Horizon Europe
• Open Source Software plays a crucial role in Horizon Europe
projects.
• OSS enables cost-effective solutions, collaboration, and knowledge
sharing among project partners.
• It promotes transparency, reproducibility, and access to project
results, facilitating further innovation and exploitation.
• Using OSS aligns with the principles of open science, fostering the
growth of a vibrant research and innovation ecosystem.
6

7. Difference between IP and IPR
7
Reference: https://intellectual-property-helpdesk.ec.europa.eu/regional-helpdesks/european-ip-helpdesk/europe-glossary_en
Intellectual Property (IP) refers to creations/products of the mind, such as inventions, research &
experimentation or products of creativity. Like physical property, IP is an asset which can be traded
(sold, bought, leased, used or given away), and is protected by law.
Intellectual Property
Rights (IPR) is the
legal right granted to
IP owners to protect
their IP, enabling
people to earn
recognition or
financial benefit from
what they invent or
create.
• Copyright (Software, written works, engineering drawings…) – it comes
to existence automatically upon the creation of the original work
• Patents (Technical inventions) - a monopoly right granted in return for
causing the publication of an invention, preventing others to use it without
agreement
• Database rights (Creation & arrangement of data) - legal rights that
protect the creation & management of data)
• Design rights (Appearance)
• Trademarks
• Confidentiality Agreements / Trade secrets (Know-how)
.

8. Software related IP and IPR
8
• Software is a type of Intellectual Property Asset that can be
associated to one or several Intellectual Property Rights
• Source Code, SW components and Associated Documentation
• Use explicit copyright notice (including year & copyright owner )
Copyright
• SW is patentable for computer- implemented invention – i.e. when the
programme has a technical effect (not business or financial)
• Patent protects the effect of the programme (not the expression)
Patent
• Logos
Trademarks
• Protected via encryption
• Shared as binary / executable
Trade Secrets
• Know how
Confidentiality
Agreements

9. Main Principles of SW Licensing
• Licensing means granting the right to use an IP protected asset
under agreed terms and conditions
• Software licenses are the legal contract between the Software
owner and the users.
• It usually specifies permission to the user (the licensee) and the rights,
obligations and limitation of the user towards the Software.
• Typically a software license grants the licensee to use the software but not
to re-distribute or re-sell the software.
• The level of rights retained by the owner of the software classifies what type
of license to use.
9

10. Main Principles of SW Licensing
10
Proprietary Open Source
• Binaries or SW as a Service,
• Against Payment
• Limitations on use / Sell /
Redistribution
• Access to source code,
• Usually ’As is’
• Freedom to use, modify,
re-distribute, etc
• Free means that the licensee gets the Software free-of-charge (i.e.
”gratis”), also known as libre software,
• Open means that the user gets access to the source code of the design.
• Software / code kept proprietary -> closed as industrial or trade secret
(only binaries of the software or encrypted code is shared)
Free of Charge
• SW code
• Restricted use ( e.g.
non-commercial,
trial, etc

11. Key Terms of a Proprietarty SW License
• Scope: Exclusive / Non-Exclusive
• Permitted use: Commercial, Non-commercial, Trial, Educational
• Limitations: Geographic, Specific Market
• Number of installations / Re-distrubution / Sublicencing
• Restrictions on reverse engineering, decompiling or modiying
• IPR ownership.
• Maintenance and Support: Availability of technical support and
upgrades
• Warranties, Liabilities and Indemnification
• Free or against payment
• Termination
11

12. Key Terms of a Open Source SW License
• Source Code Distribution:
• OSS licenses typically require the distribution of the software's source code alongside the executable form. This
allows users to access, modify, and study the underlying code, promoting transparency and collaboration.
• Derivative Works:
• Derivative works are modifications or adaptations of the original OSS codebase.
• Attribution:
• Many OSS licenses require attribution or acknowledgment of the original authors or contributors of the software.
Attribution ensures that credit is given to the individuals or organizations responsible for the creation of the OSS
project. It is a common practice to include copyright notices and maintain a list of contributors in the
documentation or accompanying materials.
• Copyleft and Share-Alike:
• Copyleft licenses require that modifications and derivative works be licensed under the same license terms,
ensuring the openness and accessibility of subsequent versions.
• Share-Alike provisions promote the continued openness of OSS by requiring that modifications or adaptations are
shared under a compatible license.
• License Compatibility:
• License compatibility refers to the ability to combine or integrate software governed by different OSS licenses.
• Some licenses are compatible, allowing code to be combined without conflicts, while others are incompatible,
creating challenges when integrating code with conflicting requirements.
• License compatibility should be carefully considered when using multiple OSS components in a project to ensure
compliance and avoid licensing conflicts.
12

13. Types Open-Source SW Licenses
13
Permissive Copyleft / Reciprocal
• GPL: General Public License
• LPGL: Lesser General Public License
• EUPL: European Union Public Licens
• e (EUPL)
• BSD licenses: BSD (Berkley Software Distribution)
• MIT: The MIT (Massachusetts Institute of Technology)
• Apache License: The Apache License by the Apache
Software Foundation
• Freedom to modify code
• Derivatives can be re-distributed under any type of
license
• Attribution needs to be kept
• Strong copyleft (GPL): Original code and Derivatives
must keep same license rights
• Lesser Copyleft (EUPL, LGPL): Original code must
keep same license rights. No restriction on derivatives

14. Permissive Licenses
• Freedom of Use:
• Permissive licenses allow users to use the software for any purpose, including
commercial purposes, without imposing significant restrictions or obligations.
• Minimal Obligations:
• Permissive licenses typically require attribution and may include disclaimers of
warranty. They do not impose strong obligations to distribute source code or
modifications.
• License Compatibility:
• Permissive licenses are generally compatible with other licenses, allowing
developers to combine permissively licensed code with code under different
licenses, including copyleft licenses.
• Flexibility:
• Permissive licenses provide users with greater flexibility to incorporate the software
into proprietary projects and to choose the license terms for derivative works.
14

15. Copyleft Licenses
• Reciprocity:
• Copyleft licenses, such as the GNU General Public License (GPL), require that derivative works
be licensed under the same license terms. They enforce a "viral" effect, ensuring that subsequent
versions of the code remain open source.
• Source Code Distribution:
• Copyleft licenses mandate the distribution of the source code for the software and any
modifications made to it. This requirement ensures that recipients have access to the source code
and the freedom to modify and distribute it further.
• Stronger Copyleft:
• Some copyleft licenses, like the Affero General Public License (AGPL), extend the copyleft
requirements to software accessed over a network (e.g., web applications), ensuring that
modifications made to the software are made available to users interacting with the network
service.
• License Compatibility Challenges:
• Copyleft licenses are generally not compatible with more permissive licenses. Combining copyleft
code with code under a permissive license would require licensing the entire project under the
terms of the copyleft license.
15

16. Open Source License Compatibilities
16
David A.
Wheeler https://dwheeler.
com/essays/floss-license-
slide.html
GPL BSD MIT EUPL Apache
Attribution / Copyright retained by original authors Yes Yes Yes Yes Yes
Right to Re-distribute Yes Yes Yes Yes Yes
Right to modify the source code Yes Yes Yes Yes Yes
Derivative work must be shared in source code Yes No No No No
License Type of the derivatives GPL Any Any Copyleft Any
Patent Compatibility Protection from Patent Claims Yes No No Yes Yes

17. Assessing License Compatibility
17
https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant

18. Examples within C-Scale - Aquamonitor
18
https://github.com/c-scale-community/use-case-aquamonitor
https://c-scale.eu/unlocking-global-satellite-data-with-openeo/
• Apache 2.0 license
• Permissive license to enable maximum flexibility for
the re-use of the code and future adaptations and
porting to new computing environments

19. Examples within C-Scale - LSDA
19
https://github.com/c-scale-community/workflow-automated-river-forecasts
https://c-scale.eu/towards-automated-ensemble-discharge-forecasts-for-
any-river-in-the-world-on-a-federated-compute-and-data-infrastructure/
• Apache 2.0 license
• Permissive license to enable maximum flexibility for the re-use of
the code and future adaptations and porting to new computing
environments

20. Examples within C-Scale – HiSea
20
https://www.deltares.nl/en/software-and-data/products/delft3d-flexible-mesh-suite
• Apache 2.0 license
• Permissive license to enable maximum flexibility for the re-use of the
code and future adaptations and porting to new computing
environments
• Delft3D Component – while also offered under open-source license –
Support service against payment is offered (under a service package)
– enabling monetization of the whole system.
https://c-scale.eu/supporting-ports-and-aquaculture-industries/
https://github.com/c-scale-community/workflow-coastal-hydrowaq

21. Examples within C-Scale - Tutorials
21
https://github.com/c-scale-community/c-scale-tutorial-eo-mqs https://github.com/c-scale-community/c-scale-tutorial-snakemake
• AGPL3.0
• Strong Copy-left license – enabling access to anyone to use and
modify – but restricting the license of any derivative & to make it
available from networked environments (servers)

22. Discussion – Sustainability of Open Source SW
• Open source needs to be managed.
• Cost Structure includes
• Infrastructure and Hosting
• Support – Including Training activities
• Maintainance including SW updates & bug fixing
• Management costs
• Community engagement & promotion
• Initial costs –covered by project – Partners need to plan for
sustainability
22

23. Discussion – Sustainability of Open Source SW
• Potential Revenue Streams can come from following Business
Models
• Support and Maintainance (against payment / subscription plan / service
contract / etc)
• Consulting ( e.g. integration/adaptation/ deployment of OSS into customers
systems )
• Dual Licensing ( code released under restrictive Open Source License “as
is”, but sold under commercial licensing terms.
• Software-as-a-Service (SaaS) / Platform-as-a-Service (PaaS). Often used
under cloud computing services – Access is enabled for users through the
cloud and revenue is based from subsciption fees or usage-based pricing
• External Funding – Government, Crowdfunding, Donations, etc
23

24. Conclusions
• Making Open Source Software available under Open Source
Licenses maximizes the chances for their up-take
• Choose appropriate license (Copyleft or Permissive)
depending on the exploitation strategy
24
Costs structure within C-Scale
• Infrastructure and Hosting – Codes Available in GitHub,
Infrastructure available under FedEarthData service
• Support – Including Training activities – Available from Project
Wiki
• Maintainance including SW updates & bug fixing – Depending
of future use & re-use or workflow components
• Management costs – Covered under follow-up projects
• Community engagement & promotion - Covered under follow-
up projects
Revenue models within C-Scale
• Support and Maintenance – of some specific
components
• Consulting - on demand
• Software-as-a-Service (SaaS) / Platform-as-
a-Service (PaaS) – under FedEarthData –
infrastructure providers offer
• External Funding – Under follow up projects
• Internal Funding – Key partners to cover the
basic management costs

25. Thank you for your attention.
This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101017529.
Copernicus - eoSC AnaLytics Engine
contact@c-scale.eu
https://c-scale.eu
@C_SCALE_EU
C-SCALE tutorial Licensing Open-Source Software | 26th May 2023 | Online
Xavier Salazar, EGI Foundation
xavier.salazar@egi.eu