Llicències de programari de codi obert segons la legislació neerlandesa i de la UE

Gairebé tots els productes de programari comercial contenen components de codi obert, normalment centenars, escollits pels desenvolupadors en lloc d'advocats. Això esdevé un problema quan ningú pot dir quines llicències s'apliquen, què requereixen i si el producte compleix les normes. Aquest article explica com funcionen les llicències de codi obert segons la legislació neerlandesa i de la UE, on rau el risc i què cal tenir en compte.

Què és una llicència de codi obert, en termes legals

Una llicència de codi obert és una llicència de drets d'autor atorgada subjecta a condicions. No és una renúncia, ni una dedicació al domini públic, ni un abandonament de drets. L'autor conserva els drets d'autor en virtut de l'art. 1 Aw i l'art. 10 Aw, que protegeixen els programes d'ordinador com a obres, i la llicència permet actes que d'altra manera infringirien els drets exclusius en virtut de l'art. 12 Aw i l'art. 13 Aw.

La conseqüència importa més que la definició. Si compleixes, la teva còpia i distribució són legals. Si no compleixes, el permís no cobreix el que has fet: el teu ús és una infracció dels drets d'autor, no un incompliment del contracte. La majoria de llicències de copyleft reforcen això rescindint automàticament en cas d'incompliment: la GPLv2 sense cap període de correcció, mentre que la GPLv3 i l'AGPLv3 restableixen els drets si l'incompliment es corregeix dins d'un període definit després de la notificació.

Els tribunals neerlandesos apliquen aquest raonament. A Rb. Amsterdam 22 de setembre de 2020, ECLI:NL:RBAMS:2020:4717, es va considerar que un distribuïdor que havia eliminat el text de la llicència i l'avís de drets d'autor d'una base de codi bifurcada havia perdut el seu permís i que infringia els drets d'autor. Afegir un gran volum de codi nou no creava una obra independent: l'original continuava present de manera recognoscible, de manera que les obligacions viatjaven amb ell.

Les dues famílies: permissives i amb copyleft

Les llicències permissives (MIT, les llicències BSD, Apache 2.0) permeten l'ús, la modificació i la redistribució, fins i tot dins de productes de codi tancat, sempre que es conservin els avisos de drets d'autor i el text de la llicència.

Les llicències de copyright requereixen que quan distribuïu el programari, o alguna cosa basada en ell, ho feu sota la mateixa llicència i poseu a disposició el codi font corresponent. Difereixen en abast.

El disparador del copyleft i la pregunta d'enllaç

Les obligacions de copyright afecta la distribució, no l'ús. Una empresa que executa programari GPL internament, per molt modificat que sigui, no distribueix res ni deu res. "Hem distribuït?" és sempre la primera pregunta, i és per això que els contenidors, els dispositius, el firmware i els SDK importen més que les eines internes.

La segona pregunta és més difícil. La GPL parla d'una "obra basada en el programa", prenent prestat el concepte americà d'obra derivada. La legislació neerlandesa no té aquest terme: l'anàlisi passa pels drets de reproducció i adaptació, preguntant si s'ha reproduït l'expressió protegida de l'original.

El cas pràctic és l'enllaç. Mai un tribunal neerlandès ha decidit si enllaçar un mòdul propietari a una biblioteca GPL crea una obra subjecta a copyleft, i no hi ha cap autoritat vinculant de la UE. L'opinió de la Free Software Foundation que l'enllaç crea una obra combinada és la interpretació de l'administrador de la llicència, no la llei, i l'opinió contrària tampoc està provada. La resposta preferida d'Internet (l'enllaç dinàmic és segur, l'enllaç estàtic no) no té cap base en la llei de drets d'autor neerlandesa, que no pregunta com es comporta un compilador. Una anàlisi més defensable pregunta amb quina intensitat es combinen els components: comparteixen un espai d'adreces i estructures de dades, la combinació s'envia com un sol producte, podria funcionar sol, el costat propietari reprodueix capçaleres, macros o codi en línia des del costat copyleft? Aquestes preguntes solen resoldre el risc. Quan no ho fan, aïlleu el component darrere d'un límit de procés, substituïu-lo o obteniu una llicència comercial.

AGPL i ús de xarxa

L'AGPL existeix perquè el copyleft s'activa mitjançant la distribució i els proveïdors de SaaS no distribueixen. La seva clàusula de xarxa exigeix ​​que si modifiqueu el programari i el poseu a disposició dels usuaris que hi interactuen de forma remota, els oferiu el codi font corresponent de la vostra versió modificada.

