Devo consegnare il mio codice di utilità e di supporto ai client?

Innanzitutto, si tratta principalmente del contratto che hai con il cliente. Se hai un contratto che include la consegna del codice sorgente, il tuo cliente può aspettarsi un codice sorgente che può compilare da solo. Se rifiuti di farlo, hai rotto il contratto - e non importa se la fonte mancante in lib A o lib B o lib "Utility". Dal punto di vista del cliente, non vi è alcuna differenza tra queste parti.

Se hai escluso in modo specifico alcune librerie nel tuo contratto (e il tuo cliente è stato abbastanza stupido da firmare), allora potresti legittimamente rifiutarti di consegnare la tua fonte per tali librerie, ma non aspettarti di mantenere il cliente in futuro .

Se vuoi evitare quella situazione in futuro, separa chiaramente la tua biblioteca di utilità nel tuo contratto e prova a venderla / concederla in licenza ai tuoi clienti come prodotto a sorgente chiusa, insieme alle fonti del prodotto principale che sei creando per loro. Ciò implicherà ovviamente il controllo delle versioni e la gestione della configurazione della tua utitlity, naturalmente.

Se il contratto si aspetta che il codice sorgente sia consegnato, il codice sorgente che gli hai fornito dovrebbe essere compilato.

Non dare loro le librerie per farlo è ridicolo.

Se il codice nelle tue librerie è un codice generico di tipo helper, non c'è niente di sbagliato nel dargli i binari e qualche accordo di licenza con loro.

Se le librerie contengono qualcosa di specifico su come è costruito il sistema, allora il cliente avrà il diritto di aspettarsi di ricevere quel codice. Potrebbe essere necessario modificarlo ad un certo punto, ad esempio.

Probabilmente devi fare una versione della tua libreria proprietaria e creare delle versioni (interne). Quindi, quando avvii un nuovo progetto, utilizzi la tua ultima libreria rilasciata in quel progetto e esegui l'aggiornamento a una nuova versione quando necessario.

Quindi puoi inviare la fonte al tuo cliente, incluso il contenitore della tua libreria nella versione con cui hai testato il progetto.

Per aggiungere a ciò che ha scritto bjarkef, dovresti avere un processo di compilazione automatizzato, in modo che le tue librerie siano costruite automaticamente.

Dovresti etichettare le versioni stabili delle tue librerie, codice sorgente e binari (jars).

Quando distribuisci un prodotto basato sulle tue librerie o su librerie di terze parti, dovresti includere i binari (giare) di tutte le librerie con cui lo hai testato all'interno del tuo rilascio.

Ci sono alcuni progetti open source che non distribuiscono le loro dipendenze di terze parti insieme alla loro distribuzione, tuttavia questa è una pratica molto negativa.

Il tuo cliente ha il diritto di insistere sulla ricezione di prodotti completi e di non iniziare a cercare la versione corretta di tutte le tue dipendenze.

Se il client è effettivamente interessato solo sul codice che è compilabile, considera di creare e passare loro "stub" che non funzionano ma implementano le interfacce necessarie per la compilazione del codice:

public class MyClass {
    public void myMethod() {
        throw unsupported();
    }
    private UnsupportedOperationException unsupported() {
        return new UnsupportedOperationException(
                "stub code intended to use only in compilation");
    }
}