Geldt een OSS licentie ook voor de data in de repository?

Een lezer tipte me over een interessante discussie bij het ChirpStack project. Een project waar men gebruik van maakte, The Things Network’s Device Repository, bleek niet meer importeerbaar, waarbij men zich beriep op databankrechten voor die data en tevens aangaf dat de opensourcelicentie op hun software niet zou gelden voor deze data. Toevallig was de licentie ook net een uur eerder weggehaald, wat erg raar aandoet. Wat is hier aan de hand?

Die repository is deel van The Things Network, “a global collaborative Internet of Things ecosystem that creates networks, devices and solutions using LoRaWAN®.” Dat laatste is dan weer een netwerkarchitectuur, maar daar hoeft het verder niet over te gaan. De kern is dat TTN een device repository heeft, een databank met belangrijke technische informatie over apparaten die op dit IoT-ecosysteem aan te sluiten zijn. En omdat er fors wat inspanning is gaan zitten in die repository, en The Things Industries (dat daarachter zit) een Nederlands bedrijf is dat het financiële risico draagt voor al die inspanningen, kan zij daar een databankrecht op claimen.

ChirpStack biedt net als TTN een open-source LoRaWAN Network Server aan. Inlezen van die repository is dan erg handig, maar dat maakte TTN recent onmogelijk onder verwijzing naar twee argumenten. Allereerst zou haar databankrecht worden geschonden, en ten tweede ging het importeren uit van een technische structuur die binnenkort zou veranderen, dus het zou alleen maar onhandig zijn voor de toekomst om dit te laten staan.

De beheerder van ChirpStack snapte van dat eerste niets: hij haalde de informatie uit het project op Github dat TTN zelf actief heeft. Daar stond (tot voor kort) een Apache licentie boven, een simpele OSS licentie die alles toestaat zonder copyleft-eisen of andere ingewikkelde dingen. En dan kun je wel een databankrecht hebben, maar licentie is licentie. De reactie van TTN:

There is and was no open data license on the concerning repository. We spend a lot of time and resources on the content of that database. In this instance, GitHub is a great channel to receive contributions from the device maker community and to contribute ourselves, verify, review and validate. But a GitHub repository doesn’t provide a license to reuse and extract it in its entirety. Sure, if you want to copy paste a payload codec that you are missing from the Device Repository, that is fine.
Oftewel: die licentie geldt alleen voor de software, niet voor de data. Dat vind ik raar in het algemeen. Het gebruik is dat je op sites als Github één licentie kiest, die dan voor alles geldt. (Of in ieder geval in de directory en daaronder van de plek waar je die neerzet.) Uitzonderingen kunnen, maar die documenteer je dan in de LICENSE file. Dat is hier niet gebeurd. Vroeger was er wel kritiek dat OSS licenties te specifiek op software geschreven waren, maar bij de Apache 2.0 licentie kun je dat moeilijk volhouden. De definitie van ‘werk’ is keurig generiek:
“Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
Hiermee is het dus volkomen logisch dat ook databestanden als ‘work’ kunnen worden aangemerkt, zodat de rechten en plichten uit de Apache licentie gewoon gelden voor afnemers van die databestanden. Althans, als de licentie daarop van toepassing is. Want tegenover wat ik hierboven schetst, staat dat men in de README (die iedereen ook geacht wordt te lezen) een beperkte verklaring had staan:
The API is distributed under Apache License, Version 2.0. See LICENSE for more information.
De bedoeling van deze software was namelijk dat je voor een gegeven stuk hardware de informatie opvraagt, met die aangeboden API. Wat ChirpStack deed, was dus niet helemaal hun bedoeling: zij maakten een kopie van alle data zodat je niet steeds via de API deze op hoefde te vragen. Die API is er alleen nooit van gekomen, het werd ‘gewoon’ software met alle data in die repository beschikbaar. Dat maakt de term “The API” onduidelijk, als die API er niet is wat bedoelde men dan wel?

Ik denk dat je dan toch uitkomt bij “alles op deze site”, omdat dat nu eenmaal de meest voor de hand liggende interpretatie is gezien het gebruik in de softwarewereld. Bijgevolg kan TTN dus het gebruik van de data niet verbieden mits dat binnen de regels van de Apache licentie gebeurt. Daar staat dan weer tegenover dat de Apache licentie heel expliciet alleen over “copyright” en “patent” toestemming spreekt, en dus niets over databankrechten. In die lezing heb je dus nog steeds niets.

Daartegen heb ik dan alleen nog het argument dat in die situatie de genoemde licentie vrijwel geen betekenis heeft, want er is verder niets van waarde onder die licentie te krijgen en dat is raar. Als je daarbij optelt dat die licentie door Amerikaanse juristen is geschreven (waar databankrecht niet bestaat) en dus best om die reden genegeerd kan zijn, dan kom ik bij de conclusie dat deze overname gewoon mag.