Sovint es passen per alt tres punts. L'obligació recau sobre els usuaris del servei, cosa que en un producte de registre obert no és gaire consol. S'activa per modificació, de manera que un component sense modificar no l'activa, però una compilació amb pegats sí que ho fa. I planteja la mateixa qüestió de treball combinat que la GPL per a la resta del vostre codi, motiu pel qual moltes empreses prohibeixen l'AGPL en el codi de producció.

Compatibilitat de llicències

La compatibilitat és el problema de combinar components les llicències dels quals imposen obligacions que no es poden complir en una sola distribució: les llicències permissives són compatibles amb gairebé tot, les llicències copyleft només amb allò que permeten els seus propis termes. El cas estàndard és Apache 2.0 i GPLv2. L'Apache Software Foundation i la Free Software Foundation coincideixen que la combinació no està permesa, perquè les disposicions de terminació de patents i indemnització d'Apache 2.0 són restriccions addicionals que la GPLv2 no permet. La GPLv3 es va redactar per acceptar-les. La compatibilitat també és direccional: el codi Apache es pot absorbir en un projecte GPLv3, però no a l'inrevés. Un component GPL al lloc equivocat pot forçar a triar entre tornar a concedir la llicència, la reenginyeria o l'eliminació, molt més barat abans del llançament que després.

Obligacions d'atribució i notificació

Les obligacions que s'incompleixen amb més freqüència són les menys dramàtiques: reproduir avisos de drets d'autor, textos de llicència, exempcions de responsabilitat i, amb Apache 2.0, continguts d'AVÍS en els materials que acompanyen la distribució. Totes les famílies les imposen, inclosos el MIT i el BSD. S'incompleixen perquè ningú no en és propietari i són les més fàcils de solucionar, normalment amb un fitxer d'atribució generat que s'envia amb el producte. El cas holandès anterior es va centrar exactament en aquest error.

Concessió de patents i represàlies per patents

El MIT i el BSD no diuen res sobre les patents, i no està clar si una llicència de patent pot ser implícita. Apache 2.0 va afegir una llicència de patent expressa i lliure de drets d'autor per a cada col·laborador, juntament amb una clàusula de represàlia: si es presenta un litigi de patents al·legant que l'obra infringeix la llicència, la llicència de patent finalitza. La GPLv3 conté una concessió comparable i les seves pròpies disposicions de patents.

Dues implicacions per a les empreses amb carteres de patents. Si els vostres enginyers contribueixen a projectes amb llicència Apache o GPLv3, esteu atorgant llicències sota les vostres pròpies patents. I si mai reclameu patents contra una empresa que depenen dels mateixos components amb llicència Apache que feu servir, les represàlies us poden costar una llicència en què confieu.

L'EUPL i el sector públic neerlandès

La Llicència Pública de la Unió Europea versió 1.2, aprovada per la Comissió Europea mitjançant una decisió d'execució el maig de 2017, és una llicència de copyleft aprovada per l'OSI amb tres característiques distintives.

• Llenguatge. Existeix en les llengües oficials de la UE, i totes les versions aprovades tenen un valor idèntic, de manera que una autoritat neerlandesa pot contractar en neerlandès.
• Compatibilitat. Un apèndix enumera les llicències compatibles (GPLv2 i v3, AGPLv3, LGPL, MPL 2, EPL 1.0, OSL i CeCILL, entre elles) i permet que una obra derivada que combina codi EUPL amb codi sota una llicència llistada es distribueixi sota aquesta llicència.
• Arribar. La seva definició de distribució inclou fer que l'obra estigui disponible en línia o fora de línia. o proporcionar accés a les seves funcionalitats essencials, i l'art. 5 de la EUPL estén l'obligació de copyleft fins a la interacció remota en què s'ofereix aquesta mateixa funcionalitat. Per tant, arriba al programari lliurat com a servei, d'una manera que la GPL no ho fa.

Un client del sector públic neerlandès pot exigir la llicència EUPL com a qüestió de política en lloc de per llei. La Llei d'Interoperabilitat Europea, Reglament (UE) 2024/903, ordena als organismes del sector públic que prioritzin solucions d'interoperabilitat sense termes de llicència restrictius, com ara el codi obert, quan sigui equivalent; a nivell nacional, el principi de codi obert, tenzij , es basa en decisions i línies polítiques del gabinet, no en lleis: la Wet digitale overheid facilita la infraestructura d'identitat digital però no imposa cap obligació exigible de publicar tot el codi font. Llegiu els documents de la licitació: un requisit de la llicència EUPL vincula el vostre producte final i pot ser incompatible amb el codi propietari que teníeu previst reutilitzar.

Aplicació a la pràctica

Qui pot demandar. El titular dels drets: els col·laboradors individuals o la fundació o empresa que té els drets d'autor cedits. L'autoria fragmentada és el fre pràctic: el demandant ha de demostrar la propietat del codi en qüestió. Això va desestimar el cas GPL europeu més conegut, on la demanda d'un desenvolupador del nucli contra un proveïdor de virtualització va fracassar per manca de prova d'autoria (LG Hamburg 8 de juliol de 2016, 310 O 89/15; confirmada OLG Hamburg 28 de febrer de 2019, 5 U 146/16).

