C-SCALE Tutorial: Licensing Open Source Software
- 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
- 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