Smau Padova 2011 Igor Serraino

Licensing e antipirateria nella realizzazione di applicativi ad hoc

Padova, 5 maggio 2011 ore 15.30 :: Sala 3

Relatore: Ing. Igor Serraino

www.serraino.it

1Wednesday, May 11, 2011

WWW.SERRAINO.IT SMAU PADOVA 2011

CSIG & IS2011, Diritti riservati IS. Eʼ vietata ogni forma di pubblicazione

senza preventiva autorizzazione dellʼautore.

Agenda

Diritto d’autore & copyright: premesse giuridiche e terminologiche

Dal punto di vista dell’autore

Codice sorgente e codice eseguibile

Licensing e casi d’uso

Considerazioni conlusive





DIRITTO D’AUTORE & COPYRIGHTPREMESSE GIURIDICHE E TERMINOLOGICHE





Software programmingDiversi scenari, tra i più diffusi:

1. freelance programmer on a commission basis: l’azienda commissiona al libero professionista un applicativo ad hoc con alto livello di personalizzazione (“su commissione”). Il software è ad uso interno, il committente utilizza l’applicativo esclusivamente sulle proprie postazioni informatiche;

2. embed programmer on a commission basis: parte dell’organigramma aziendale, il programmatore è incaricato della produzione di un software ad uso interno;

3. freelance programmer OR embed programmer to market on a commission basis: l’applicativo commissionato è destinato alla commercializzazione. Il committente, quindi, ha incaricato il programmatore (interno o esterno) di creare un software che poi verrà sottolicenziato dal committente stesso;

4. freelance programmer to market: il programmatore libero professionista produce un software destinato alla vendita attraverso canali di vendita da esso stesso stabiliti;

5. freelance programmer to community: il programmatore, di qualunque natura esso sia, produce software (o moduli software) con finalità non commerciali.





Criticità

In ognuno degli scenari introdotti:

il programmatore o il fornitore percepiscono l’esigenza di tutelare l’applicativo e garantire un utilizzo idoneo alle funzionalità implementate;

è necessario formalizzare il rapporto che intercorre tra chi fornisce il software e l’utilizzatore finale;

è fondamentale definire la data di consegna, il numero di versione e le funzionalità presenti nell’applicativo consegnato;

deve essere effettuata una scelta sulla modalità di rilascio dell’applicativo e dei relativi componenti funzionali: codice sorgente abbinato ad eseguibile o esclusivamente codice eseguibile (o compilato)?

è spesso richiesto di prevedere possibilità di aggiornamento / modifiche funzionali successive alla consegna definitiva.





Diritto d’autore vs Copyright

Copyright e diritto d'autore sono due sistemi quasi identici, ma ci sono alcune differenze (anche storiche).

Il Copyright è una invenzione dell'era Gutenberg, un risultato dell'invenzione delle presse per la stampa risalente alla seconda metà del ‘400. Originariamente inteso come monopolio per gli editori (nel 1500 Venezia contava ben 417 editori) e non era concepito per dare agli autori alcun diritto sulle proprie opere. Solo nel 1710 i primi autori possono acquisire i diritti sulle proprie opere.

L'idea di un diritto fondamentale dell‘Autore sul proprio lavoro — il nocciolo del moderno diritto d'autore — è stata diffusa prevalentemente da filosofi tedeschi e francesi prima della Rivoluzione Francese e venne considerata come una delle maggiori conquiste della Rivoluzione Francese.

AVV. ANDREA MAGGIPINTO :: WWW.MAGGIPINTO.ORG





Diritto d’autore vs Copyright

Oggi gli ordinamenti dell'Europa continentale seguono la tradizione del diritto d'autore, l'area anglosassone segue ancora la tradizione del copyright

Al fine di creare una base internazionale comune, ci sono stati processi ed accordi di armonizzazione. Per questo motivo la maggior parte delle questioni sono sostanzialmente identiche nonostante le basi estremamente differenti

