Challenges in Software Licensing

You can do IT. Entrepreneurship in IT and Maths Saarbrücken, 06 June 2018

Sigmar Lampe Counsel IP and Licensing European Patent and Trademark Attorney Technology Transfer Office University of Luxembourg

1 Outline

1. Defining software – what is it?

2. Intellectual property rights (IPR) in software

3. Free and open source software (FOSS) vs.

4. Software licence compliance

5. Licensing models

6. Examples

7. Take home messages

2 1. Defining software

3 Computer System

HARDWARE SOFTWARE (physical) (logial)

4 ASTP-Proton Annual Conference 2016 25 – 27 May, Copenhagen, Denmark

Software:Software: broad broad meaningmeaning Software: narrow meaning

Databases Data Databases Data

Graphic Graphic Document Document user user libraries libraries interface interface

Computer Software Computer Software … … programs (electronic) programs (electronic)

5

Elements of computer program

Functionality

Data files Preparatory Computer design work programs

Programming statements Algorithms IPR IN SOFTWARE Programming language

2 ASTP-Proton Annual Conference 2016 25 – 27 May, Copenhagen, Denmark

Software: broad meaning Software:Software: narrow narrow meaningmeaning

Databases Data Databases Data

Graphic Graphic Document Document user user libraries libraries interface interface

Computer Software Computer Software … … programs (electronic) programs (electronic)

6

Elements of computer program

Functionality

Data files Preparatory Computer design work programs

Programming statements Algorithms IPR IN SOFTWARE Programming language

2 ASTP-Proton Annual Conference 2016 25 – 27 May, Copenhagen, Denmark

Software: broad meaning Software: narrow meaning

Databases Data Databases Data

Graphic Graphic Document Document user user libraries libraries interface interface

Computer Software Computer Software … … programs (electronic) programs (electronic)

ElementsElements of of a computerComputer program Program

Functionality

Data files Preparatory Computer design work programs

Programming statements Algorithms IPR IN SOFTWARE Programming language

7

2 2. Intellectual property rights in software

8 ASTP-Proton Annual Conference 2016 25 – 27 May, Copenhagen, Denmark

IPRIPR inin elementselements of of computer computer program program Legal definition of computer program

• Usually not defined in legal acts, except: – US copyright law: A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. (17 U.S. Code § 101 – Definitions)

Source: European IPR Helpdesk. Fact Sheet. IPR management in software development. June Source: European IPR Helpdesk. FactSheet. IPR management in software development. June 2013 https://www.iprhelpdesk.eu/Fact-Sheet-IPR-Management-in-Software-Development2013 - http s:/ /www.i prh el pd es k.eu / Fact-Sheet-IPR-Management -in-Software-Development

9

Protected elements of a computer Protected vs non-protected elements program according to legal acts of software in court practice • TRIPS: Copyright Patent Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971) (TRIPS art 10 (1)) USA/Europe: USA: • Berne Convention: Preparatory design material Computer program „as such“ The expression “literary and artistic works” shall include every production Expression of programming statements USA/Europe: and/or instructions in the literary, scientific and artistic domain, whatever may be the mode or Computer program as part of form of its expression, such as books, pamphlets and other writings […] USA/Europe: (medical) devices (computer- (Berne Convention art 2 (1)) Ideas and principles which underlie any implemented inventions) element of a program, including those • Directive 2009/24/EC of the European Parliament and of the which underlie its interfaces Council Functionality USA/Europe: For the purpose of this Directive, the term ‘computer program’ shall Logic, algorithms Abstract ideas include programs in any form, including those which are incorporated Programming language Mathematical formulae into hardware. This term also includes preparatory design work leading Format of data files Natural phenomena to the development of a computer program provided that the nature of Database* Business methods the preparatory work is such that a computer program can result from it Graphic user interfaces, application Europe: at a later stage (Directive 2009/24/EC recital (7); see also art 1) programming interfaces* User manuals, guidelines, other Computer program „as such“ documentation*

3 Legal definition: “computer program”

Usually not defined in legal acts, except:

US copyright law:

• A “computer program” is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. (17 U.S. Code § 101 – Definitions)

10 Protected elements (legal acts) TRIPS, art. 10(1) (1971) Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention

Berne Convention, art. 2(1): The expression “literary and artistic works” shall include every production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression, such as books, pamphlets and other writings [...]

European “Software” Directive 2009/24/EC, recital (7), art. 1) For the purpose of this Directive, the term ‘computer program’ shall include programs in any form, including those which are incorporated into hardware. This term also includes preparatory design work leading to the development of a computer program

11 Protected vs. non-protected elements COPYRIGHT ≠ PATENT USA and Europe USA + Preparatory design material + Machine-transformation test + Expression of programming statements and/or instructions Europe – Ideas and principles which underlie + Further technical effect any element of a program, including – Computer program „as such“ those which underlie its interfaces – Functionality USA and Europe – Logic, algorithms + Computer program as part of devices – Programming language (computer-implemented inventions) – Format of data files – Abstract ideas – Graphic user interfaces, application – Mathematical formulae programming interfaces* – Natural phenomena – Database* – Business methods – User manuals, guidelines, other documentation* (* own law) 12 Forms of computer program

