Klient chce kodu źródłowego, ale zawiera dużo kodu współdzielonego, którego używam ponownie w innych projektach

Mam klienta, który chciałby, żebym dostarczył kod źródłowy z opracowaną aplikacją binarną. Pierwotnie nie powiedzieli nic o kodzie źródłowym, ale ostatnio powiedzieli, że go potrzebują. Umowa nie została sfinalizowana. Zgodzili się na pracę, nie podpisali, a następnie wrócili z tą klauzulą.

Problem w tym, że: Mam bazę kodu, którą tworzyłem przez lata i używałem jej jako szablonu dla większości aplikacji, które piszę. Jest znacznie większy niż zakres projektu.

Zamierzam również użyć go jako produktu, więc tak naprawdę nie chcę oferować go dla stosunkowo małego projektu.

Zgaduję, że nie jest to pierwszy raz, gdy miało to miejsce w tej branży. Jaki jest najlepszy sposób na obejście tego problemu? Zgaduję, że takie rzeczy, jak biblioteki wspólne, mogłyby pomóc.

Pierwszą rzeczą, o której należy pamiętać, jest to, że kod źródłowy ma wartość oddzielną od plików binarnych. Całkowicie uzasadnione jest odmowa podpisania umowy wymagającej dostarczenia kodu źródłowego lub naleganie na dodatkowe opłaty za dostarczenie kodu źródłowego. Umowy są dokumentami dwustronnymi. Nie pozwól, aby druga część dyktowała to, co jest wymagane tylko dlatego, że są to „duże firmy” i „robią to cały czas”. Po pierwsze, decyduje, jakie ty są skłonni dostarczyć i jak ty chcesz być zrekompensowane. Następnie zanieś umowę do prawnika i ustal, co należy zmienić. Następnie negocjujesz.

Nie rób tego, co robi wielu młodych ludzi, kiedy zaczynają się kontraktować. Nie podpisuj się, bo wygląda na to, że mają duże doświadczenie, a ty nie. To dobry sposób na oszukanie.

Sprawdź, dlaczego chcą źródła. Mogą tego chcieć, aby mieć później możliwość korzystania z innego programisty. Lub mogą tego chcieć tylko dlatego, że obawiają się, że autobus może cię potraktować, a nagle otrzymają binaria, których nie mogą poprawić. Jeśli jest to drugi przypadek, zajrzyj do usługi Software Escrow Service . Usługi te przechowują kod źródłowy na wypadek bankructwa lub niemożności utrzymania oprogramowania. Może to zaspokoić zarówno Twoje pragnienie zachowania własnego kodu do obsługi innych klientów, jak i ich pragnienie, aby nie zostawiać torby z niemożliwym do utrzymania zestawem plików binarnych, jeśli wydarzy się coś złego.

„Nie” to idealnie dobra odpowiedź, w rzeczywistości jest to niezwykle przydatna odpowiedź, która z jakiegoś powodu, którego nie rozumiem, jest bardzo niedoceniana.

„Cześć, zdecydowaliśmy nagle, że po prostu chcemy również kodu źródłowego, bezpłatnie”.
„Cześć, nie.”

To naprawdę nie jest takie trudne.

Następnie, jeśli chcą płacić skandaliczne kwoty pieniędzy na to, co już ci winien, może dać im przyciętą wersję aplikacji, która obejmuje tylko źródła rzeczywiście potrzebne, a dbanie uzyskują absolutnie non praw zwykłej lub na wyłączność.

Nie komplikuj prostych rzeczy.

Twoje pytanie brzmi: „jaki jest najlepszy sposób na obejście tego problemu?” Ale co uważasz za problem? Inni słusznie zauważyli, że jest to kwestia negocjacji: wszystko ma wartość i od klienta zależy cena za dostarczenie tego, o co prosi.

Ale musisz również dokładnie rozważyć - i zapisać w umowie - konsekwencje dostarczenia kodu. Czy to po to, żeby klient mógł to zobaczyć? Czy klient może to zmodyfikować? A w szczególności, czy zastanowiłbyś się nad przyznaniem klientowi wyłącznych praw do bazy kodu, którą stworzyłeś przez lata i jest używany jako szablon dla większości aplikacji , abyś nigdy więcej nie mógł używać go w przyszłości?