Contrariamente al Copyright, il diritto d'autore riconosce un diritto morale all'autore che - come altri diritti umani - è inalienabile. Indipendentemente da quello che dice qualsiasi contratto, il diritto morale dell'autore non può mai essere limitato. In effetti un contratto che (in pratica o apparentemente) tenti di farlo corre il rischio di essere dichiarato nullo davanti ad una corte





Convenzione di Berna

Convenzione di Berna per la protezione delle opere letterarie e artistiche del 9 settembre 1886 (completata a Parigi il 4 maggio 1896, riveduta a Berlino il 13 novembre 1908, completata a Berna il 20 marzo 1914 e riveduta a Roma il 2 giugno 1928, a Bruxelles il 26 giugno 1948, a Stoccolma il 14 luglio 1967 e a Parigi il 24 luglio 1971)

Sono state introdotte due nuove categorie di opere protette dal diritto d'autore:

i programmi per elaboratore: considerati alla stregua di opere letterarie;

le banche di dati: tutelate in ragione della loro creatività dovuta al tipo di materiale selezionato ed al tipo di disposizione che di esso viene fatto nella banca





Riconoscimento a livello internazionale

Il diritto d'autore è un diritto territoriale: la legge del luogo dove l'opera è destinata a essere utilizzata è quella che stabilisce se e in che modo l'opera deve essere tutelata.

Per questo è importante il riconoscimento reciproco del diritto d'autore tra gli Stati aderenti alla Convenzione di Berna (l’Italia ha aderito nel 1978)





Il software nella Comunità europea

La Comunità Europea ha deciso di fornire ai programmi per elaboratore la protezione che si riconosce alle altre opere d'autore attraverso l'emanazione della Direttiva 91/250/CEE del Consiglio, del 14 maggio 1991, relativa alla tutela giuridica dei programmi per elaboratore. È stata recepita nel nostro ordinamento giuridico con il d.lgs. 518 emanato il 29 dicembre 1992, che ha novellato la legge sul diritto d'autore n. 633/1941

Nel 2002 la Commissione Europea ha pubblicato una proposta di direttiva in tema di invenzioni attuate per mezzo degli elaboratori elettronici, bocciata però dal Parlamento europeo il 6 luglio 2005

Nuova Direttiva 2009/24/CE del Parlamento Europeo e del Consiglio del 23 aprile 2009 relativa alla tutela giuridica dei programmi per elaboratore, che ha abrogato la Direttiva 91/250/CEE





Il software nella Comunità europea

Lo scopo della nuova direttiva è duplice:

rafforzare la protezione del diritto d'autore del sw, in quanto “per creare programmi per elaboratore è necessario investire considerevoli risorse umane, tecniche e finanziarie, mentre è possibile copiarli a un costo minimo rispetto a quello necessario per crearli autonomamente”

eliminare le differenze normative esistenti nella tutela giuridica dei programmi per elaboratore





Il software in Italia

Legge sul Diritto d’Autore (LDA): legge 22 aprile 1941, n. 633

Le modifiche alla LDA (D.Lgs. 518/92) hanno esteso al software la protezione assicurata alle “opere dell'ingegno di carattere creativo”, così riconoscendo in capo all'autore di un software (il programmatore) sia la summa dei diritti afferenti al diritto morale d'autore, sia i diritti di utilizzazione economica dell'opera

Il diritto d'autore sul software costituisce una privativa sui generis, diretta a riservare al titolare non soltanto la riproduzione ma, ancor prima, l'utilizzo stesso del programma, consentendogli così di escludere qualsiasi possibilità di uso da parte di altri se non espressamente autorizzati





Dal punto di vista dell’autore...

DIRITTI ESCLUSIVI DI UTILIZZAZIONE ECONOMICA• SCADONO E POSSONO ESSERE TRASFERITI• INDIPENDENTI GLI UNI DAGLI ALTRI