SOURCE CODE OBJECT CODE

13 Modular architecture

NEW CODE

PRE-EXISTING (UNMODIFIED) CODE MODIFIED PRE-EXISTING CODE

14 Multiple ownership

UNIVERSITY

OPEN-SOURCE SPIN-OFF COMMUNITY COMPANY

3RD PARTY COMMERCIAL PROVIDER

15 Multiple licences

F/OSS LICENCEF/OSS LICENCEF/OSS LICENCE

CUSTOMISED PROPRIETARYCUSTOMISED PROPRIETARYLICENCE LICENCE

3RD PARTY RD COMMERCIAL3 PARTY COMMERCIALLICENCE LICENCE

16 Software

Function (impact) Data Code Structure

Name Graphics

Software

!17 Software Protection

A brief review of IPRs relevant for software:

1. Patents

2. Copyright

3. Trademarks

4. Designs

5. Databases

18 A review of Industrial Property Rights (IPR) Legal right What for? How?

Application and Patents New technical inventions examination

Original creative or artistic Copyright Exists automatically forms

Distinctive identification of Use and/or Trade marks products or services registration

Registered External appearance Registration designs

Valuable information not Reasonable efforts to Trade secrets known to the public keep secret

19 Patent

• negative right = exclusivity • prevent others from • making • using • selling or offering for sale • importing • in countries for which the patent was granted • for a limited time (up to 20 years)

20 Requirements for a patent to be granted

The invention must

• be absolutely new on a worldwide basis

• involve an inventive step (not obvious to skilled person) and

• be susceptible to industrial application

Sufficiency of disclosure:

• the invention must be described in sufficient detail

• description must be comprehensible to a “person skilled in the

21 What can’t be protected?

PROGRAMS FOR COMPUTERS ! • However, could be patentable, unless it is a computer program “as such”

If the program is purely of abstract or intellectual character: • only non-technical aspects à no invention ✘ à no patent ✘

If the program implements a technical solution to a (technical) problem: • “computer-implemented invention” • see: novelty, inventive step à identify technical aspects à examine technical aspects of invention à patentable, if novelty and inventive step confirmed ✔ (❓ )

22 Computer implemented inventions: Examples

• control of machines or industrial processes • control of the internal processes in a computer • helps to use resources in a computer more efficiently, or increases its performance • increases the safety of the computer • makes a computer system easier to use • improves the transmission or storage of data • technical considerations were necessary • provides a device with new functionality computer program: patentable under certain conditions Attention - always required: novelty + inventive step!

23 Copyright

Negative right = exclusivity

Economic rights for author: • reproducing • modifying (software)

• distributing These rights are freely transferable or licensable, per country

Moral rights for author (moral interest) • modifying (literary/artistic works) • authorship

24 Copyright and Software

Traditional view (1960-1970): source code can be fixed in writing, but object code is virtual (in computer memory)

WIPO Copyright Treaty (WCT) 1996, Articles 4 and 5: Computer Programs • computer programs are protected under copyright as if literary works • despite the lack of ‘originality’ • whatever mode or form of their expression (source code, object code, …)

N.B. Copyright for Databases • compilations of data or other material are protected as a separate new work • in any form • if the selection or arrangement of their contents constitute intellectual creations • the data or material contained in the compilation may itself be protected

25 Trademarks

Exclusive right = exclusivity • distinctive signs associated with products or services offered • principle of speciality • principle of territoriality

• Potentially perpetual (renewal every ten years) • Risk of loss of protection if: • not used after five years • found to be invalid

26 Trademarks and Software

• brand is associated with the products or services offered

• choose the name of the software product or service

• minimise the likelihood of consumer confusion

• avoid resemblance with other trademarks

• should be inherently distinctive (non-descriptive)

• ensure the use in commerce:

• failure to use the trademark at all, or improperly using the trademark, may result in loss of the trademark registration.

27 Designs

• Negative right = exclusivity

• for aesthetic appearance only

• prevent others from

• making • using

• selling or offering for sale

• importing …products incorporating design

• Principle of territoriality

• Duration maximum 25 years

28 Design and Software

• copyright only protects the underlying code of a software application • copyright fails to protect the 'look and feel' of display on screen • Design right: for aesthetic appearance only! ➡ ideally suited to protecting digital images: • video game characters: • e.g. Lara Croft, star of the Tomb Raider games: control and license the use of Lara Croft's image in other media. • graphic icons: • design right protects icons in computer applications and mobile phones ➡ useful to protect new media and digital products.

29 Database

A database is a collection • of independent works, data or other materials • arranged in a systematic or methodical way • individually accessible by electronic or other means. • Directive 96/9/EC on the separate legal protection of databases (N.B. copyright protection of limited use for “living” databases) sui generis protection for databases: • contents • investment in production • maker • prevents others from extracting and/or re-using content

Computer programs are excluded (they are NOT databases) 30 Database Protection

