EUPL.IT for eGov
EnglishFrenchGermanItalianPortugueseRussianSpanish

Quale soluzione alla proliferazione delle licenze Open Source?

Al fine di darne maggior risalto, ripropongo in questa sezione (EUPL NEWS) il commento inviatomi da Patrice-Emmanuel Schmitz, sul tema spinoso della proliferazione delle licenze open source.

La combinazione tra open source e copyleft (come è stato fatto da Richard Stallman) è stata probabilmente la pietra miliare per la sostenibilità del software libero. Tutto questo è ora in pericolo, a causa della proliferazione di licenze copyleft, che sono incompatibili per come sono state progettate. Dopo aver contato 1,800 diverse licenze usate da centinaia di migliaia di progetti open source, la società Black Duck ha brevettato (US – 7.552.093 B2) la tecnologia per controllare l’uso delle licenze open source in un processo di sviluppo multi-source. L’uso di software brevettato per risolvere l’incompatibilità copyleft è paradossale!

Per mantenere un forte copyleft, preservando la libertà agli sviluppatori ‘, Patrice-Emmanuel Schmitz (uno degli scrittori EUPL) pensa che è giunto il momento per promuovere l’interoperabilità delle licenze copyleft. Il suo articolo è pubblicato (in inglese) sul sito http://www.OSOR.eu
( http://www.osor.eu/communities/eupl/blog/licence-proliferation-the-way-out )

L’articolo segnalato (“Licence Proliferation. The Way Out?”) è molto interessante e ne consiglio un’attenta ed integrale lettura.

Non rinuncio, però, a segnalarvi alcuni passaggi che mi sembrano molto significativi.

Schmitz, infatti, sottolinea che

If license proliferation can be perceived as a failure, I do not think that it is the failure of the F/OSS movement. It is the entire contrary: a testimony of the vitality and attractiveness of F/OSS models.

In reality, license proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the 80’ and reproduced by nearly all subsequent copyleft licenses. Once necessary and successful, this model looks not adapted anymore because it was copied and creates today more barriers (and less freedom) than protection.

Il ragionamento prende in considerazione, dunque, il modello di licenza open source basato sullo “strong copyleft” (o “rigid copyleft” ;) , all’insegna del quale la c.d. clausola virale non tollera eccezioni e rifiuta ogni interoperabilità con qualsivoglia altro contratto, incluso le altre licenze open source che intendono perseguire il medesimo fine.

Spiega ancora Schmitz nel suo articolo:

Why is it a problem? The main issue with license proliferation is not only to multiply the number of texts (and the obligation to analyse and to understand differences between licenses). It is the proliferation of the rigid copyleft model adopted by many licenses, which excludes other models in case of re-distribution and creates new barriers.

Schmitz non trascura di esaminare, seppur brevemente, le conseguenze pratiche ingenerate dal modello di rigid copyleft:

When developers adopt a copyleft license, integrating “incompatible” code in their work makes the distribution of derivative works impossible. This is a pity when F/OSS copyleft licenses are those which should provide the best protection of user’s and developers rights and freedom.

The fact a dozen of licenses are used for more than 90% of projects does not solve this issue: modern free software programming is the assembly and interaction of many components, licensed by a multitude of authors and contributors. Provide only one of the key components has incompatible licensing conditions may impact on the whole solution.

Nell’indagare le possibili soluzioni al problema dell’incompatibilità delle licenze al fine di garantire l’utilizzo del software, in cui confluiscono più componenti assemplati tra loro, ciascuno governato da una licenza eventualmente diversa, l’approccio classico è quello tipico della “upstream compatibility”, a cui può contrapporsi un’altro, più innovativo, che può essere denominato di “downstream compatibility”:

The classical vision of copyleft is based on “upstream compatibility”: a developer will find that a software license is “compatible” with its own licensing purpose when he/she can freely reuse or copy the licensed software into his work and redistribute the derivative work under his/her preferred copyleft conditions. This way was initiated by the GPL and worked very well until it was copied.

(… ;)

An innovative approach to solve copyleft licenses conflicts is to publish a downstream compatibility list. To my knowledge, the EUPL is the first copyleft license to publish such a list. When it is necessary to avoid license conflicts, developers have the freedom to change for another “similar” copyleft license (in that case the GPLv2, Eclipse, OSL, CeCILL, and Common Public Licence).

Il concetto, ricorda ancora Schmitz, non è nuovo ed è quello a cui si ricorre, notoriamente, in caso di librerie:

The concept is not new, as the FSF applied it with the LGPL a long time ago. The LGPL (now LGPLv3) is convenient for software libraries aimed to produce derivative works: if the library is propagated on its own, it must be under the provision of its original license (LGPL); however, if the library components are part of a derivative work, this work can be licensed under another license, while the original library remains LGPL.

Tuttavia, la soluzione innovativa della downstream compatibility list, adottata nella EUPL, presenta non solo vantaggi, ma anche rischi, connessi alla ristrettezza della lista ed alla sua imposizione unilaterale e non oncertata tra una comunità (es. FSF) e l’altra (es. UE). Tra tali rischi è da includere quello riassunto molto bene da Schmitz con l’espressione “Tourism Licence”, allorché un software, originariamente licenziato sotto una licenza, finisce per migrare sotto un’ulteriore llicenza per garantirsi l’uso di una componente fondamentale governata da una public licence non inclusa nella lista di quelle compatibili.

E’ chiaro, allora, che la soluzione deve passare per un’altra via, individuata nella interoperabilità tra le diverse licenze open source.

Ecco come prosegue il ragionamento di Schmitz:

Therefore, the convenient approach to increase developers’ freedom without compromising the F/OSS sustainability of derivative works could be called the “loan and give back interoperability” between strong copyleft licenses: a loan from a specific community could be recovered at any time by the same community (and not transferred to any other, outside a circle, without its agreement).

Interoperability will not impact the original license of the loaned component. The objective is not to change it, but to facilitate complex solution development and obtain a single licence for the solution.

To avoid any kind of abuse (… ;) , it would be wise to set up interoperability agreements good practices, authorizing the lender community to distribute also the whole developed solution under the lent component’s original license.

(… ;)

Such exchanges will be restricted to the members of the “circle of trust” that have concluded the interoperability agreement.

(… ;)

Interoperability will strongly reduce the impact of license proliferation, by creating a visible interoperable circle of trust.

La prospettiva è interessante e ringrazio Patrice-Emmanuel Schmitz per avercela voluta proporre.

Del resto, il tema dell’interoperabilità tra le licenze, su cui si dovrà lavorare in futuro, soprattutto in vista del delicato rapporto tra EUPL 1.1 e GPL v.3,  è affine al processo di arminizzazione che l’UE sta conducendo nel tentativo di avvicinamento delle singole legislazioni nazionali dei Paesi membri.

In entrambi i casi abbiamo un assetto normativo (le singole public licences, da una parte, e le singole normative nazionali, dall’altra parte) che è espressione di comunità differenti.

Mi sembra però che l’auspicata buona riuscita del processo di interoperabilità, così come quello di armonizzazione, debba essere preceduta o accompagnata da una sensibilizzazione culturale, che deve far giungere ad un avvicinamento (appunto “culturale” ;) tra due comunità che si percepiscono almeno in parte distanti e che sarebbe meglio se iniziassero a trovare seriamente forti punti di contatto.

Il percorso di riflessione di Schmitz, che, è bene ricordarlo ancora una volta, è tra coloro che hanno predisposto il testo della EUPL, mi sembra significativo, perché l’auspicata convergenza si sente già nell’aria e l’articolo di Schmitz dà un sicuro contributo al rinnovamento del processo culturale, propedeutico per qualsivolgia cambiamento delle strategie contrattuali che sono alla base delle (quasi duemila) licenze open source.

Un gazie sentito sentito a Patrice-Emmanuel Schmitz per aver voluto contribuire, con le Sue riflessioni, ad arricchire il confronto sulla European Union Public Licence su questo sito.

Fabio Bravo

www.fabiobravo.it

.

3 risposte a Quale soluzione alla proliferazione delle licenze Open Source?