Ti importa che un software sia "sorgente disponibile" ma non "open source"

Probabilmente conosci l'elenco delle licenze open source ufficialmente approvate dall'OSI. In particolare, suppongo che sarebbe GPL, MIT, [inserisci qui la tua licenza preferita].

Di recente mi sono imbattuto in un progetto che, sebbene fosse open source (il creatore ha reso disponibile tutto il codice sorgente), non era ufficialmente open source con una di quelle licenze ufficiali.

• Ha rilasciato la fonte, ma non ha promesso di rilasciare la fonte in futuro.

• Consentiva suggerimenti di modifica, ma non prometteva di accettare patch e non consentiva la distribuzione esterna di versioni con patch esterne.

• Ha consentito l'uso del software in progetti commerciali o a pagamento, ma non ha consentito la vendita del software stesso.

Suppongo che potrebbe essere chiamato "fonte disponibile" non open source come ci piace pensarci.

Vedo perché il team di gestione di un'azienda non vorrebbe fare affari con questo software. Non possono fork, non possono venderlo, non possono creare la propria versione del software e distribuirlo o venderlo.

Ma ti importerebbe come parte di un team di ingegneri del software che sta solo usando questo software? Posso ancora fare il mio lavoro con esso, posso usarlo in un progetto per il quale sono pagato (ma non posso vendere il software stesso, che comunque non mi occupo di fare), e posso apportare modifiche al codice per farlo comportare diversamente per le mie esigenze (ma non posso renderle pubbliche), e se voglio che tali modifiche siano rese ufficialmente disponibili per gli altri, l'approvazione dipende dal progetto stesso e loro scelgono se incorporarli in una versione ufficiale o meno.

Quindi sappiamo che una società che vuole basare la propria attività su questo software "fonte disponibile" non può farlo, ma come qualcuno del team di ingegneria del software, queste differenze contano per te o sembrano meno rilevanti?

Curioso ciò che gli altri pensano di questo.

Per i progetti che avrebbero dovuto sviluppare da zero le funzionalità fornite da questo software, è una comodità definitiva non farlo.

Ma se un pacchetto open source comparabile sarebbe meglio dipende da altri fattori:

• verrà utilizzato per fornire un servizio o raggrupparlo come parte di un altro prodotto?
• hanno le risorse per migliorare e mantenere il prodotto in modo indipendente?
• esiste un vantaggio competitivo utilizzare questo software rispetto alla versione open source (nel codice o nella gestione del progetto)?

Rispondere no a uno di questi fattori indica che l'OSS è una scelta migliore.

Il più delle volte, il codice stesso non è il fattore determinante. È necessario esaminare il quadro più ampio.

I progetti OSS SIDEBAR non possono legalmente promettere che terranno aperte le versioni future o che ci saranno versioni future. Questo è uno dei motivi per cui avere una licenza aperta è così vantaggioso. Inoltre, i progetti OSS non sono tenuti ad accettare patch dai collaboratori (in particolare senza trasferimento di proprietà o diritti).

La domanda per questa e ogni altra libreria esterna è la manutenzione .

Qual è la durata della tua applicazione e qual è la durata apparente di questa libreria? Speriamo che il tuo sia il più corto.

Chi eseguirà le correzioni di bug per questa libreria? Come sembra da qui, la tua azienda dovrebbe allocare esplicitamente risorse in futuro per la manutenzione di questo software, poiché non puoi fare affidamento su altri bug corretti per te. Non è possibile condividere l'onere di manutenzione con nessun altro in quanto non è possibile condividere la fonte. Vuoi dare la caccia a un bug di condizione di gara inafferrabile nel codice che non conosci?

Questo solo pensiero potrebbe rendere la biblioteca troppo costosa da usare.

Ciò potrebbe essere irrilevante se la libreria è molto solida, robusta e facile da lavorare a livello di sorgente, ma la mia esperienza è che la pressione dei pari dei veri progetti open source rende semplicemente il codice migliore perché in quel momento tendi a fare del tuo meglio.

