Verslag EUPL verklarende text

Dit document bevat input over de EUPL-licentie.

Inhoudsopgave

Inhoudsopgave
Inleiding
Achtergrond
GIBIT 25/26 en Open Source
Citaten
Stukken in ontwikkeling
Bronnen
- Voorlopige analyse voor OpenZaak (niet juridisch)

Inleiding

Omdat er onduidelijkheid bestaat over Intellectueel Eigendom bij het laten ontwikkelen van Open Source Software en de rol van de licentie daarbij, maken we hier een kort overzicht van de belangrijkste punten. Let op dat dit geen juridisch advies is, maar een samenvatting van de huidige stand van zaken, die in beweging zijn.

Hoog over adviseren wij om deze vraag bij de Open Source Program Officer van Common Ground neer te leggen voor een formele juridische check, en de ontwikkeling van de GIBIT 25/26 nauwlettend te volgen.

Achtergrond

“Wanneer publieke organisaties aanbesteden, dan doen ze dat vrijwel altijd met behulp van standaard inkoopvoorwaarden. […] Bij gemeenten is dat de GIBIT. In het geval van maatwerk, stellen deze inkoopvoorwaarden, moet het intellectueel eigendom worden overgedragen aan de opdrachtgever. De opdrachtgever wordt daarmee juridisch eigenaar van het ontwikkelde product. De achterliggende reden om juridisch eigenaar te willen zijn van een product, is dat je niet beperkt wordt in de doorontwikkeling ervan. Leveranciers hebben door de overdracht van intellectueel eigendom geen mogelijkheden om doorontwikkeling te belemmeren.

Wanneer broncode zonder opensourcelicentie beschikbaar wordt gesteld [door een overheid, red.], dan zijn er volgens artikel 15b [van de auteurswet, red.] geen enkele belemmeringen in het gebruik ervan. Waarmee ook niet afgedwongen kan worden dat de doorontwikkeling van de broncode open source moet blijven. Vanuit open source licenties bekeken zou dit vergelijkbaar zijn met de BSD0*.” [1]

* Zie ook https://en.wikipedia.org/wiki/Public-domain-equivalent_license

GIBIT 25/26 en Open Source

In de GIBIT 25/26 2 (in ontwikkeling) wordt Open Source Software expliciet benoemd in de artikelen 40 tot en met 46. Hieronder een samenvatting van de belangrijkste punten:

Maatwerkprogrammatuur wordt standaard als Open Source ter beschikking gesteld, tenzij expliciet anders is afgesproken (art. 40).
Open Source Programmatuur is altijd Maatwerkprogrammatuur, en het intellectueel eigendom komt toe aan de Opdrachtgever (art. 41).
Oplevering van de Open Source Programmatuur geschiedt onvoorwaardelijk door publicatie op een repository (art. 41).
De leverancier dient volledig gerechtigd en in staat te zijn om de Programmatuur te publiceren (art. 41).
De publicatie van de Open Source-programmatuur geschiedt op een platform zoals GitHub, GitLab, of Bitbucket (art. 42).
De leverancier mag niet zonder toestemming van de opdrachtgever de Open Source-programmatuur publiceren (art. 42).
De Programmatuur wordt in beginsel onder de European Union Public Licence (EUPL) beschikbaar gesteld (art. 43), tenzij anders is afgesproken, in welk geval er geen gebruik worden gemaakt van open source-programmatuur met viraal effect/copyleft (art. 41).
Ter beschikkingstellen van de programmatuur is inbegrepen in de vergoeding, maar aanvullende taken niet (art. 45).
Correctief en Innovatief Onderhoud op de Open Source-programmatuur is mogelijk, met een doorslaggevende stem voor de opdrachtgever bij prioritering (art. 44); leverancier hoeft dit niet gratis aan te bieden.
Updates en Upgrades van Open Source-programmatuur dienen ook open source gepubliceerd te worden (art. 44).
Vroegtijdige beëindiging van de overeenkomst is geen reden om publicatie van de programmatuur achterwege te laten (art. 46).

Citaten