Què estableix la jurisprudència. Els tribunals alemanys han acceptat repetidament que les llicències de codi obert són vàlides i que l'incompliment fa que la distribució sigui il·legal, començant per la primera ordre judicial de la GPL (LG München I 19 de maig de 2004, 21 O 6123/04). El Circuit Federal dels Estats Units va arribar a la mateixa conclusió a Jacobsen contra Katzer , 535 F.3d 1373 (Fed. Cir. 2008): els termes de la llicència són condicions sobre l'abast de la concessió, no meres clàusules, de manera que l'incompliment dóna suport a una reclamació de drets d'autor i a una mesura cautelar. El litigi dels Estats Units està explorant si un receptor posterior pot fer complir la GPL com a tercer beneficiari. Aquesta és la qüestió central a Software Freedom Conservancy contra Vizio davant el Tribunal Superior de Califòrnia: si els consumidors, com a tercers beneficiaris, poden exigir l'alliberament del codi font sota la GPLv2. S'espera una sentència final substantiva només després del judici amb jurat el 2026, de manera que la qüestió encara no s'ha decidit.

Com ho abordaria un tribunal neerlandès. Com a infracció dels drets d'autor segons l'Auteurswet: el demandant demostra la propietat i la reproducció o comunicació; el demandat planteja la llicència; el demandant respon que no es van complir les condicions, de manera que la defensa fracassa. Els recursos contractuals en virtut de l'art. 6:265 BW funcionen en paral·lel, però els drets d'autor són la via més sòlida.

Recursos. Una ordre judicial en virtut de l'art. 3:296 BW, normalment amb una multa i disponible en procediments sumaris; danys i perjudicis en virtut de l'art. 27 Aw i un compte de beneficis en virtut de l'art. 27a Aw; retirada, lliurament o destrucció en virtut de l'art. 28 Aw; i recuperació completa de les costes legals raonables i proporcionades en virtut de l'art. 1019h Rv. Quan el programari es va distribuir gratuïtament, la pèrdua és difícil de quantificar, i un tribunal d'apel·lació alemany va rebutjar concedir danys i perjudicis tot i confirmar l'ordre judicial (OLG Hamm 13 de juny de 2017, 4 U 72/16). El que rarament mossega són els danys i perjudicis: és l'ordre judicial, la retirada, l'ordre de costos i haver de publicar la font que mai no es volia publicar.

Quan descobreixes un problema de compliment

El descobriment normalment prové del qüestionari de seguretat d'un client, d'una exploració durant la diligència deguda o d'una carta del titular dels drets. La correcció s'executa de la següent manera: atureu la distribució de la compilació afectada si l'exposició és greu. Establiu quin component, quina versió, quina llicència, quins productes i llançaments, durant quin període. Calculeu què requereix realment la llicència, sovint un fitxer d'atribució en lloc d'un llançament de codi font. Prepareu els artefactes: avisos, textos de llicència, codi font corresponent complet, inclosos els scripts de compilació, i una oferta escrita on s'utilitzi. Envieu un llançament conforme i, a continuació, expliqueu al titular dels drets què heu fet en lloc de discutir sobre si ho havíeu de fer.

Sota la GPLv3 i l'AGPLv3, la finestra de correcció dóna valor legal a la velocitat; sota la GPLv2 no hi ha cap dret de correcció, motiu pel qual la majoria de les mesures d'aplicació acaben en un compromís de compliment negociat. Tingueu en compte també que el privilegi s'aplica a l'assessorament del vostre advocat, no a un informe d'enginyeria intern.

Codi obert en fusions i adquisicions i due diligence

En una adquisició de programari, el codi obert és un flux de treball de diligència estàndard, i un component de copyleft no revelat en el producte principal és una de les poques troballes que realment mouen un acord: si el producte no es pot distribuir sense publicar el seu codi font, el comprador està adquirint un actiu diferent del que té preu.

Espereu una anàlisi de la base de codi, un inventari de components amb llicències i preguntes sobre els acords entre col·laboradors i contractistes. Els resultats típics són una indemnització específica, una retenció pendent de remediació, una condició precedent que requereixi l'eliminació o una garantia de codi obert a mida. Els venedors haurien d'analitzar primer: les conclusions que reveleu són una negociació, les conclusions que fa l'assessor del comprador són un avantatge. Els compradors no haurien de buscar "l'empresa és propietària de la seva propietat intel·lectual", sinó una representació que cap producte incorpora codi obert que requereixi la divulgació de codi font propietari.