Database rights are often overlooked because the rights arise: • not through the creation of new works • but through the collection and presentation of pre-existing independent works and materials. Examples: • customer lists • sales records • business contacts • extracts from research reports

• protected, when arranged in a systematic or methodical way so that they can be individually accessed

• these databases comprise ordinary information, but this does not impact the exclusive right to extract and reutilise the information

31 Ownership of IP rights

patent employer

literary works author

copyright software employer

database employer

trademark employer

design employer

32 Example:Example: PAGERANK ™

function [v] = rank2(M, d, v_quadratic_error)

N = size(M, 2); % N is equal to either dimension of M and the number of documents v = rand(N, 1); v = v ./ norm(v, 1); % This is now L1, not L2 last_v = ones(N, 1) * inf; PATENT (?) M_hat = (d .* M) + (((1 - d) / N) .* ones(N, N)); while(norm(v - last_v,COPYRIGHT 2) > v_quadratic_error) last_v = v; v = M_hat * v; % removed the L2 norm of the iterated PR end

end %function

Damping Factor d = ? TRADE SECRET!

Sorry, just math! 3. Free/Open-source vs proprietary licences

34 What is a license?

Latin “licere” = to allow, to permit allow an activity that would otherwise be forbidden may require paying a fee or proving certain capability

Government licenses: • Broadcasting licenses • Mobile phone operating licenses • Fishing licenses • Driving licenses

Licenses also between private parties = contract

35 Licences – why?

Commercial interest in exploiting IP rights? Remember: IP right-holder can prevent certain acts, unless authorisation is given.

➡ A licence is a legal contract between the parties: • right holder (licensor): grants allowance (licence) • interested party (licensee): receives allowance • may be with or without payment

Licence: • In intellectual property terms: "a promise by the licensor not to sue the licensee" • limited to particular IP right(s) • no freedom-to-operate w.r.t. other IP rights 36 What can be licensed?

• Trade secrets (know-how) • Patents • Copyright • Trademarks • Designs

Licensee can also grant privileges (sub-licence): • same privileges as enjoyed by holder of patent, trademark, copyright, etc. • may be more restricted • but never more permissive than those received (see e.g. GPL)

37 Express licence

Formal contract (i.e. signed) between two parties

Licence granted by certain (express) terms: • nature of the rights granted • kind of exploitation envisaged • Scope of field of exploitation • Place (worldwide?) and the duration of the exploitation

By default, in absence of writing, interpretation in favour of the right-holder: • particularly in countries which do not allow free granting of copyright! • hence the need for minimum licence clauses, even for

38 Implied licence

• Licence presumed to have been given based on certain behaviour of the party authorised to give it

• e.g. open source licences or

• Licence presumed to have been accepted based on certain behaviour of the party authorised to receive it

• shrink wrap licence

• click wrap agreement

39 Open-source and similar licences

Licence • you do not give away any of your rights • you still hold the IPR on your work • a license grants specific permissions for others to use your work

Open-source licences • based on intellectual property rights • easy for others to contribute without having to seek special permission • protect any original creator, making sure they at least get some credit • help to prevent others from claiming foreign original work as their own • are not necessarily “for free” (without payment) • (in theory) not limited to software/copyright 40 FREE SOFTWARE licences

4 essential user freedoms (, FSF):

(0) to run the program, for any use

(1) to study and change the program in source code form

(2) to redistribute exact copies, including the possibility to give away for free, or sell, the copies; and

(3) to distribute modified versions

Example: GNU General Public License (GPL) version 3

41 OPEN SOURCE licensing principles

Open source doesn't just mean free access to the source code: 1. Free Redistribution (original & derivative developments) 2. Source Code (availability) 3. Derived Works (allowance) 4. Integrity of The Author's Source Code (paternity) 5. No Discrimination Against Persons or Groups 6. No Discrimination Against Fields of Endeavour 7. Distribution of License (no NDAs) 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral

(from: opensource.org) 42 OPEN SOURCE: 70 licences (2015) Academic 3.0 (AFL-3.0) Frameworx License (Frameworx-1.0) Non-Profit Open 3.0 Affero GNU Public License: See "GNU Affero GNU Affero General Public License v3 (NPOSL-3.0) General Public License 3.0 (AGPL-3.0)" (AGPL-3.0) OCLC Research Public License 2.0 (OCLC-2.0) Adaptive Public License (APL-1.0) GNU General Public License version 2.0 Open Font License 1.1 (OFL-1.1) 2.0 (Apache-2.0) (GPL-2.0) Open Group Test Suite License (OGTSL) Apple Public Source License (APSL-2.0) GNU General Public License version 3.0 Open Software License 3.0 (OSL-3.0) 2.0 (Artistic-2.0) (GPL-3.0) PHP License 3.0 (PHP-3.0) Attribution Assurance Licenses (AAL) GNU Library or "Lesser" General Public The PostgreSQL License (PostgreSQL) BSD 3-Clause "New" or "Revised" License License version 2.1 (LGPL-2.1) Python License (Python-2.0) (overall Python (BSD-3-Clause) GNU Library or "Lesser" General Public license) BSD 2-Clause "Simplified" or "FreeBSD" License version 3.0 (LGPL-3.0) CNRI Python license (CNRI-Python) (CNRI License (BSD-2-Clause) Historical Permission Notice and Disclaimer portion of Python License) Boost Software License (BSL-1.0) (HPND) Q Public License (QPL-1.0) CeCILL License 2.1 (CECILL-2.1) IBM Public License 1.0 (IPL-1.0) RealNetworks Public Source License V1.0 Computer Associates Trusted Open Source IPA Font License (IPA) (RPSL-1.0) License 1.1 (CATOSL-1.1) ISC License (ISC) Reciprocal Public License 1.5 (RPL-1.5) Common Development and Distribution License LaTeX Project Public License 1.3c (LPPL-1.3c) Ricoh Source Code Public License (RSCPL) 1.0 (CDDL-1.0) Lucent Public License Version 1.02 (LPL-1.02) Simple Public License 2.0 (SimPL-2.0) Common Public Attribution License 1.0 MirOS Licence (MirOS) (Sleepycat) (CPAL-1.0) Microsoft Public License (MS-PL) Sun Public License 1.0 (SPL-1.0) CUA Office Public License Version 1.0 (CUA- Microsoft Reciprocal License (MS-RL) Sybase Open Watcom Public License 1.0 OPL-1.0) MIT license (MIT) (Watcom-1.0) EU DataGrid Software License (EUDatagrid) Motosoto License (Motosoto) University of Illinois/NCSA Open Source License Public License 1.0 (EPL-1.0) Public License 2.0 (MPL-2.0) (NCSA) Educational Community License, Version 2.0 Multics License (Multics) Universal Permissive License (UPL) (ECL-2.0) NASA Open Source Agreement 1.3 (NASA-1.3) Vovida Software License v. 1.0 (VSL-1.0) Eiffel Forum License V2.0 (EFL-2.0) NTP License (NTP) W3C License (W3C) Entessa Public License (Entessa) Naumen Public License (Naumen) wxWindows Library License (WXwindows) European Union Public License, Version 1.1 Nethack General Public License (NGPL) X.Net License (Xnet) (EUPL-1.1) Nokia Open Source License (Nokia) Zope Public License 2.0 (ZPL-2.0) Fair License (Fair) zlib/libpng license (Zlib)

43 Free/open source software vs Intellectual Property?

Free software / open source licences do not oppose intellectual property:

• minimum: copyright and author’s rights

Some licenses even comprise industrial property rights: • trademarks • patents (e.g. Apache)

➡ All free software / open source licenses are based on intellectual property. ➡ They respect and rely on it in order to achieve their goal.

44 The Licensing Spectrum

IP assets = exclusive rights

None Some All

Public Free / Open Source * Proprietary

Freeware / academic contextual reciprocal other Shareware

* strict definition!

45 Academic licences

Permissive licenses

• Under an academic license, the content may be re–licensed, even under a different licence (including proprietary licence)

• Obligation: attribution of authors

• Example: New BSD, MIT/X, Apache Advantages:

• facilitate distribution

• simple contracts Disadvantage:

• almost no control over the distribution

46 BSD Licence(s)

• a family of permissive free software licences

• fewer restrictions on distribution compared to other free software licences such as the GNU General Public Licence.

• New BSD Licence Simplified BSD licence (“3-clause licence”) (“2-clause licence”) • allows unlimited redistribution for any • allows unlimited redistribution for any purpose as long as purpose as long as 1. copyright notices are maintained 1. copyright notices are maintained 2. disclaimers of warranty are 2. disclaimers of warranty are maintained maintained 3. restricts using the names of • omits the non-endorsement clause (3.) contributors for endorsement of a derived work without specific permission

47 MIT Licence shortest and broadest of all popular open-source licences: “Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/ or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.” • you can use, copy and modify the software however you want • you can distribute the software in any way you see fit • the only restriction is that it be accompanied by this licence agreement

48 Apache Licence (version 2.0) can relate to both copyrights and patents (other open-source licences may relate only to copyright):

• perpetual • worldwide

• no fee or royalty

• non-exclusive

• irrevocable special requirements for redistribution:

• give proper credit to those who have worked on the code

• maintain the same license 49 Contextual licences

Particularly suitable for libraries • depends on the context of use • , if embedded • allows dynamic linking of library, without obligation to share alike • Example: GNU L-GPL v.X;

Principles • Advantages: • compatible with a multitude of strategies (including proprietary licensing) • Disadvantage: • technically complex (dynamic, not static linking)

50 GNU Lesser General Public Licence (LGPL)

Reasoning: • GPL requires that other software with parts of licensed code also be licensed under the GPL à developers cannot use GPL-licensed code for paid and proprietary software

Solution: • LGPL does not require other projects with parts of the code to be similarly licensed • grants fewer rights to a work than the standard GPL • is appropriate e.g. for libraries that want to allow linking from non-GPL and non-open-source software (e.g. glibc)

51 Reciprocal licences a.k.a. “Copyleft” licence

• Any development must be re-licensed under the identical license

