Licensing FOSS per profitto

Queste licenze non fanno quello che pensi che facciano. Purtroppo, la licenza GPL e simili sono ampiamente fraintese (anche da parte delle persone che le scrivono. Con ciò intendo che la legge spesso ha un'idea diversa di cosa significano i termini dati rispetto all'autore della licenza).

La GPL non ti preclude l'utilizzo in progetti proprietari. Molti progetti proprietari hanno dipendenze su applicazioni con licenza FOSS di biblioteche. Tutto ciò che fa è precludere il tentativo di spedire un codice binario senza fonte, o di applicare restrizioni aggiuntive su quei progetti.

Inoltre, se hai scritto il codice in primo luogo, anche se lo pubblichi sotto GPL, puoi fare tutto ciò che vuoi e fare qualsiasi eccezione che ti piace. Puoi anche smettere di produrre codice in quella licenza e produrre solo versioni con licenza proprietarie.

Tuttavia, per rispondere alla tua domanda. È diventato piuttosto "di moda" per le aziende pubblicare una versione "community" di un prodotto e una versione "enterprise". Gli esempi includono Vayatta, Alfresco, Flowplayer e molti altri.

L'idea è che chiunque abbia bisogno di supporto lo comprerà comunque, e quelli che non lo fanno non comprerebbero comunque il tuo programma. Quindi promuove una sorta di "buona volontà" anche se è solo uno schema.

La licenza GPL ha un paio di clausole / definizioni che non sono chiare al di fuori dell'ambito originale (programmazione C) che danno bruciore alle corporazioni.

1. Se estendi un progetto GPL sei responsabile di (a) pubblicizzare il fatto, fornire la licenza GPL ai tuoi utenti e (b) fornire una copia del codice sorgente a chiunque ne faccia richiesta . NOTA: una richiesta può essere richiesta per essere eseguita per iscritto, anziché renderla disponibile per il download.
2. Se si collega a una libreria GPL si è non estendendolo, quindi la clausola precedente non si applica. Il problema è che link significa cose diverse a seconda di chi stai parlando - ad esempio cosa significa in un linguaggio interpretato come Ruby?

È per la ragione di poter svelare segreti aziendali che la maggior parte delle aziende evita i progetti basati sulla GPL. Inoltre, potrebbero non esserci altri rischi di tipo legale / proprietario di cui non sono a conoscenza.

La doppia licenza non è rara. È un modo per garantire che il prodotto di base sia sempre disponibile, fornendo valore alle persone disposte a pagare per questo. Non è raro anche semplicemente scegliere una licenza FOSS che non contenga le clausole spaventose come la licenza ASL, MIT o qualche variazione. Dà alle corporazioni molto meno bruciore di stomaco per fornire attribuzione rispetto al codice sorgente. In breve, è meglio dire che il prodotto utilizza Apache Xerxes piuttosto che dover rilasciare il codice sorgente perché incorpora un parser XML GPL.

Ulteriori informazioni sul copyright americano Negli anni '90 ho partecipato a un seminario della durata di 2 settimane che riguardava la legge sul copyright, attinente all'industria dell'intrattenimento. Quel seminario è stato tenuto da uno dei più eminenti avvocati che si sono concentrati sull'argomento in quel momento: Al Schlessinger. Quello che segue è un breve riassunto delle informazioni di quel seminario (io stesso non sono un avvocato, sto solo ripetendo le informazioni):

1. Il copyright è proprietà reale, come nel settore immobiliare. Può essere comprata, venduta, lasciata in eredità e donata proprio come la terra può.
2. L'uso del materiale protetto da copyright è dettato dalle licenze, che a loro volta ottengono la loro applicazione dalla legge sui contratti. Una licenza è un contratto.
3. Se i termini del contratto a cui stai lavorando richiedono la revoca del copyright, ti trovi in una situazione di "lavoro a noleggio". È così che le case discografiche possono rovinare le band newbie a meno che non sappiano cosa cercare. Sono anche i record RCA fottuti su Prince.
4. GPL non converte il copyright dei proprietari del progetto GPL originale, ma specifica i termini per il uso dell'opera originale protetta da copyright. Essenzialmente, acconsentiresti a esporre il tuo codice sorgente a chi lo ha richiesto. Conservi ancora il copyright del lavoro derivato, ma non il lavoro originale da cui è stato derivato.

È per questo motivo che di fronte alla prospettiva di incorporare codici / librerie GPL o LGPL nella tua applicazione commerciale, controlli tutto con un avvocato specializzato in questo tipo di lavoro. Esistono, e la mia precedente azienda ne usava una per scoprire i rischi legali. Gli avvocati hanno sottolineato i potenziali problemi, che abbiamo dovuto trasmettere al nostro cliente.

Il punto dolente per la doppia licenza è che l'entità che sta licenziando il lavoro deve essere in grado di dimostrare di avere l'unico copyright per il lavoro. Questo è il motivo per cui quando diventi un committer su alcune delle più grandi organizzazioni ombrello (GNU, Apache, ecc.) Ti viene richiesto di firmare un accordo per il trasferimento del copyright di quel codice a quell'organizzazione. Una volta soddisfatta tale condizione, l'organizzazione può concedere una doppia licenza, modificare il modello di licenza o qualsiasi altra cosa debbano fare a proprio piacimento.

È perché c'è abbastanza Paura, Incertezza e Dubbio (FUD) che circondano la GPL su entrambi i lati dell'equazione, che recentemente c'è stata più spinta a usare modelli di licenze amichevoli per le aziende.

Il progetto che hai derivato dal tuo lavoro può gridare male e affermare che stai violando i termini della licenza? Sì. Lo faranno? Probabilmente no. Ciò non significa che dovresti comunque violare in modo flagrante i termini.