PUBBLICAZIONERIPRODUZIONEESECUZIONERAPPRESENTAZIONECOMUNICAZIONE AL PUBBLICODISTRIBUZIONETRADUZIONE O ELABORAZIONENOLEGGIO O PRESTITOTRASCRIZIONE

DIRITTI MORALI:• INALIENABILI • IMPRESCRITTIBILI

PATERNITÀINTEGRITÀINEDITORITIRO DELL'OPERA

RIF. LDA ARTT. 20-24, ARTT. 142-143

RIF. LDA ARTT. ARTT. 12-19





Il contenuto del diritto

I diritti di utilizzazione economica:

attribuiscono all’autore la piena disponibilità dell’opera e il potere di impedire comportamenti non autorizzati (il rovescio della medaglia)

principio di indipendenza dei diritti

trasmissibilità del diritto

durata limitata nel tempo: 70 anni dalla morte dell’autore





Diritti morali

Il diritto di paternità

Il diritto di opporsi a qualsiasi deformazione, mutilazione o altra modificazione, e a ogni atto a danno dell’opera stessa, che possano essere di pregiudizio all’onore e alla reputazione dell’autore

Il diritto di ritirare l’opera dal commercio

Diritto di inedito (l'autore ha diritto di pubblicare la propria opera o di lasciarla per sempre nell'inedito, insomma è arbitro della pubblicazione)






Licensing & licensing agreement

The granting of permission to use intellectual property rights, such as trademarks, patents, or technology, under defined conditions.

Written contract under which the owner of a copyright, know how, patent, servicemark, trademark, or other intellectual property, allows a licensee to use, make, or sell copies of the original.





Distribuzione del software: terminologiasoftware freeware (libero): distribuito gratuitamente. Sono generalmente ammesse la redistribuzione e la duplicazione, sempre a titolo gratuito. Il codice sorgente può essere fornito o meno, tale scelta non è direttamente collegata alla gratuità dell’applicativo; (NB. NON è necessariamente Open Source, slides successive...)

software shareware: fornito a titolo dimostrativo per un periodo limitato di tempo, e spesso al limite temporale si abbina anche una limitazione funzionale. Al termine del periodo stabilito per la prova, l’utilizzatore è tenuto ad acquistare regolare licenza a pagamento o a cessare ogni forma di utilizzo;