La llista de materials, l'escaneig i la Llei de ciberresiliència

Una llista de materials de programari és un inventari dels components d'un producte, amb versions i llicències. Fins fa poc era purament contractual, ara també és reguladora.

La Llei de ciberresiliència, Reglament (UE) 2024/2847, va entrar en vigor el 10 de desembre de 2024 i s'introdueix gradualment. Les obligacions d'informació sobre vulnerabilitats explotades activament i incidents greus de l'art. 14 de la Llei de ciberassegurances (CRA) s'apliquen a partir de l'11 de setembre de 2026; les disposicions sobre la notificació dels organismes d'avaluació de la conformitat a partir de l'11 de juny de 2026; el Reglament complet a partir de l'11 de desembre de 2027 (art. 71 CRA). L'annex I de la CRA exigeix ​​als fabricants que identifiquin i documentin els components del producte, fins i tot mitjançant l'elaboració d'una llista de materials de programari en un format d'ús comú i llegible per màquina que cobreixi com a mínim les dependències de nivell superior. No cal que es publiqui; les autoritats de vigilància del mercat ho poden sol·licitar.

El programari lliure i de codi obert subministrat fora d'una activitat comercial queda fora de l'àmbit de l'ARC. El Reglament introdueix l'administrador del programari de codi obert —una persona jurídica que dóna suport sostingut al desenvolupament de programari de codi obert destinat a activitats comercials— amb obligacions més lleugeres a l'art. 24 de l'ARC: una política de ciberseguretat documentada, cooperació amb les autoritats de vigilància del mercat i presentació d'informes. Si comercialitzeu programari de codi obert o financeu un projecte que altres comercialitzen, establiu quin rol ocupeu. La Comissió va adoptar les seves primeres directrius el 27 de juliol de 2026: les directrius de la Comissió sobre l'aplicació de la Llei de ciberresiliència (ARC), annexes a la comunicació C(2026) 5252, que aborden, entre altres coses, quan el programari lliure i de codi obert entra dins l'àmbit d'aplicació. No s'ha adoptat cap acte d'aplicació que prescrigui un format per a la llista de materials del programari, per la qual cosa l'estàndard propi del Reglament —un format llegible per màquina d'ús comú— continua sent la mesura de moment.

L'anàlisi de la composició de programari executada a CI genera l'inventari que serveix per al compliment normatiu, la revisió de llicències i la diligència alhora. Aquestes eines no detecten el codi del proveïdor, identifiquen erròniament els projectes amb doble llicència i no poden llegir les condicions d'una llicència: tracten la sortida com l'inici de la revisió, no com la revisió mateixa.

Si publiqueu el vostre propi codi: els CLA i el DCO

Una empresa que publica codi i accepta contribucions externes ha de saber que té els drets sobre allò que fusiona. Un acord de llicència de col·laborador és un contracte entre el projecte i el col·laborador, que normalment atorga una àmplia llicència de drets d'autor i una llicència de patent expressa, amb garanties quant a l'originalitat i l'autoritat. És el que permet a una empresa tornar a llicenciar el seu projecte més tard o oferir llicències comercials juntament amb una de codi obert. El seu cost és la fricció.

El Certificat d'Origen del Desenvolupador , utilitzat pel nucli de Linux i molts altres projectes, no és una concessió de llicència sinó una atestació lleugera, afegida com a línia de finalització a cada commit, que el col·laborador pot enviar el codi sota la llicència del projecte. Menys feixuc i menys protector: sense llicència de patent, sense renovació de llicències.

Si la doble llicència o una futura rellicència és plausible, feu servir un CLA; si el projecte és un bé comú genuí, el DCO sol ser suficient. Sigui com sigui, assegureu-vos que els vostres acords laborals i contractistes assignin els drets d'autor del codi que escriu la vostra gent.

Una llista de comprovació de polítiques pràctiques

• Genera un inventari de components per producte i allibera'l durant el procés de compilació, no manualment.
• Publicar una política interna: una llista de permesos, una llista de prohibits i una via d'aprovació per a tota la resta.
• Defineix per escrit què compta com a distribució: instal·lacions locals, dispositius, contenidors, SDK, aplicacions mòbils, firmware.
• Envieu un fitxer d'atribució generat amb cada producte.
• Aprova les opcions de llicència en el moment del disseny, quan se selecciona un component, no en el moment del llançament.
• Decidiu si les contribucions a projectes externs necessiten aprovació, ateses les patents concedides, i trieu un CLA o un DCO abans de la primera contribució externa.
• Alineeu les garanties, les indemnitzacions i els termes del dipòsit en garantia de la propietat intel·lectual amb el codi obert que realment conté el producte.
• Feu la revisió abans d'un procés de recaptació de fons o de venda, no durant un.