Qual è la risposta canonica a "Non puoi inviare una patch a questo progetto open source perché non sei un committer"?

Il problema degli attacchi dei brevetti verso FOSS è reale. Alcuni progetti, come quelli della Apache Software Foundation , richiedono ai contributori di qualsiasi tipo di firmare un contratto in cui il contributore si assume tutte le responsabilità in caso di contenzioso (in realtà, dichiari che i tuoi contributi sono in buona fede e legali).

Questo tipo di accordo contrattuale può sembrare duro per qualcuno che vuole solo contribuire, ma farlo in questo modo protegge la comunità e il software:

1. Non c'è una grande organizzazione da citare in giudizio.
2. Le responsabilità individuali si diluiscono man mano che il software viene modificato.
3. La community viene protetta dai contributi dannosi.

Il caso SCO ha dimostrato che il FOSS può essere l'obiettivo di attacchi legali (ingiusti) e che i progetti adottano il significa che trovano il modo migliore per proteggere il loro lavoro. Il caso SCO riguardava il copyright; i casi di brevetto dovrebbero essere ancora più complicati.

Aziende come IBM hanno contribuito a proteggere FOSS con cui sono coinvolte, distribuendo brevetti, rassegnando le dimissioni ad altri e mantenendo un solido portafoglio che concedono in licenza selettiva a progetti FOSS.

Dovresti sempre essere in grado di inviare una patch, e poi spetta a un maintainer decidere se la patch debba andare nel repository.

Se non vogliono l'invio di patch, devono scrivere tutto da soli. Alcuni lo fanno, ma quelli sono raramente quelli che fanno la maggior parte delle versioni.

Che ne dici di "Perché devo essere un committer per proporre una patch? C'è qualcosa che possiamo fare al riguardo?" I progetti vengono eseguiti in modalità cattedrale per motivi. Potrebbero essere cattivi motivi, ma devi conoscerli se vuoi cambiare la mente di qualcuno.

Sospetto che alcune delle risposte più comuni siano probabilmente:

• "Come ti aspetti di ottenere un progetto open source da zero se non sei aperto alle richieste inviate dalla community?" (Questo non è molto utile, ma probabilmente comune ...)
• "Quale modulo dovrei compilare per assegnare il copyright a [uno degli sviluppatori / qualche organizzazione fidata]?" (La FSF usa questo metodo per mantenere pulito il loro IP)
• Fai come si dice e inizia una discussione su listserv / pubblica un ticket e spera che risolvano da soli il tuo problema.
• Per prendere un risposta da una domanda correlata: puoi eseguire il fork del progetto (e pubblicarlo pubblicamente con una politica di invio più aperta o semplicemente mantenere un fork locale solo per te). Sfortunatamente, è probabile che funzioni troppo se vuoi inviare solo una (o alcune) patch.

Se nessuno dei precedenti sembra essere appropriato (o semplicemente non funziona), la migliore linea d'azione potrebbe essere semplicemente fingere che il progetto non esista e cercare un'alternativa.

Il mio personale sospetto (e speranza) è che qualsiasi progetto open source almeno moderatamente popolare, eseguito in questo modo per un certo periodo di tempo, finirà per forgiare una volta che abbastanza "outsider" si stancano abbastanza del loro atteggiamento per fare qualcosa al riguardo.