Musisz upewnić się, że umowa wyraźnie określa, kto ma prawa do korzystania z kodu i w jaki sposób.

Pamiętaj, że każdy kod źródłowy wymaga licencji. Jeśli przekażesz kod źródłowy, firma może użyć kodu źródłowego, aby zrobić wszystko, na co pozwala licencja, a wszystko inne poza tym stanowi naruszenie praw autorskich. Tak więc, jeśli przekażesz kod źródłowy, będziesz mieć umowę, która absolutnie wyjaśni, że zachowasz wyłączne prawa autorskie do kodu źródłowego i dokładnie, jakie zastosowania kodu źródłowego są dozwolone. I oczywiście kod źródłowy + licencja nie przyszedłby za darmo.

Duże przedsiębiorstwo raczej nie naruszy twojego prawa autorskiego, ponieważ złapanie go spowoduje poważną szkodę dla jego reputacji, oprócz szkód finansowych. Z drugiej strony, płacenie za oprogramowanie bez gwarancji, że jakiekolwiek problemy zostaną naprawione w przyszłości, może być nie do przyjęcia dla klienta.

Wcześniej zwykle dostarczałem klientowi kod źródłowy (biblioteki i wszystkie) na podstawie licencji MIT. Jeśli twoje biblioteki są dobrze zorganizowane, udostępniasz tylko potrzebne pliki / zasoby dla tego konkretnego klienta, ale nic więcej. Myślę, że jest to sprawiedliwe zarówno dla mnie, jak i dla klienta. Jednak zawsze pojawiał się problem z nowym kodem napisanym dla tego konkretnego klienta na podstawie umowy, który wcześniej nie był częścią biblioteki. Zacząłem więc omawiać ten problem z klientem przed rozpoczęciem projektu. Niektórzy klienci chcieli własności tego kodu, inni nie (zawsze dawałem negatywne zachęty, takie jak wyższe ceny dla tych, którzy to robią). Ale tak naprawdę dla niektórych klientów dyskusja była bardzo myląca, a czasem rozmawiałem z 3 lub 5 różnymi osobami (w tym ich prawnikiem), aby zatwierdzić projekt.

Więc teraz wszystkie moje biblioteki są częścią niestandardowego frameworka, którego zawsze używam do tworzenia i wyjaśniam klientowi, że będę korzystać z tego frameworka, ale frameworkiem jest inny produkt z inną licencją. (Czasami używam „komponentów oprogramowania” do wyjaśniania, ponieważ „framework” może być dla nich nieznany). Zawsze dostarczam kod używanych plików na licencji MIT i (ponieważ cały kod jest dobrze zorganizowany) kod niskiego poziomu (nawet nowy) pozostaje w ramach (do ponownego wykorzystania przeze mnie i przez nich), ale kod odnoszący się do ich aplikacji należy wyłącznie zachowanie ich na własnych warunkach (ten kod najprawdopodobniej byłby dla mnie bezużyteczny do ponownego użycia w innym projekcie). Oczywiście wszystko to jest poprawnie zapisane w umowie. Myślę, że to też jest sprawiedliwe.

Kluczem jest: „te elementy są innym produktem” i wszystko jest zapisane w umowie przed rozpoczęciem.

Więc tak, pomysł na korzystanie z bibliotek współdzielonych może mieć rację. Pytam jednak, dlaczego nie podasz im kodu źródłowego, którego użyłeś, na podstawie licencji, która pozwoli im zmniejszyć ryzyko? Myślę, że to byłoby sprawiedliwe.

Sposobem na poradzenie sobie z tym jest negocjowanie.

Jeśli chcą kodu źródłowego, powinni być przygotowani, aby za niego zapłacić, i to Ty decydujesz, ile to powinno być.

Z drugiej strony ... jeśli nie są gotowi zapłacić tego, czego chcesz, mogą zdecydować się na „przeniesienie swojej działalności w inne miejsce”.