software copyleft: individua un modello di gestione dei diritti d'autore basato su un sistema di licenze attraverso le quali l'autore (in quanto detentore originario dei diritti sull'opera) indica ai fruitori dell'opera che essa può essere utilizzata, diffusa e spesso anche modificata liberamente, pur nel rispetto di alcune condizioni essenziali.

software di dominio pubblico: espressione del diniego di interesse da parte del programmatore. Pone il software in uno stato privo di copyright;

software proprietario: dotato di limitazioni d’uso, di redistribuzione o copia, di modifica, poste dall’autore e certificate da un mezzo tecnico o legale;

software commerciale: sviluppato da un’azienda con la finalità di distribuirlo sul mercato a pagamento. Non necessariamente si tratta di software proprietario: applicativi commerciali freeware inquadrano la distribuzione con contratti di assistenza a pagamento


CODICE SORGENTE E CODICE ESEGUIBILE





Codice sorgente e codice eseguibile

L’accesso o meno al codice sorgente del software è prerequisito parte di ogni tipologia di licenza

Codice sorgente: espressione del software in una forma intelligibile espressa in un qualche linguaggio di programmazione, che deve essere tradotta in linguaggio macchina per poter essere eseguita dal computer.

Codice eseguibile: traduzione del codice sorgente del software in una forma che permetta immediata esecuzione (o interpretazione) da parte dell’entità software preposta alla traduzione in codice macchina.





Use case: Oracle Sun Java

CODICE SORGENTE: file .java contenente codice in linguaggio Java (ovvero che ne rispetti la sintassi e la semantica).






CODICE COMPILATO (BYTECODE ESEGUIBILE): file .class interpretabile (eseguibile) da un’entità software denominata Java Virtual Machine






CODICE COMPILATO (BYTECODE ESEGUIBILE): file .class interpretabile (eseguibile) da un’entità software denominata Java Virtual Machine

SORGENTE: INTELLIGIBILE, MODIFICABILE BYTECODE: ESEGUIBILE, NON INTELLIGIBILE

PROGRAMMATORE LICENZIATARIO





L’importanza del codice sorgente

E’ il “substrato” a partire dal quale il software prende vita

Fornisce un gran numero di informazioni tecniche low level relative al software:

algoritmi utilizzati

architettura software implementata

librerie utilizzate

gestione della sicurezza

protezione dei dati, information hiding





Utilizzo del codice sorgente di un sw

Il programmatore, durante le varie fasi di sviluppo, produce e archivia diverse revisioni del codice sorgente (CVS versioning system)

Al momento della consegna il software è basato su un sorgente etichettato con un numero di versione, generalmente 1.x se definitivo o 0.x se ancora in deployment

Revisioni dell’applicativo successive alla consegna:

modifica diretta della versione 1.x, operando sul codice sorgente

utilizzo della versione 1.x, aggiungendo moduli funzionali che si appoggiano sull’applicativo completo (o su parti di esse)





Modifica del codice sorgente

Effettuata dal programmatore stesso o da terze parti

Può alterare il funzionamento a regime dell’applicativo, stabilito dalle specifiche funzionali (guida all’uso)

Richiede approfondita conoscenza dell’architettura utilizzata dall’applicativo (documentazione tecnica)

In generale, dato un applicativo fornito alla revisione 1.x o successiva, le operazioni di modifica / aggiornamento / correzione realizzate intervenendo sul sorgente sono di elevata complessità:

necessario sviluppo team-based

design patterns

documentazione on code





Utilizzo del codice sorgente

L’accesso al codice sorgente apre all’utilizzatore anche ulteriori prospettive:

realizzazione di componenti utilizzando i medesimi algoritmi del codice sorgente analizzato

adattamento del codice sorgente alle proprie esigenze

miglioramento dell’applicativo intervenendo direttamente sul codice sorgente (non riducendosi al mero utilizzo del binario)

sviluppo di librerie che utilizzano sorgenti già collaudati

contributo alla comunità di sviluppatori (gruppi di discussione internet, repositories pubblici, documentazione liberamente accessibile, case studies)





Open Source Software (OSS)

La definizione di software “Open Source” è stata proposta dalla Open Source Initiative ed è attualmente utilizzata per definire quali tipologie di licenze possano essere qualificate come “a sorgente aperto” (corollario: OSI CERTIFIED).

In generale, la qualifica di OSS prescrive il rispetto dei 3 canoni fondamentali:

1. l’oggetto del licensing non deve godere di commerciabilità con diritto esclusivo (free redistribution);

2. il codice sorgente deve essere disponibile (source code);

3. deve essere attuabile la generazione di opere derivate da quella oggetto della licenza (derived works).





Software OSI Certified

Per ottenere la certificazione di Software Open Source, esistono inoltre alcuni criteri aggiuntivi da rispettare, tra cui:

inviolabilità del codice originale, ovvero data una versione del codice sorgente (eventualmente modifica da più utenti), deve essere possibile ottenere la versione originale dell’autore (applicabile tramite l’adozione di patches sull’originale);

non deve essere inibito l’accesso al sorgente per determinate tipologie di utenti o gruppi di utenti;

la licenza d’uso originale deve poter essere applicabile a qualunque sottinsieme di utenti, senza la necessità di emetterne di nuove;

non possono esistere restrizioni relative a determinati ambiti di utilizzo;

la licenza non deve porre restrizioni su altro software distribuito insieme al software licenziato. Per esempio, la licenza non deve richiedere che tutti gli altri programmi distribuiti sugli stessi supporti siano software open source.

La licenza non deve contenere clausole che dipendano o si basino su particolari tecnologie o tipi di interfacce.





Codice eseguibile (o compilato)

Destinato all’esecuzione, attraverso librerie del sistema operativo (es. .exe in ambiente windows), oppure attraverso entità software fornite dal linguaggio di programmazione utilizzato (es. jvm java)

Non intelligibile

L’eventuale clonazione - con l’obiettivo di generare un applicativo copia - può essere funzionale e basata sul livello di presentazione dell’applicativo (interfaccia grafica), ma non è realizzabile dal punto di vista del codice

Nel caso di codice compilato (bytecode) esistono ulteriori forme di utilizzo differenti dall’esecuzione in senso stretto del termine

creazione di componenti che utilizzano il compilato, e precisamente tutte le funzionalità disponibili nella sua interfaccia pubblica

creazione di librerie, composte da uno o più compilati





Eseguibile --> Sorgente?

Reverse engineering è il processo per cui è possibile risalire a dettagli tecnologici, architetturali e di codifica di un applicativo software

Dall’eseguibile (o dal compilato) è possibile ricavare il codice sorgente che ne ha portato alla generazione

Esistono tools che permettono di generare diagrammi architetturali (UML per linguaggi a oggetti)

BYTECODE O ESEGUIBILE

CODICE SORGENTE

DIAGRAMMI UML

VIA MAINTAINJOR OTHERS TOOLS





Reverse engineering: osservazioni

Di norma vietato dalla legge, salvo che sia necessario per ottenere l’interoperabilità del software decompilato con altri programmi e non vi sia altro modo di ottenere tale interoperabilità (ad esempio: il programmatore ha in precedenza reso disponibile una patch per l’interoperabilità: in questo caso ovviamente la decompilazione è vietata);

questa precisa facoltà di decompilare è prevista dalla legge vigente

questione controversa: una eventuale clausola che impedisca la decompilazione del software inserita nella licenza è nulla, e sarà dunque possibile decompilare se necessario ottenere l’interoperabilità.





Codice sorgente indispensabile?

Linguaggi come Java e ActionScript3 di Adobe utilizzano una tecnica a bytecode per arrivare all’effettiva “esecuzione” del software o del componente

Sorgente .java Bytecode .java

Sorgenti .swf e as Binario .fXX

JVM

FLASH PLAYER


LICENSING E CASI D’USO





Licensing summary

FREE SOFTWARE

GPL LGPL X11 ,,OTHERS”prop. licenses

AD HOCtalvolta derivative da licenze esistenti

SOFTWARE PROPRIETARIO, COMMERCIALE, CON LIMITAZIONI D’USO

AGPL





GNU General Public License (GPL)

AMBITO DI APPLICAZIONE: free software, copyleft software

First version by Richard Stallman in 1989, revisioni successive nel 1991 e nel 2007 (v3, attuale)

“Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.”

Il testo della licenza, dunque, non è modificabile.

“GNU” IS A RECURSIVE ACRONYM FOR “GNU'S NOT UNIX





GPL: preamble

“The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users.“

...

“When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.”

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA





GPL: limitations

...if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.”

“...we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors’ reputations.”

“We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone’s free use or not licensed at all.”






GPL: obiettivi

1. Mantenere il software free, gratuito, in modo che risulti liberamente redistribuibile senza autorizzazione del licensor

2. L’utilizzatore riceve il software “as is”, senza alcun tipo di garanzia applicabile (no warranty)

3. Impedire qualunque tipologia di brevetto (patent) restrittivo delle facoltà del licenziatario

“If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.”






GPL: distribuzione

Due casistiche ben distinte:

redistribuzione del software in copia 1:1 (“verbatim copies”)

modifica del software o di parte di esso e successiva redistribuzione dell’applicativo modificato

GNU GENERAL PUBLIC LICENSE: TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

“This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The “Program”, below, refers to any such program or work, and a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term “modification”.) Each licensee is addressed as “you”.Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.