Arnoud

5 reacties

  1. Een houder van IE rechten mag – met werking voor de toekomstige aspirant licentienemers – een licentie wijzigen of intrekken. Dus, voor wat betreft de situatie na het verwijderen van de Apache licentie geldt dat er geen licentie meer is. Dan restert de vraag wat geldt voor al verleende licenties op dingen die al gedownload waren voordat de licentie werd ingetrokken. De Apache licentie is “irrevocable”, dus die blijft gelden. Hoewel de IE houder zich hier beroept op een IE recht dat niet genoemd is in de Apache licentie, denk ik dat je gelijk hebt dat gelet op het totaal van de verstrekte informatie, het een goed verdedigbare interpretatie is dat ook het databankrecht gelicentieerd werd. Dat databank recht bestaat alleen in de EU. Dus buiten de EU geldt hooguit het copyright, mits aan de voorwaarden daarvan is voldaan (voldoende originaliteit in de “selection or arrangement” van de databank). Als aan die voorwaarden niet is voldaan, geldt er geen copyright en is ook geen licentie nodig.

  2. Er zijn genoeg projecten waarbij “the API” bestaat uit “doe een wget naar een bestand op de mothership-site van de ontwikkelaar”. Hun enige onhandigheid is dan dat ze dat niet duidelijk hebben verwoord en/of het bestand buiten de Github repo hebben geplaatst.

    Wat ik verder nog interessant vind is dat er in de discussie verwezen wordt naar de CLA om derde partijen uit te sluiten (emphasis mine)

    We respect device maker’s own copyright on their photos, device profiles, codecs etc. Some codecs have their own copyright header, which is fine. For us, to be able to use their data, we require contributors to sign the CLA. That gives us, and not third parties, the rights to use their information.
    Die CLA zegt echter dat ook derde partijen gebruiksrechten verkrijgen (emphasis mine):
    …You grant to the Projects’ maintainers, contributors, users and to The Things Network Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your contributions and such derivative works. Except for this license, You reserve all rights, title, and interest in your contributions

    Ik ben niet zo’n fan van CLA’s en ik snap nooit helemaal goed hoe ze werken. Wat als ik een bijdrage doe onder een CLA en die bijdrage bevat ook code van iemand anders? Ben ik dan ueberhaupt gerechtigd die CLA te tekenen?

    1. Die vraag kun je alleen beantwoorden door de tekst van de CLA door gte lezen. Het kan, vaak staat er “je geeft een licentie op de code die jij gemaakt hebt”, en dan gaat het goed met code van derden. Als er staat “je garandeert dat alles dat je uploadt, door jou gemaakt is” dan gaat het dus mis.

      Helaas is er ook in OSS land nog steeds geen enkele prikkel om standaard CLA’s te maken. Ieder project vindt het wiel opnieuw uit…

      1. Duidelijk, dank. Overigens gebruikt deze specifieke CLA een tussenvorm die zegt “het is jouw code of je hebt code van derden en je zegt maar even erbij welke code dat is – voorzover je dat zelf doorhebt”

        Maar dat terzijde.

        Nu hebben we hier dus de situatie dat een uploader die de CLA tekent dat heeft gedaan onder de veronderstelling dat hij zo’n beetje iedereen (“maintainers, contributors, users”) een licentie heeft verschaft en dat de CLA-verstrekker dat ineens tegenspreekt (“That gives us, and not third parties, the rights”). En dan?

        1. Goeie vraag. In de licentie staat niets over wanprestatie. Terugvallend op Nederlands recht zou ik ook niet weten of dit wel wanprestatie is, als B een contract met A heeft en tegen C zegt dat C daar niets mee kan. In ieder geval zou C op goede grond kunnen zeggen, ik lees die CLA anders en ik heb wél direct een licentie van A dus je kan de boom in. En omdat B geen auteursrecht heeft (alleen een licentie van A) kan hij niet procederen tegen de beweerdelijke inbreuk op de rechten van A.

          Voor het databankrecht ligt dat anders. Volgens de wet ligt dat recht bij de producent, de partij die het financiële risico draagt. Dat zal dus die stichting zijn of het bedrijf dat daarmee samenhangt. Iemand die een brokje data levert voor in de databank, heeft daarmee geen rechten op de databank. Behalve eventuele auteursrechten op het brokje, maar specifiek bij dit soort feitelijke informatie zie ik dat niet. Dus al die mensen die keurig doorgeven wat hun apparaatje doet (puur feitelijk) kunnen niets claimen over het databankrecht en hoe dat uitgeoefend wordt.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.