Si ets programador, necessites conèixer els diferents tipus de llicències de software

Normalment, quan una empresa crea programari també reutilitza codi. Això inclou fragments de codi, biblioteques, funcions, marcs de treball i aplicacions senceres. De fet, en la majoria d'aplicacions, la major part del codi està composta per components de tercers reutilitzats. I tot el codi del programari ve amb certs drets i obligacions si és utilitzat per altres o incorporat en el codi d'una empresa. 

Fins i tot els fragments de codi copiats de Stack Overflow tenen obligacions per a la reutilització. La majoria d'aquests components de tercers són de codi obert. El programari de codi obert és gratuït, però no està lliure d'obligacions; simplement està controlat per un tipus diferent de llicència.

El programari es llicencia de maneres diferents, i les conseqüències de no complir amb la llicència poden ser significatives. Si una empresa reutilitza un component sense llicència o sense complir amb les obligacions d'una llicència, el titular dels drets d'autor podria presentar una demanda. En algunes circumstàncies, una empresa podria enfrontar-se a una ordre judicial contra la distribució addicional de productes que contenen components mal utilitzats, danys o la possibilitat de haver de publicar el seu propi codi font. 

La majoria de les empreses simplement volen ser "netes" en el seu ús de programari de tercers. Per protegir el codi i l'organització, cal entendre les llicències de programari que governen l'ús de qualsevol codi, incloses les biblioteques i els marcs de treball que no vas escriure tu mateix.

Com funcionen les llicències de programari?

Els nous usuaris d'un programari normalment subscriuen un acord de llicència amb l'anomenat Acord de Llicència d'Usuari Final (EULA), que constitueix una definició legal de la relació entre el llicenciador (proveïdor) i el llicenciat (usuari o empresa). L'EULA és un contracte que estableix els drets del comprador per instal·lar i utilitzar el programari.

Cada EULA conté una clàusula que especifica quan es posen en marxa les seves condicions per part de l'usuari final. Això pot ser en el moment en què l'usuari obre l'embolcall del producte o, per exemple, quan l'usuari fa clic en un botó per acceptar els termes de l'EULA per accedir-hi.

Per exemple, les aplicacions basades en el núvol, com el Software com a Servei (SaaS), sovint inclouen detalls de llicència a les EULAs, incloent-hi:

• Càrregues mensuals o anuals per usuari.
• Durada de l'acord.
• Termes de cancel·lació de l'acord.
• Recuperació de qualsevol càrrega si es cancel·la durant l'acord.

Una altra utilització de les llicències de programari és quan un desenvolupador o empresa atorga l'autorització per vendre o distribuir el programari amb la marca d'una segona part. El desenvolupador conserva la propietat, però l'empresa que fa el reetiquetatge té permís per revendre el producte. Aquest mètode de llicència es coneix com "etiquetatge blanc" (white labeling).

Les diferents tipus de llicències de programari

Aquí tens cinc tipus comuns de models de llicències per a components que es poden reutilitzar en un codi, juntament amb la rara i mal entesa categoria de programari de domini públic, i la no tan rara categoria sense llicència.

1. Permissives

   Les llicències permissives tenen restriccions mínimes sobre com es pot modificar o redistribuir el programari. També se les coneix com a llicències "d'atribució", ja que generalment només requereixen que es retengui la informació de drets d'autor en un fitxer d'avisos quan es distribueix el programari. Aquest tipus de llicència de programari és la més popular entre les llicències de codi obert. Els exemples més coneguts d'aquesta categoria són la Llicència Apache, la Llicència BSD i la Llicència MIT.

2. Copyleft feble

   La Llicència Pública General Menor de GNU es coneix com una llicència de tipus "copyleft feble". Està dissenyada per permetre la vinculació a biblioteques de codi obert amb poques obligacions. Si el programari vincula dinàmicament a una biblioteca amb llicència LGPL, tota la feina es pot distribuir sota qualsevol llicència, fins i tot una llicència pròpia, amb requisits mínims. La vinculació estàtica i/o la modificació de la biblioteca es complica més. I l'ús del component amb llicència LGPL d'altres maneres comporta obligacions copyleft. Altres llicències de copyleft feble (incloses la MPL, CDDL i Eclipse) ocupen un lloc entre les permissives i les de copyleft.