Witamy w świecie biznesu :-)

A kiedy będziesz rozmawiać z potencjalnymi klientami w przyszłości, pamiętaj o tym wcześniej ... aby uniknąć marnowania czasu każdego.

Warto również zauważyć, że to, co robisz, jest anatemą dla programistów open source i (wykształconych) klientów, którzy szukają rozwiązań open source.

Może to być dla ciebie za późno, ponieważ być może już zgodziłeś się na to w umowie i mógłbyś zgodzić się na wzajemnie niezgodne warunki z różnymi klientami.

Istnieją dwa sposoby dostarczenia klientom kodu źródłowego. Własność praw autorskich i licencja.

Niektórzy klienci będą chcieli własności kodu źródłowego. Oznacza to, że pod koniec procesu zapłacą ci pieniądze, aw zamian przekażesz im prawa autorskie do stworzonego dla nich kodu. Jednym z powodów jest to, że widzą znaczny potencjał własności intelektualnej w kodzie źródłowym i mogą chcieć wycenić to w bilansie swojej firmy. W tym scenariuszu nie będziesz mieć prawa do dalszego korzystania z tego kodu źródłowego w innych projektach, chyba że uzyskasz również licencję od swojego klienta, która daje ci to prawo.

Jeśli Twój klient kupuje od ciebie produkt „z półki”, oczekuje, że otrzyma licencję na korzystanie z oprogramowania, a nie własność kodu źródłowego. Powinny spodziewać się, że sprzedajesz to samo (lub podobne) oprogramowanie wielu innym organizacjom i, mam nadzieję, że korzystają one z niższych kosztów zakupu dzięki szerszej bazie klientów.

Jednak sytuacja w tym pytaniu jest mieszanką tych dwóch.

Oto, co chciałbym móc zrobić. Udzielę klientowi licencji na wykorzystanie (i modyfikację) wspólnego kodu. Jeśli klient zapyta mnie o to, zwracam uwagę, że jest to kod współdzielony, który był już używany w wielu projektach i ma aktualne oferty na przyszłe prace, które są oparte na dalszym korzystaniu z tej pracy. zwróć uwagę, że spowodowało to mniej czasu na ten projekt dla twojego klienta i że w rezultacie zapłacili niższą cenę. Podobnie jak inne współdzielone biblioteki kodu używane w projekcie, mają one licencję na używanie tego kodu i zezwalanie innym zespołom programistycznym na rozwijanie tego i innych projektów opartych na tej bibliotece. Jeśli jednak wolą prawo własności do całego kodu, możesz utworzyć zamiennik, ale będzie to dodatkowa opłata.

W zależności od tego, co już zobowiązałeś się, być może będziesz musiał napisać funkcję zastępczą za darmo lub rozdać kod źródłowy.

Pamiętaj, że istnieją różne typy bibliotek. Standardowa biblioteka szablonów w C ++ jest dobrym przykładem biblioteki, która jest zawarta na poziomie kodu źródłowego i jest wkompilowana w plik wykonywalny projektu, który może być dość podobny do tego, w jaki sposób używałeś wspólnego kodu.

Jeśli używasz strony trzeciej z dostarczonym oprogramowaniem, istnieje prawdopodobieństwo, że nie masz kodu źródłowego tej strony. Nadal dostarczysz oprogramowanie do firmy z plikami binarnymi strony trzeciej. Kod, który opracowałeś jako platformę współdzieloną we wszystkich swoich projektach, jest dokładnie taki sam jak strona trzecia, nawet jeśli jest twoją własnością. W takim przypadku firma ma dokładnie takie samo ryzyko z plikami binarnymi twojego frameworka, jak z zewnętrzną firmą. Dlaczego w takim przypadku miałbyś przekazać firmie kod źródłowy swojego frameworka? Możesz dostarczyć jej dobrą dokumentację API wraz z umową licencyjną i to. Jeśli Twój kod zawiera kolejną wielką rzecz, która zrewolucjonizuje branżę, to inna historia, ale generalnie tak nie jest.