GPL: verbatim copies

È permessa la distribuzione di “copie esatte” del codice sorgente del Programma, con qualunque mezzo, a condizione che:

si aggiunga un’appropriata nota di copyright;

siano intatti gli avvisi sulla Licenza sulle le clausole non-permissive aggiunte in accordo con la sezione 7;

siano intatti gli avvisi circa l'assenza di garanzia;

sia fornita ai destinatari una copia della Licenza





GPL: modifica e redistribuzione

È possibile distribuire un'opera basata sul Programma, o le modifiche per produrla a partire dal Programma, nella forma di codice sorgente secondo i termini della sezione 4, ammesso che tu rispetti anche tutte le seguenti condizioni:

informazioni esaustive dell’avvenuta modifica, con indicazione della data

informazioni adeguate sulla Licenza e sulle condizioni aggiuntive (sezione 7)

rilasciare l’opera, nel suo complesso, sotto Licenza GPL

se l'opera ha delle interfacce utente interattive, ciascuna deve mostrare delle Adeguate Informazioni Legali





GPL: aggregazione e composizione

L’aggregazione di più componenti o software (o più programmi tra di loro) stabilisce un rapporto di utilizzo reciproco tra di essi;

non esiste una relazione funzionale stretta per cui l’aggregazione dei singoli componenti vada a formare un programma a sé stante;

