Ciao, sono nuovo alla programmazione e mi sono sempre chiesto quale sarebbe il punto di contribuire con i codici open source se non c'è modo di garantire che tutti coloro che usano il codice aderiranno alle licenze (o c'è? ).
Ciao, sono nuovo alla programmazione e mi sono sempre chiesto quale sarebbe il punto di contribuire con i codici open source se non c'è modo di garantire che tutti coloro che usano il codice aderiranno alle licenze (o c'è? ).
Per molte persone, è vanità, far associare il tuo nome a qualcosa di eccezionale (ecco perché i piccoli progetti OSS tendono a rimanere piccoli, e quelli grandi tendono ad avere processi molto rigorosi per controllare potenziali nuovi submitter, semplicemente vengono inondati da applicazioni da tutti e il loro cane).
Per gli altri, è un tentativo di convincere gli altri a fare il loro codice per loro. Getta un'idea semi-elaborata su sourceforge (ad esempio), esagera usando alcuni account con altri nomi su slashdot (ad esempio), e siediti e aspetta che il codice entri (che di solito fallisce, ma le persone continuano a tenere provandolo dopo tutti questi anni).
Poi ci sono persone (e di solito aziende) che hanno qualcosa che hanno sviluppato in casa per uso interno e pensano che sarebbe utile per il mondo in generale, ma non hanno il tempo, i soldi, le persone, qualsiasi cosa per lucidarlo per la vendita e / o per la commercializzazione (forse è qualcosa che non si adatta bene al loro portafoglio prodotti esistente, ad esempio). Lo hanno messo lì come open source, usando una fondazione o altra entità legale creata allo scopo come front-to-own e supervisionando lo sviluppo, rifornita inizialmente del proprio personale e rendendola nota (buon marketing) che sponsorizzano fondazione (ospitando il suo sito Web e consentendo ai dipendenti di dedicare parte del loro orario di lavoro).
E poi ci sono i veri altruisti, le persone con la testa bloccata in nuvole rosa se lo desideri, che lo fanno per il senso di "tutto dovrebbe essere libero" (senza considerare che possono solo contribuire a quei progetti perché hanno un lavoro facendo esattamente la stessa cosa per pagare).
Quelli insieme sono probabilmente il 90% + dei contributori a progetti open source. Problemi legali come gli altri che usano parte di quel codice nei loro progetti closed source non contano per la maggior parte di essi, almeno non più di una fastidiosa sensazione da qualche parte. E non è davvero un gran problema. Se vedi la maggior parte delle licenze open source non c'è alcuna restrizione sull'uso commerciale della libreria o del prodotto open source come parte di qualcos'altro. Molti chiedono di riconoscerli se lo fai, ma nemmeno di tutti loro.
E dubito seriamente che la situazione che descrivi si manifesti tanto. La maggior parte dei progetti open source non è molto adatta per questo, sia che si tratti di librerie strettamente raggruppate o di prodotti completi (e la maggior parte di quelli non molto maturi, anche se i migliori sono molto buoni), quindi lo sforzo necessario per estrarre pezzi utili per il tuo uso personale e la splicing di quelli nel tuo prodotto sono probabilmente superiori allo sforzo necessario per creare la funzionalità da zero (magari utilizzando la fonte OSS come fonte di ispirazione o guida).
Non dare per scontato che non sia possibile rilevare che un binario compilato è una copia del codice di qualcun altro.
Per cominciare, tutti i valori letterali di stringa passano attraverso il processo di compilazione invariato. Se un programma closed-source ha un sacco di letterali stringa che corrispondono a quelli di un progetto open-source, allora è destinato ad aumentare i sospetti.
Dopodiché, ci sarà qualcuno, da qualche parte, che è abbastanza ossessivo da decompilare / decodificare il codice per capire che sta facendo le stesse cose della libreria open source.
Se il codice open source proviene da un grande progetto, la prossima cosa è che ricevi una lettera dai loro avvocati, suggerendo che potresti voler aprire il progetto che contiene il codice che hai copiato. Se non si riesce a farlo, il passo successivo è una causa. Durante la fase di scoperta, ti chiederanno di presentare al tribunale il tuo codice sorgente, per dimostrare che non è solo una copia di loro.
Se perdi il caso giudiziario, potresti vedere i rimborsi dei danni e essere costretto a ritirare il tuo prodotto dal mercato.
Penso che il modo in cui definisci la domanda misuri insieme due cose diverse: perché dovresti contribuire a un progetto open source e come una licenza open source può essere applicata quando i binari vengono distribuiti. Il punto di contribuire a un progetto open source è di contribuire al progetto e le persone lo fanno per tutti i tipi di motivi. La seconda domanda è la più interessante.
Ci sono molte diverse licenze open source e alcune, soprattutto la GPL, proibiscono l'incorporazione in software proprietario (closed source) che viene distribuito e viene fornito con una serie di regole da seguire se il codice viene ridistribuito (si potrebbe avere qualcosa in cui il codice GPL è parte di ciò che è distribuito ma non è effettivamente incorporato nell'applicazione proprietaria.). Quindi, come viene applicata la GPL in generale? Anche per il codice che è in PHP o Javascript che non esce nei binari è ancora possibile porre la domanda. Il modo in cui viene applicato è che potrebbe esserci un whistle blower internamente, un cliente può segnalare sospetti o l'autore del codice può diventare consapevole dell'altro codice ed essere sospettoso su di esso per qualche motivo. (@ Simon-barker ha indicato alcuni dei modi in cui è possibile indagare sul codice sospetto.) In altre parole, è proprio come qualsiasi altro tipo di errore, probabilmente ci sono molti incidenti non segnalati ma alcune istanze vengono scoperte.
A quel punto potrebbero accadere cose diverse. La maggior parte dei progetti più grandi ha squadre o singoli individui che si occupano di investigare i problemi di licenza o che uno sviluppatore individuale potrebbe dover gestire da solo. Di solito il modo in cui il processo dovrebbe funzionare è come qualsiasi altra questione legale civile. Prima c'è una lettera approvata o redatta da un avvocato inviata agli autori del codice sospetto dall'autore o dal progetto. Poi c'è una lettera approvata da un avvocato che risponde. Questo può risolvere l'intera cosa a volte. Ad esempio, forse dicono "Abbiamo ripulito il codice della camera pulita e qui è disponibile la nostra documentazione". oppure "No, il nostro codice in realtà fa qualcosa di diverso o ha una firma diversa" o "È giunto alla nostra attenzione che, a noi ignoto, un appaltatore ha usato un codice simile al tuo. la sua licenza, e questo è stato specificato nel contratto. L'abbiamo rimosso e rilasciato un aggiornamento a tutti i clienti, e quell'appaltatore non lavora più con noi. " Quindi lo sviluppatore originale e l'avvocato decidono come rispondere. E così via. In rari casi essi possono procedere ad un deposito giudiziario effettivo e avere una fase di scoperta. In una fase di scoperta un giudice può richiedere che il codice sorgente sia condiviso.
Molte volte con violazioni GPL la violazione non notifica ai clienti che hanno diritto a una copia del codice, aggiungendo un EULA inappropriato, mancata inclusione di una copia della licenza o distribuzione di versioni obsolete quando i clienti chiedono per le copie.
Molte licenze open source permissive richiedono che le informazioni di licenza originali siano incluse nel codice, quindi non è solo la GPL che ha questo tipo di problemi.
Contribuire a progetti open source è, almeno a mio parere, una cosa molto idealistica da fare. Gli idealisti credono nel bene delle persone - e questo significa che gli altri non rubano il codice sorgente per copiarlo e incollarlo nei loro progetti closed source.
D'altra parte, musica, film, libri possono anche essere facilmente copiati e non ha (ancora) impedito agli artisti di pubblicare nuove cose.
Per alcune licenze è possibile rilasciare i binari a sorgente chiusa. Queste licenze sono conosciute come "permissive". I fautori di queste licenze credono che gli utenti a valle contribuiranno con correzioni di bug o funzionalità appropriate perché è un modo più efficiente di mantenere il codice. Questo è l'incentivo a condividere è economico e guidato dal processo.
Un'altra categoria di licenze (copyleft debole) consente la distribuzione binaria in quanto non ci sono modifiche in quel codice. Questo è più comunemente usato per le biblioteche. In questo caso c'è lo stesso driver economico e di processo, ma è supportato da un requisito legale per il rilascio del codice sorgente delle modifiche.
La categoria finale è il copyleft che utilizza la legge per richiedere la pubblicazione di tutte le fonti se include un codice copyleft. I driver economici e di processo esistono ancora qui, ma i sostenitori del copyleft (e del copyleft debole) tendono a credere che non sia sufficiente senza la legge aggiungere i denti alla discussione.
L'open source non significa necessariamente che il codice non possa essere portato in closed source. Ci sono due tipi di scuole di pensiero su questo: alcune licenze come la famiglia di licenze BSD e MIT permettono che, data l'attribuzione di alcuni è stato fatto. E questo è usato - Microsoft per esempio ha usato lo stack TCP / IP di BSD per molto tempo in Windows (penso che sia Windows 95 e XP). I motivi ci sono che la gente pensa che sia fantastico che il loro codice funzioni in così tanti posti e sia felice di rendere il mondo migliore. Permette di aiutare a garantire che le implementazioni TP / IP di diversi sistemi siano compatibili. Parte del pensiero è che anche se alcuni prodotti a codice chiuso includono questo codice, la versione aperta sarà più attraente. In questo lato i creatori e gli utenti sono abbastanza uguali e hanno entrambi abbastanza poca familiarità nell'usare il codice.
L'altra scuola di pensiero riguarda la licenza GPL della Free Software Foundation. Qui il pensiero è che assicurare "la libertà" del software è più importante della disponibilità onnipresente. La libertà è che il codice sarà sempre disponibile per tutti e quindi l'utente può sempre correggere i bug e continuare a utilizzarlo anche se il venditore va giù.
Ora in entrambi i casi l'inserimento del codice in altri software può essere illegale (con attribuzione BSD mancante ecc., con GPL che non rende il software GPL ecc.). Questo potrebbe non essere visto spesso, ma l'analisi binaria o anche il test di funzionalità possono dimostrare che il codice è stato incluso e che è possibile intraprendere un'azione legale. link documenta i casi in cui questo è il caso e fornisce assistenza legale.
Leggi altre domande sui tag open-source licensing