Personalmente penserei molto attentamente se adotterò questo o qualsiasi altro codice esterno, poiché l'intera ragione per usare il codice di altre persone è che non devi occupartene da solo . Pensa anche ai futuri manutentori: dovresti fare esercitazioni antincendio modificando il codice nella libreria per vedere se può essere fatto affatto. Ci potrebbero essere alcune brutte sorprese qui.

Sei libero di discutere della biblioteca in questione?

Ad essere sincero, non vedo perché il team di gestione di una società abbia dei problemi con l'utilizzo di una libreria "fonte disponibile". Per quanto riguarda l'integrazione nel proprio prodotto, possono semplicemente considerarlo come una libreria di origine chiusa.

Per me, come programmatore, non importa se una libreria è "open source" o "disponibile". Preferisco non apportare modifiche locali a una libreria esterna, perché ciò comporta un ulteriore onere di manutenzione. Non solo quando vengono rilevati dei bug nelle mie modifiche locali, ma anche sull'integrazione delle modifiche ancora e ancora quando esce una nuova versione della libreria.

Le uniche situazioni in cui, IMHO, "open source" supera la licenza "disponibile" descritta nella domanda è quando

• la licenza del nostro prodotto richiede anche la divulgazione delle fonti delle librerie contenute
• stiamo lavorando alla produzione di una versione migliorata / estesa della biblioteca

Questo è il motivo per cui la Free Software Foundation usa i termini "libero" o "non libero" per descrivere il software. Non si riferiscono al prezzo, ma alle restrizioni poste sull'uso o sulla distribuzione del software.

Sembra che tu abbia colpito uno dei rari casi d'angolo in cui hai pieno accesso al codice sorgente di qualcosa, ma il software non è "Open Source" dalla definizione OSI .

Entrambi i termini hanno la capacità di diventare un termine improprio. Ho pagato $ 50 per la mia prima copia di emacs (su nastro QIC), ma emacs è un software gratuito . Ho il codice sorgente di alcune applicazioni proprietarie che la mia azienda utilizza internamente, ma non sono open source.

La cosa che solleva la bandiera rossa più grande (almeno per me) non è una garanzia di accesso al codice sorgente delle versioni future. Se dipendi fortemente dalla possibilità di modificare questo strumento, starei attento. Anche se hai un accordo verbale con il venditore, avrai sempre il codice, a meno che non sia in forma di contratto .. quell'accordo non è mai successo.

Come CTO, faccio del mio meglio per garantire che non dipendiamo da software non libero. Sono stato in una brutta fine del blocco dei fornitori diverse volte in passato, un errore che mi piace evitare. Mentre utilizziamo alcune cose proprietarie, la nostra attività non subirebbe inutili difficoltà se all'improvviso non potessimo più utilizzarle.

Mi sembra che tu stia costruendo cose intorno a questo software e ad accedere al codice, quindi ti consiglio di ottenere qualcosa per iscritto che dica che avrai sempre accesso. Cosa succede se il venditore viene acquistato?

Questo è abbastanza importante. Principali problemi con l'approccio "fonte disponibile" che hai descritto:

• Non hai il controllo del tuo destino tecnologico se non hai la libertà di modificare la fonte. Spesso l'hacking della fonte può essere preferibile a una soluzione disordinata.
• Non hai alcuna garanzia che il software continuerà a essere mantenuto e non hai l'opzione di fallback di farlo tu stesso che ottieni con vero open source.
• Dal momento che sembra una licenza personalizzata, probabilmente hai un rischio legale maggiore rispetto all'uso di qualcosa di ben noto e provato come le licenze GPL o BSD.
• Se non è un vero open source, non otterrai lo stesso livello di comunità utile attorno ad esso, il che è un grande vantaggio per molti progetti open source

Il mio consiglio: prova a convincere il creatore a rilasciare il software con una licenza open source. Dovrebbe essere una vittoria / vittoria per tutti - tu perché ottieni il software che desideri con le licenze open source, il creatore perché rendere il progetto open source probabilmente renderà il software molto più efficace nel lungo periodo.