“raccolta di software” all’interno di un unico supporto di memorizzazione o una locazione logica;

L'inclusione di un programma coperto da questa Licenza in un aggregato non comporta l'applicazione di questa Licenza alle altre parti dell'aggregato.

In molti casi è possibile distribuire il software coperto da GPL accanto ad un sistema proprietario. È necessario assicurarsi che i programmi liberi e i non liberi del sistema comunichino tra di loro ma siano tra di loro indipendenti





GPL: implementazione

Inserimento di una clausola all’inizio di ogni file sorgente (es. tramite blocco di commento o documentazione /** */ , in cui si indichi la natura GNU GPL del programma;

inclusione, nella struttura logica del programma (es. directories), di una copia in formato digitale della GNU GPL (testo ufficiale);

la nota di copyright deve comprendere l'anno in cui il programma è stato completato (quindi, se è stato completato nel 1998 ma non è stato pubblicato fino al 1999, bisogna scrivere 1998). Bisogna aggiungere l'anno per ogni versione: per esempio, "Copyright 1998, 1999 Rita Rossi" se alcune versioni sono state completate nel 1998 ed altre nel 1999. Se più persone hanno contribuito a scrivere il programma, vanno scritti tutti i loro nomi;

nel caso in cui sia stato prelevato codice da altro software in licenza GPL, includere anche le note di copyright dell’originale;

inserire le informazioni di contatto, fondamentali per permettere all’utilizzatore di comunicare con l’autore.





GPL: utilizzo di librerie

A “library” means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables.

La GPL non permette di incorporare componenti GPL all’interno di software proprietari. E’ espressamente vietato dal testo della licenza

Le librerie rilasciate sotto licenza GPL, dunque, sono incorporabili all’interno di un software che verrà poi rilasciato con un tipo di licenza compatibile

GNU Lesser General Public License più adeguata per tali casistiche





GNU Lesser General Public License

The GNU Lesser General Public License (LGPL) is another license created by the Free Software Foundation for the purpose of permitting a certain class of programs, generally subroutine libraries, to be licensed under an FSF license but be permitted to link with non-GPL software programs.

LGPL-licensed libraries can be linked with non-GPL licensed programs, including proprietary software.

Tipologia di licenza fondamentale per il programmatore: permette l’utilizzo di librerie di terze parti - fornite con LGPL - all’interno di software anche non dotati di licenza GPL

repository www.sourceforge.net





Libraries: dal punto di vista del programmatore

Qual è il tipo di licenza migliore da abbinare alle proprie librerie personalizzate?

Utilizzando GPL si inibisce l’utilizzo della libreria nei software proprietari, rendendola disponibile solo per gli applicativi free

La licenza GPL non risulta particolarmente indicata quando le funzionalità offerte dalla libreria sono largamente disponibili in altre librerie

Ad esempio, nel caso delle librerie C vi è larga disponibilità di LGPL: se il programmatore dovesse rilasciare la propria libreria in modalità GPL, gli sviluppatori di software proprietario - banalmente - se ne cercherebbero altre;

Viceversa, nel caso in cui la libreria sviluppata offra funzionalità uniche, rilasciarla sotto licenza GPL è decisamente produttivo dal punto di vista della comunità di sviluppatori: esisterà almeno un applicativo free con codice aperto che la utilizza;

La presenza di un buon numero di librerie GPL con funzionalità uniche, non disponibili con LGPL, darà un vantaggio notevole allo sviluppo del software libero





Use case: pdf generator iText libraries

Linguaggio utilizzato: Oracle Sun Java J2SE

iText ® is a library that allows you to create and manipulate PDF documents. It enables developers looking to enhance web- and other applications with dynamic PDF document generation and/or manipulation.

Developers can use iText to:

Serve PDF to a browser

Generate dynamic documents from XML files or databases

Use PDF's many interactive features

HTTP://ITEXTPDF.COM





Use case: pdf generator iText libraries

ITEXT LIBRARIES

ALTRE LIBRARIES

COMPILATO O ESEGUIBILE

CODICE SORGENTE

LINKER





Le librerie sono reperibili nel sito ufficiale http://itextpdf.com/ in formato .jar

Tale formato è diffusissimo in ambito java (ma utilizzabile anche in altri linguaggi ad oggetti)

L’archivio .jar è disponibile in due versioni:

bytecode, compilato Java. Il software importa (collega) le librerie e le utilizza

sorgenti. Oltre all’importazione, l’utente ha accesso ai files sorgenti e ha facoltà di modificarli in base alle proprie esigenze. Il sorgente risulta utile anche per operazioni di debug e risoluzione di problematiche di programmazione.

Use case: AGPL iText libraries





iText free è fornito con licenza AGPL

The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software

It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version


HTTP://WWW.GNU.ORG/LICENSES/AGPL.HTML





Lo scenario tipico è di utilizzo . in quanto tali librerie hanno un livello di maturità notevole

la modifica, tuttavia, non è esclusa ed è conseguenza diretta dell’appartenza della AGPL alla macrofamiglia delle GPL.

le librerie, dunque, risultano componente funzionale indispensabile per il software stesso

nel file binario (o compilato, o bytecode, o eseguibile) è incluso un collegamento alle librerie (linking dinamico)

Criticità:

in quanto componente di terze parti, le librerie sono integrabili nel pacchetto fornito all’utente?

con quale licenza?

con quali regole di utilizzo?






Although iText is a free/open source software (F/OSS) project, giving you a lot of freedom and flexibility regarding the use of the iText software, this doesn’t mean you're free to do anything you want with the product: you have to respect the Affero General Public License (AGPL)

DOWNLOAD SOURCES: rispetto alla GPL v2 prevede l’accesso al codice sorgente via network

If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.


HTTP://ITEXTPDF.COM/TERMS-OF-USE/

HTTP://WWW.AFFERO.ORG/OAGF.HTML






Come soddisfare i requisiti AGPL, per iText with free license?

fornire il codice sorgente del proprio applicativo

rilasciare l’applicativo con licenza compatibile

realizzare un collegamento ai sorgenti delle librerie iText, contenute all’interno di un file .jar (archivio java). Tipicamente, viene realizzato un pulsante di collegamento al sito del produttore nell’interfaccia di comando dell’applicativo.

includere, immutata, la licenza originale di iText;

tracciare eventuali modifiche sul codice originale di iText, nel caso in cui si sia intervenuto direttamente sui sorgenti per adattarli.





Esistono anche varie tipologie di licenze commerciali per iText

Tali licenze garantiscono caratteristiche differenti rispetto alla AGPL:

diritto al risarcimento nel caso di infrazioni relative alla proprietà intellettuale o al diritto d’autore

non è più obbligatorio osservare i vari obblighi derivanti dal copyleft imposto dalla AGPL, quindi non sarà più necessario:

distribuire il codice sorgente, incluso quello dell’applicativo;

licenziare il proprio software con AGPL;

la menzione e l’inclusione della nota di copyright di iText e della licenza AGPL originale;

fornire tracciabiltà delle modifiche effettuate sul codice originale

nei metadati del file pdf generato non risulta necessario mantere intatto il tag PDF Producer line (iText) , ma la personalizzazione è permessa

In abbinamento alla licenza commerciale, è acquistabile anche un contratto di assistenza personalizzato






Licenza X11 (o MIT)

Licenza di tipo permissivo, compatibile con la GPL

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the

Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall beincluded in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.





Caso d’uso: licenza X11 (o MIT)

PUTTY: implementazione gratuita dei protocolli Telnet e SSH, per client Windows e Unix

Licenza X11-MIT (Open Source certified)

”... anybody (even companies) can use PuTTY without restriction (even for commercal purposes) and owe nothing to me or anybody else. Also, apart from having to maintain the copyright notice and the licence text in derivative products, anybody (even companies) can adapt the PuTTY source code into their own programs and products (even commercial products) and owe nothing to me or anybody else. And, of course, there is no warranty and if PuTTY causes you damage you're on your own, so don't use it if you're unhappy with that.

In particular, note that the MIT licence is compatible with the GNU GPL. So if you want to incorporate PuTTY or pieces of PuTTY into a GPL program, there's no problem with that.”

HTTP://WWW.CHIARK.GREENEND.ORG.UK/~SGTATHAM/PUTTY/


CONSIDERAZIONI CONCLUSIVE





Quale tipologia di licensing?

La scelta della licenza opportuna richiede dunque considerazioni complesse e non va sottovalutata;

il punto di partenza per indirizzare la scelta sulla giusta strada può essere rappresentato dalla necessità di fornire o meno il codice sorgente;

è possibile affidarsi a licenze già esistenti appartenenti alle macrocategorie esaminate: in tal caso è importante ricordarsi che il testo della licenza originale non può essere modificato;

esistono casistiche in cui è possibile modificarle, avendone ben chiare le conseguenze. Tuttavia è questa un’operazione non semplice e financo pericolosa.





Licensing ad hoc?

Premessa dunque l’esistenza “sul mercato” di un gran numero di licenze, per l’azienda sviluppatrice di software risulta spesso conveniente realizzare licenze ad hoc per i propri software commerciali;

Deve essere garantita la riusabilità della stessa licenza e l’applicabilità in contesti software simili tra di loro;

spesso constatiamo poca attenzione nella predisposizione della propria licenza “homemade”, risultato di azzardati “taglia e cuci”: la creazione di licenze ad hoc va affidata a figure professionali operanti nell’ambito del Diritto informatico;

vale la pena, in alcuni (e forse in molti) casi, elaborare ex novo una propria licenza (o anche diversi modelli di licenza a seconda del caso).

Ciò permette di arrivare ad un risultato ottimale per le esigenze della società o del programmatore freelance, ad esempio prevedendo specifiche clausole di esclusione di responsabilità.





Padova, 5 maggio 2011 ore 15.30 :: Sala 3

Relatore: Ing. Igor Serraino

www.serraino.it

[email protected]

GRAZIE PER VOSTRA ATTENZIONE



Smau Padova 2011 Igor Serraino

Technology

Transcript of Smau Padova 2011 Igor Serraino