• “viral effect” or “contamination”

• Example: (Affero) GNU GPL v.X; EUPL v.1.1

Advantages:

• secures the “common” goods Disadvantage:

• impact on distribution

• interoperability issues with other licenses

52 GNU General Public Licence (GPL)

One of the most commonly used licences for open-source projects

Guarantees a wide range of rights to developers working on open-source projects:

• copy the software as often as you want

• distribute the software however you want

• charge any/no fee to distribute the software

• make whatever modifications to the software you want

• the new source code must also be released under the GPL (COPYLEFT)

Attention: source and binaries distribution are two very different things.

To use the GPL, you include a copy of the licence in the software code

53 Strong COPYLEFT Licence

• FSF: “Copyleft is a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well.“

• Copyleft obliges derivative, extended and even combined works, to be licensed under the same terms as the original license.

Example: GPL v2 and GPL v3 ( kernel, WordPress, My SQL)

• not free to choose other licenses for extended, combined or derivative works based on GPL work

• GPL is a complex legal issue

54 4. Software licence compliance

55 ASTP-Proton Annual Conference 2016 25 – 27 May, Copenhagen, Denmark

Multi-source development model

FOSS VS PROPRIETARY LICENSES

Source: Ibrahim Haddad. Free and Open Source Software Compliance. The Basics You Must Kn ow. The , 2010 - pl eas e see th e exact li nk in th e no tes secti o n.

ImportanceImportance of of FOSS FOSS FOSS vs proprietary licenses

• Importance of F/OSS

Source: European IPR Helpdesk. Fact Sheet. IPR management in software development. June 2013 - https://www.iprhelpdesk.eu/Fact-Sheet-IPR-Management-in-Software-Development Source: Ibrahim Haddad. Open Source Compliance. – please see the exact link in the notes section. 56 Source: Ibrahim Haddad. Open Source Compliance. – please see the exact link in the notes section.

5 Free and Open Source Software Compliance: The Basics You Must Know

With time, companies started to incorporate FOSS into their platforms for the different advantages it offers such as technical merit, fast time-to-market and the ability to customize source code to own needs. The current most adopted development model is the multi-source development model (Figure 2). In this model, software components can consist of source code origination from different sources and licensed under different licenses; for instance, software component A can include proprietary source code in addition to 3rd party proprietary source code, while software component B can include proprietary source code in addition to source code from an open source project. Figure 2 highlights the combinations of incoming source code sources.

Following this model, the source code built into a product is incoming from various sources:

• Proprietary, developed by the company building the product or by one of its acquired subsidiaries

• 3rd party commercial, developed by 3rd party software providers and received by the company building the product under a commercial license

• FOSS, developed by the FOSS community and received by the company building the product under Multi-sourcea FOSS license development model

• A combination of any of the above sources

3rd Party Commercial + FOSS

3rd Party Commercial FOSS

Proprietary Proprietary + FOSS + 3rd Party Commercial

Proprietary + Integration Proprietary + FOSS 3rd Party Commercial + QA + Commercialization

Source: Ibrahim Haddad. Free and Open Source Software Compliance. The Basics You Must Know. Final Commercial Product The Linux Foundation, 2010 - please see the exact link in the notes section. 57 FIGURE 2. MULTI-SOURCE DEVELOPMENT MODEL

3 Aggregation of software components

Derivative works comprise a code modification Larger works comprise unmodified original software components

Example:

• pre-existing component A

• pre-existing component B

• Component C:

• modified version of A (derivative of A)

• merged with unmodified B (larger work of B)

Source: European IPR Helpdesk FactSheet. IPR management in software 58 development. June 2013 – please see the exact link in the notes section. Licence conflicts

F/OSS commercial / customised Licences ⚡ proprietary licences ⚡ proprietary licences

compatible licence compatible licence compatible licence √ √ √ 1 1 1

compatible licence compatible licence compatible licence √ √ √ 2 2 2

compatible licence compatible licence compatible licence √ √ √ 3 3 3

… … …

59 F/OSS Proprietary • Publicly available (code and licence) • Private or secret (code and/or licence)

• Non-negotiable (standard licence) • May be negotiable (customised license) • Can be freely run • Only authorised licensees may run • Can be freely studied • Cannot be studied without access to • Can be freely copied source • Can be freely modified • Reverse engineering and de- • Source code of modifications must be compilation back to source code made available upon external usually prohibited distribution • Copies prohibited or limited • May include “share alike”(“copyleft”): • Modifications prohibited or limited modifications must be shared under • same or equivalent licence Mostly for internal use only, distribution prohibited or limited • Can be freely distributed • Mostly distributed in object code form, • Source code must be kept available source code is kept secret

60 Licence conflicts within F/OSS due to “share alike“ = viral effect

GPL or compatible EPL or compatible EUPL or compatible licences ⚡ licences ⚡ licences

GPL compatible EPL compatible EUPL compatible √ √ √ licence 1 licence 1 licence 1

GPL compatible EPL compatible EUPL compatible √ √ √ licence 2 licence 2 licence 2