“Wat zijn redenen om te kiezen voor intellectueel eigendom in plaats van voor een open source licentie? De aanwezigen waren eensgezind dat de bepaling over intellectueel eigendom eigenlijk voortkomt uit oud denken, en niet het beste juridische middel is om de gewenste doelen te bereiken. Een open source licentie verplicht stellen op maatwerk is effectiever.” 3

“Tijdens de aanbesteding viel op dat we met elkaar een opgave hebben in hoe we vanuit aanbestedingsrecht kijken naar intellectueel eigendom in relatie tot open source. Volgens de meeste standaard inkoopvoorwaarden in de publieke sector komt bij maatwerkaanbestedingen het intellectueel eigendom standaard bij de opdrachtgever te liggen. Zo wordt de opdrachtgever niet belemmert bij de doorontwikkeling van dat maatwerk. Nadeel is alleen dat verder niemand iets met die broncode kan zonder toestemming van die opdrachtgever. Het biedt allerlei voordelen om die intellectueel eigendomsbepaling te vervangen of aanvullen door een opensource-licentie. Je wordt als opdrachtgever niet belemmerd in de doorontwikkeling van het maatwerk en derden – inclusief de opdrachtnemer – krijgen de mogelijkheid om de broncode ook (commercieel) te hergebruiken naar eigen inzicht. De broncode die met publiek geld is ontwikkeld kan daarmee aanvullend renderen én de leverancier heeft een prikkel om de broncode zo goed mogelijk voor hergebruik te ontwikkelen. Makkelijk te hergebruiken broncode is ook makkelijker te doorontwikkelen, wat weer een voordeel is voor de opdrachtgever.” 4

“Denk dat ik al in 2008 heb geschreven dat de overheid als opdrachtgever kan kiezen tussen overdracht van auteursrechten, of in plaats daarvan levering onder de EUPL. Daaruit volgt dat overdracht inderdaad niet perse nodig is. Terzijde: die beoogde wetswijziging van de Auteurswet gaat volgens mij vooral over het werkgeversauteursrecht, en niet over de overdracht waar wij het nu over hebben. Daarvoor blijft namelijk, net zoals nu het geval is, een schriftelijke en specifieke overdracht noodzakelijk. De enkele vermelding ervan in algemene voorwaarden wordt is en was onvoldoende om de overdracht ook daadwerkelijk te effectueren.”. - Matthieu Paapst, expert Open Source en Intellectueel Eigendom.

“Voor de delen van de code waar je zelf de IE-rechten van bezit, kun je altijd nog van licentie wisselen. Zodra de code echter is vermengd met bijdragen van derden, zit je vast aan de voorwaarden waaronder zij hun bijdrage hebben geleverd. Een licentiewijziging kan dan alleen met hun toestemming. Let er ook op dat een licentiewijziging van een module gevolgen kan hebben voor de licentie van het project als geheel. Zo kan een project als geheel niet langer onder de EUPL blijven, wanneer een losse module van MIT naar GPL wijzigt – althans niet meer in combinatie met die specifieke versie van de module.” 5

Stukken in ontwikkeling

In ontwikkeling en wordt gecheckt door jurist, mogelijk/hopelijk daarna naar BZK gebracht als advies/standaardtekst: https://hackmd.io/xKaPXWp9RxWZP20OnePz2g

Bronnen

Voorlopige analyse voor OpenZaak (niet juridisch)

Indien het maatwerk is ontstaan onder GIBIT, dan is volgens de GIBIT het IE bij de (toenmalige) opdrachtgever, met de kanttekening van Matthieu Paapst dat algemene voorwaarden niet voldoende zijn voor overdracht; dat moet expliciet gebeuren in de overeenkomst
Indien EUPL licentie vanaf het begin is afgesproken, dan zijn alle bijdragen onder die licentie gedaan
De EUPL licentie geeft iedereen (waaronder de opdrachtgever) het recht om de software te gebruiken, te wijzigen, te verspreiden, en afgeleide werken te maken (en dus door te (laten) ontwikkelen), mits de voorwaarden van de licentie worden nageleefd
Intellectueel eigendom noch licentie zegt iets over de beschikbaarheid van de broncode; zorg voor een (openbare) kopie van de broncode
Zaken als merkregistratie en domeinnaam zijn los van IE/licentie; regel die apart

Laat dit formeel checken door een jurist (wij zijn dat niet)