3. Copyleft

   Les llicències de copyleft també es coneixen com a llicències recíproques o restrictives. En general, són menys amigables des del punt de vista comercial que altres llicències. La més coneguda i utilitzada amb freqüència és la família de llicències de la General Public License (GPL). 

   Aquestes llicències permeten als desenvolupadors modificar el codi llicenciat, incorporar-lo amb codi propietari i distribuir obres noves basades en ell, sempre que distribueixin el codi font de qualsevol obra nova o adaptació sota la mateixa llicència de programari. El problema aquí és que aquestes llicències requereixen la distribució del codi font juntament amb la nova obra derivada. Per tant, la llicència per a una obra pròpia que inclou codi amb llicència GPL requereix la distribució de codi font propietari. Però, és clar, exposar el codi font als usuaris o als competidors generalment no està en l'interès (comercial) d'una empresa. Així que les empreses que creen aplicacions comercials solen evitar l'ús de programari amb aquest tipus de llicències.

4. Comercial o propietària

   De tots els tipus de llicències de programari, aquestes tendeixen a ser les més restrictives. Aquestes llicències s'utilitzen generalment per a programari comercial on el titular dels drets d'autor està afirmant condicions expressament respecte als drets que es concediran, i per exemple, no vol que el codi es comparteixi, s'ingeni, es modifiqui, es redistribueixi o es vengui.

5. Dual

   Un titular de drets d'autor pot optar per oferir el seu programari sota diferents llicències a diferents usuaris. Un model de negoci cada vegada més comú és la doble llicència: utilitzar tant una llicència de copyleft o altres formes de llicència oberta però restrictiva, com una llicència comercial. 

   L'estratègia és utilitzar la llicència de codi obert per facilitar que els desenvolupadors obtinguin el codi i el provin, però les obligacions són tals que, si l'empresa realment vol guanyar diners amb el programari, ha de pagar per una llicència comercial. 

   La llicència AGPL es fa servir sovint per a aquest propòsit, i han sorgit algunes variants noves que són encara més comercialment restrictives, com ara la Llicència Pública del Costat del Servidor.

6. Domini públic

   Algún programari és de domini públic. En general, les obres de programari estan protegides pel dret d'autor, el que significa que utilitzar el programari de qualsevol manera requereix el permís del creador o del titular dels drets d'autor, és a dir, una llicència. 

   No obstant això, el dret d'autor no s'aplica a les obres de domini públic, i qualsevol pot modificar i utilitzar aquest programari sense cap restricció. Però has de saber que el codi de domini públic és rar i que la definició varia entre jurisdiccions.

7. Sense llicència

   El codi que no té una llicència explícita no es considera de facto en domini públic; la premissa és que necessites una llicència per utilitzar el programari. Així que si una empresa no pot associar el programari que està utilitzant amb una llicència, probablement està incomplint la llei de drets d'autor.

Com fer per saber quines llicències s'apliquen a un codi de programari

Abans de poder determinar quines llicències regeixen els components d'un codi, necessites un Inventari de programari (SBOM, per les seves sigles en anglès), una llista de tots els components del codi. 

Un programa establert que inclogui polítiques, processos, formació i eines d'anàlisi de la composició de programari (SCA) garantirà que una empresa pugui mantenir un SBOM precís amb el temps. Una bona eina SCA serà capaç de trobar components complets així com fragments de codi, i t'indicarà quines llicències s'apliquen a cada tros de codi i si pots estar utilitzant llicències que tenen conflictes (a més d'identificar vulnerabilitats de seguretat conegudes als components). 

En absència de tot això, o, per exemple, en una transacció de fusió i adquisició, una auditoria de confiança realitzada per un tercer competent pot proporcionar una instantània precisa en un moment determinat.

Un cop establert el SBOM, i especialment amb l'ajuda d'una eina SCA o d'un auditor, la majoria de les llicències seran fàcils de comprendre. Però, com destaca aquest article, això no sempre és el cas. La millor pràctica és tenir un advocat de propietat intel·lectual amb coneixements en codi obert a qui recórrer per assessorar sobre les qüestions més complexes que inevitablement sorgeixen.