GPL compatible EPL compatible EUPL compatible √ √ √ licence 3 licence 3 licence 3

… … …

61 GNU General Public Eclipse Public Licence Licence (GPL) version 3.0 (EPL) version 1.0

• Strong “copyleft” • Weak “copyleft” • sufficient to provide reference to source • Source code has to be made available • distribution: sufficient to mention how to • Distribute together with the obtain the source code corresponding object code, only a few • Scope of modifications that need to be strict exceptions published and “shared alike” is narrower • Scope of modifications that need to be • “changes” – covered by EPL v1.0 published and “shared alike” are broader • derivative works” – not defined in the license (might include linking), but • “work based on the Program” (might covered by EPL v1.0; to be interpreted include derivatives, linking) covered by • “additions” = separate modules, which GPL v3.0 are not derivative work, not covered by • “aggregate” = compilation with “separate EPL v1.0 (e.g. Eclipse plug-ins without and independent works” (additions?), not modification) covered by GPL v3.0 • Sublicensing of source requires “share alike” • In case of sublicensing, both source and • Sublicensing of object code permitted object code form must be “shared alike” under proprietary license under GPL v3.0 • Laws of New York State, USA; • No governing law specified USA IP laws 62 How to overcome licence conflicts

• Replace with equivalent software under compatible license

• Change license for your own module, to comply with license of 3rd party

• Make your own module available under parallel licences:

• users can choose a suitable combination of software modules and the respective licences themselves

• Consider adding a specific permission in your FOSS license (e.g. GPL v3.0 section 7), allowing to run your module together with a 3rd party module despite conflicting licence terms (however, both licences have to allow special permissions to overcome conflicting terms)

• Use dynamic linking (less risky, but no guarantees!)

• Aggregate with unmodified 3rd party modules, instead of modifying (derivative work) and linking with them (aggregation <–> linking?)

63 Interoperability

Creating modifications can lead to difficulties in terms of interoperability of the licences

• legal compatibility of licenses is not automatic, on the contrary!

• need to respect and apply the rights and obligations contained in each and every licence used

Typical difficulties:

• territorial clauses

• IP clauses

• non-free use clauses

64 Interoperability

BSD L-GPL v2 GPL v2

Afero GPL MIT L-GPL v3 GPL v3 v3

– patents contextual reciprocal licence licence

Apache

licence original derivative academic possible licence based on: European IPR Helpdesk FactSheet. IPR management in software development. June 2013 – please see the exact link in the notes 65 section. Proprietary Licences

• usually, no access to source code

• no modifications allowed

• strict rules of use

Types of proprietary license: • licence to defined user

• workstation licence

• network licence (floating licence)

• site licence (geographic situation)

In practice, an (almost) unlimited number of tailor-made proprietary licenses

66 5. Licensing Models

67 End User Licence Agreement (EULA)

• is essentially a Software licence agreement • is not a “purchase” agreement! The software is not owned by the user. • contract between the licensor and the user • non-exclusive rights for user • right to use the software under copyright regulations / patent law • often only in digital form (click-through) which the user must "accept” • large businesses and government entities: • special agreements that include support contracts and warranties • private users: • usually almost total exclusion of liabilities and warranties • occasional attempts to control more than reasonably allowed under copyright / patent law • usually prohibits further distribution

68 Software Distribution Licence Agreement

• may be exclusive or non-exclusive, regional or worldwide • only distribution rights, not necessarily combined with use rights! Standard Distribution Agreement • distributing software as off-the-shelf product packaged by the vendor OEM Agreement • bundling a software program with another product (hardware/software) Corporate Distribution Agreement (volume licensing) • permits a large user to obtain many copies of software from the vendor Site Licensing Agreement • widespread distribution of software within a defined user community Development Agreement • rights to create derivative works of software program/documentation International Distribution Agreement On-Line Distribution Agreements • downloads, App Stores, etc.

69 Open Source Business Models licence and support for proprietary separating licence and support also software: in the open source world:

• • software licence fee (vendor) software freely available under FOSS

• additional chargeable • no licence cost / no revenue services such as support and consultancy • support contract or consultancy services from • also provided by third third party specialist parties

70 Dual-Licensing

• same piece of software can be made available under two (or more) different software licences:

• open source licence, e.g. GPL

• proprietary licence

• only the copyright-holder(s) can decide on this!

• the freedom to license may be limited by the use of FOSS in the piece of software

71 Dual-Licensing As A Business Model

Software is made available both under

• an open source licence

and

• a different licensing scheme that may incur a licence fee.

Example:

• open source code shall be re-used within proprietary software

• some open source licences do not allow this (strong copyleft)

• solution: offering a (paid) proprietary licence in parallel to open- source licence

72 Software as a Service

• classical licence: rights to copy and use a software application • service contract: recipient gets a service (tech support, IT consulting) • confusion due to central role of “software” in software as a service

What will the customer do with the software? • puts a copy of a software application on a computer—downloads it, installs it from a disk, etc.: copyright law ‣ traditional licence

• software remains on the provider’s computer • customer merely accesses via Internet (no copies, no copyright issue) ‣ service agreement —> Software as a Service !

Provider operates like an Internet service provider (ISP): • provides a subscription to service made possible through software

73 Software as a Service Agreement The customer obtains a subscription to a service, not a software license. IT maintenance: no need to provide it! Service level agreement (SLA): • time-frames for fixing errors • minimum performance standards—speed, latency, etc. IP Indemnities: • SaaS customers generally don’t risk suits about copyright infringement, including open source suits • the customer could get dragged into a patent suit, even without copying the software

Data Management & Security: • customer’s sensitive data stored on the provider’s computers • provider’s obligations for managing data and for keeping it secure

74 6. Examples

75 That’s it …

Thank you for your attention!

Questions?

• Invention: anomaly detection in multiple parameters 17 • IP: patent LU (positive) then WO; know-how • Application: smartphone as intelligent mobile sensor in vehicles Game of Roads • Proof-of-concept with support from FNR, software

▶ Safe Driving Campaign IP: copyright ▶ Launch Friday March 13th 2015 ▶ By September 2015 • First prototype client found ▷ > 5300 Users ▷ > 3.500.000 km driven ▶ Monthly Winners & Final (17/10) • Spin-off founded by researcher-inventors end 2014 ▶ Duration: 6 months Analytics Backend • Patent and know-how licence in the field Mobile App (iOS) • Prototype successfully launched in public: “Game More info: gameofroads.lu 14 of Roads” • BM: proprietary software and advanced analytics

76 7. Take home messages

77 What is it?

• Algorithm

• Research Tool

• Stand-alone Software

• App

• Game

• Database Who has contributed?

Software is usually developed and improved continuously, over long periods of time:

• many people may have contributed

• ownership might be fuzzy and difficult to establish

• programmer probably has most information, but probably does not oversee all potential risks

• does the institution/company actually own anything? Common Issues with Contribution

• “A group of students has written most of the code as part of their project” ➡ Have students assigned their rights to the Institution? • “I started this work whilst at another University” ➡ An inter-university agreement might be needed • “A colleague from another University gave the initial code to me to start with” ➡ An inter-university agreement might be needed • “An ex PhD student continued to contribute in his/her spare time after completion of his/her PhD” ➡ PhD students needs to assign rights to Institution Common Issues with Ownership

Creator Employee Student IP-Right (incl. PhD) (M and B) Patent Institution Student* Copyright Employee Student* Software Institution Student* Design Institution Student* Trademark Institution Student* Database Institution Student* *) unless assigned to the institution through separate written agreement (personal data) (subject) (subject)

The table depicts the situation in Luxembourg. Ownership of IP rights is subject to national law. Please check with competent legal counsel. IP Infringements – Patents

Software patents do exist!

• computer-implemented inventions

• technical or physical real-world effect

• e.g. Google PageRank

• in US more common than in EU

“According to Google Patents I am not infringing any patents”

• Use databases (Espacenet / WIPO) to check Freedom to Operate Use of Data

• Does the invention use Data in any way?

• How is the Data accessed?

➡ Is access to pre-existing databases required?

• Is Data being collected?

➡ Which legislation is applicable (e.g. GDPR)? Use of Databases

Databases can be protected – copyright (US) / sui generis (EU) • License might impose restriction on data use / re-use • Academic vs commercial use

• “I have only used Open Data from publicly available databases” ➡ Check conditions for (commercial) use

• “I have written an algorithm to extract data from an existing database and to include this into my own database” ➡ Consent from the Database owner is probably needed Use of (personal/user) Data

Must comply with General Data Protection Regulation (EU 2016/679): • Data must be processed fairly and lawfully and must be collected for explicit and legitimate purposes and used accordingly. • Data must be relevant and not excessive in relation to the purpose for which they are processed. • Data must be accurate and where necessary, kept up to date. • Data controllers are required to provide reasonable measures for data subjects to rectify, erase or block incorrect data about them. • Data that identify individuals must not be kept longer than necessary. • Member States must provide one or more supervisory authorities to monitor the application of the directive. • In principle, all data controllers must notify supervisory authorities when they process data. Use of Personal Health Data

Due to the sensitive nature, health data, as a principle, should not be processed, unless the data subject gives his/her explicit consent. • Check that patient has given consent compliant with legislation

• Electronic Health Records • access controlled by health care provider

• Personal Health Records • access controlled by patient Open Source

Have any open source elements been used? • programmers should be able to tell you • use independent audit service, e.g. Black Duck, FOSSA, etc.

For each open source element, need to check: • type of license • compatibility with intended commercial use

If not compatible: • are alternative open source elements available? • can Open Source elements be replaced by own code? • take into account additional time and budget for rewriting Open Source – Checks

Academic vs commercial proprietary licenses (e.g. “MatLab”)

• for research/teaching use only

• commercial use restricted

“Viral” open source elements

• some licenses require derivatives to be made available under the same license conditions (“copyleft”)

• e.g.: General Public License (GPL) Quality of Software

Initial algorithms usually intended for research only: • academic language may be incompatible with industry standards • no neat/consistent annotations or documentation of what components do • can only be used by academics themselves • contains bugs

“We use this code all the time in our research and in our hands it works fine; even our students are able to use it” • be sceptical of the quality Quality of Software

To be commercially used, software needs to be • well documented • easy to understand by other software specialists • work independently, without the input from the academic • debugged extensively

“We used MatLab/Mathematica to write and test the code” • a lengthy and costly development track might be needed to further develop the software before it is of commercial value • academics might not be up for this Consortium for IT Software Quality (CISQ) Model

• measures the level of risk and the likelihood of RELIABILITY potential failures resiliency and • also: modifications made to the software (its structural solidity "stability”) • source code and software architecture ensure high performance EFFICIENCY • important for high execution speed environments where performance and scalability are paramount. SECURITY • poor coding practices and architecture likelihood of security • quantifies the risk of encountering critical breaches vulnerabilities that damage the business • a must for mission-critical applications MAINTAINABILITY • change is driven by tight schedules adaptability, portability • important for IT to remain responsive and transferability • keep maintenance costs under control • directly impacts maintainability SIZE • assess amount of work produced / to be done Version Control

Where and how is the source code stored? • on a server, a USB stick…?

Is there a clear documentation of what is included in the different versions of the Software?

Which version are you actually licensing?

“We don’t really keep track of versions. We just keep adding to the source code” • keeping well-documented copies of different versions is advisable First Checks

• What are we dealing with?

• Who has contributed?

• IP infringements / Freedom-to-operate?

• Is protected data used?

• Have any open source elements been used?

• What is the quality of the software?

• Version Control! Good practice (1)

Understand the ecosystem you’re operating in: • The licensing strategy needs to be as dynamic as the field of activity A computer program is more than a few lines of code: • Graphics • User manuals • Icons • Functions • Data structures Licenses for each/all of these? • Choosing a particular license goes further than technical aspects • The license chosen has an impact on the exploitation 94 Good practice (2)

Licensing-In keep track of third-party components; manage their compatibility

• listing of compatible licenses

• listing of third-party components:

• type of license; author; source it was obtained from; date

Licensing-Out audit your own source code

• verify compliance with pre-existing obligations (e.g. in- licenses)

95 Avoiding frequent mistakes

• Promote awareness of FOSS • Provide adequate training about FOSS • Require employees to inform about use/modification/distribution of FOSS in their projects (FOSS request), i.e. no use of FOSS allowed without prior approval • Introduce an Open Source Review Board (OSRB) to: • approve/reject FOSS requests • define and manage your FOSS strategy

• Regularly scan and audit source code in your code base to discover new FOSS elements or modifications of FOSS elements and other licence in-compliance (e.g. proper attribution/license/copyright/modification notices, making source code available where required by FOSS licenses) • Regularly run a dependency tracking tool to verify linkages between software modules (to map potential derivative works covered by FOSS licenses)

• Create compliance check-list for software development and release procedures (e.g. final inspection of source code license compatibility before release)

Based on: Ibrahim Haddad, “Free and Open Source Software Compliance. The Basics You Must Know.” The Linux Foundation, June 2010. http://www.linuxfoundation.org/publications/compliance/compliance-the-basics-you-must-know

96 Helpful tools and materials Fossology: http://www.fossology.org/projects/fossology Black Duck Hub: https://www2.blackducksoftware.com/products/hub FOSSA: https://fossa.io Linux Open Compliance Program: http://www.linuxfoundation.org/programs/legal/compliance • Dependency Checker (http://www.linuxfoundation.org/programs/legal/compliance/tools) • Self-Assessment Checklist (http://www.linuxfoundation.org/programs/legal/compliance/self- assessment-checklist) • Generic FOSS policy http://www.linuxfoundation.org/publications/compliance/generic-foss-policy Free Software Foundation - Compliance section: http://www.fsf.org/licensing/compliance Working Paper on the legal implication of certain forms of Software Interactions (a.k.a. linking) (2010): https://informatiecentrum.clinic.nl/wp-content/uploads/LinkingDocument.pdf Software Freedom Law Center: http://www.softwarefreedom.org/ • Guidelines for management of copyright notices and permissions: http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html International Free and Open Source Software Law Review: http://www.ifosslr.org/ • M. Bain, “Software Interactions and the GNU General Public License” (2010) DOI: http://www.ifosslr.org/public/ifosslr-v2i2.pdf (page 165) IPR Helpdesk: https://www.iprhelpdesk.eu • FactSheet. IPR management in software development. June 2013 https://www.iprhelpdesk.eu/Fact-Sheet-IPR-Management-in-Software-Development

97 Summary

• properly identify all elements of “software”

• various intellectual property rights in one “software” project

• differences between FOSS vs. proprietary software

• ensure software license compliance, especially w.r.t. FOSS

• select an appropriate licensing model

98 Questions?

Sigmar Lampe Counsel IP and Licensing Knowledge and Technology Transfer Office University of Luxembourg Campus Belval 6, avenue de la Fonte L-4364 Esch-sur-Alzette [email protected]

99