Przyjazne umowy IP o otwartym źródle dla freelancerów


12

Zaraz po raz pierwszy wkroczę w świat doradztwa i muszę napisać swój pierwszy kontrakt. Jeden z moich problemów dotyczy pracy open source i własności intelektualnej. Uwielbiam pracować nad projektami typu open source, niezależnie od tego, czy jest to projekt istniejący, czy projekt, który zaczynam sam.

Pytanie brzmi: jak napisać umowę, aby uwzględnić następujące sytuacje:

  1. W trakcie pracy nad projektem klienta chcę otworzyć część kodu źródłowego dla społeczności pod własnym nazwiskiem.
  2. W trakcie pracy nad projektem klienta wykorzystuję niektóre z moich istniejących projektów open source i wprowadzam do nich ulepszenia.
  3. W trakcie pracy nad projektami klienta wprowadzam ulepszenia do projektów open source stron trzecich i wnoszę je z powrotem.
  4. W trakcie pracy nad projektem klienta decydujemy się otworzyć część kodu źródłowego pod nazwą klienta.

Jakie są precedensy, jeśli takie istnieją?

Aktualizacja: Dodałem element z powyższej listy (punkt # 3).


Chciałbym móc komentować komentarze. Jestem zaskoczony ilością dezinformacji i braku wiedzy na temat pracy z projektami typu open source. W dzisiejszych czasach zarabianie i praca nad projektami typu open source jest bardzo powszechna. W wielu przypadkach klienci chcą otworzyć kod, problem polega na tym, w jaki sposób przyciągają go. Dobre pytanie @toby
Aras

Odpowiedzi:


2

IANAL - więc polecam skonsultować się z prawnikiem, który w szczególności rozumie lub specjalizuje się w kwestiach własności intelektualnej oprogramowania .

Sądzę jednak, że odpowiedź jest dość prosta: 1. Nie sądzę, aby zachodziła potrzeba omawiania z klientem terminu „open source” (przeczytaj dalej przed sformułowaniem opinii na temat tego oświadczenia). 2. W swojej umowie wyraźnie należy podać następujące informacje: Każda praca, którą utworzysz dla klienta, którego JOINTLY WŁASNIE i każdy może tworzyć pochodne produkty pracy. Oznacza to, że każdy może z niego korzystać zgodnie z potrzebami, w tym uczestniczyć w projekcie open source (oczywiście należy zapoznać się z wymaganiami IP projektu open source). b. Zachowujesz własność dowolnego wcześniej istniejącego produktu roboczego, który jesteś na tyle miły, że możesz dołączyć za darmo, i wydajesz nieograniczoną licencję klientowi na używanie tego kodu na zawsze, w tym tworzenie dzieł pochodnych c.

Będziesz także chciał upewnić DAMN SURE, że nigdy nie podpisujesz żadnych umów z klauzulą ​​Przydział wynalazków, która nie jest bardzo ograniczona (nigdy nie są) - lub możesz być prawnie SOL. Należy pamiętać, że istnieje kilka stanów (np. Kalifornia), które ograniczają (ale nie eliminują) zgodnie z prawem, niezależnie od tego, co mówi umowa. Jest to oczekiwane w umowie o pracę (ale limity mogą być negocjowane), ale IMHO nie powinno być przyznawane dla umowy z niezależnym wykonawcą.

Twoim największym wyzwaniem będzie skłonienie ich do przyjęcia wspólnej własności kodu źródłowego. Jest to sprzeczne z doktryną „Praca na zlecenie ”, która jest specyficznym językiem, który jest bardzo często używany w umowach dotyczących tworzenia oprogramowania podczas korzystania z kontrahentów.

Jeśli rozumieją IP, mogą nie wyrazić na to zgody - ale zgaduję, że nie są to klienci, z którymi masz do czynienia. Mogę z całą pewnością powiedzieć, że istnieje co najmniej jedna wyjątkowo duża firma programistyczna, która robi to dla każdego kodu konsultacyjnego / niestandardowego napisanego dla dowolnego klienta - a jeśli nie zgodzi się na to, to nie zrobi tego - kropka ( ale skierują ich do partnera).

Jeśli masz współwłasność, powinieneś być w porządku pod względem IP, aby wnieść ten kod do projektu open source, z zastrzeżeniem wszelkich ograniczeń nałożonych przez ten projekt.

Będziesz także chciał być selektywny w tym, co otwierasz. Wyrządziłbyś swojemu klientowi szkodę, jeśli otworzysz kod źródłowy dla branży, który byłby przydatny dla jego bezpośrednich konkurentów. Twój klient będzie również niezadowolony, jeśli zorientuje się, że cała aplikacja, za którą zapłacili ci za niestandardowe pisanie, jest dostępna za darmo - i może nawet na początku pomyśleć, że właśnie zainstalowałeś go zamiast pisać od zera. Właśnie zmniejszyłeś ich postrzeganą wartość twoich usług.

Myślę, że dotyczy to twoich pytań 1,2 i 4.

Pytanie 3 może stanowić problem - w zależności od modelu licencjonowania projektu open source, z którego tworzysz pracę pochodną, ​​klient z pewnością może ci za to zapłacić, ale może nie mieć pełnej lub nawet własności tego kodu na model licencjonowania projektu open source. Nie oznacza to, że nie możesz tego zrobić - ale możesz to objąć dodatkową klauzulą ​​w umowie - i uruchomić ją przez prawnika IP - lub zrobić to tylko wtedy, gdy klient o to poprosi - i wtedy możesz być w stanie obciążyć koszty związane z zapoznaniem się z adwokatem aneksu do umowy dotyczącej tej sytuacji.


Aha - a jeśli nie zgodzą się na współwłasność, nie udostępniaj im swojej wcześniej istniejącej pracy za darmo, co może stać się punktem negocjacyjnym. W związku z tym, jeśli nie zgodzą się na współwłasność, ponieważ obawiają się o własność intelektualną, mogą nie chcieć, aby twoja wcześniej istniejąca praca była w to mieszana.
ScottBai 30.09.11

2

Poważnie, obie odpowiedzi zaczęły się od IANAL - myślę, że musisz przestać nawet myśleć o napisaniu umowy i porozmawiać z prawnikiem przed kontynuowaniem. Nie zapytałbyś swojego prawnika, jak refaktoryzować części kodu.

Poza tym - @Pete Wilson ma rację, twoje założenia prawdopodobnie nie będą dobrze pasować do twojego klienta.


1

Obowiązuje zwykły IANAL, co oznacza, że ​​skonsultuj się z prawnikiem.

To powiedziawszy, moje zdanie będzie:

  1. ... jest trudny. Jest mało prawdopodobne, aby klient był skłonny zapłacić ci za oprogramowanie, które zamierzasz natychmiast otworzyć. Możesz zapytać, a jeśli się zgadzają, odpowiednio zawrzeć umowę, ale zgaduję, że tak się nie stanie.

  2. ... jest również mało prawdopodobne, ale z dobrze spreparowaną umową, która wyraźnie określa granice, i zgadzanie się, że nie otrzymasz zapłaty za pracę nad własnymi projektami typu open source (niezależnie od tego, czy korzystasz z kodu, czy nie) akceptowalny dla klientów. Być może uda ci się ich przekonać do finansowego wsparcia projektu, ale w każdym razie musisz włożyć dużo wysiłku w zawarcie dobrej umowy.

  3. ... leży w gestii klienta. Zwykle klient chce korzyści, za którą ci płaci, co oznacza, że ​​nie widzi korzyści w otwartym pozyskiwaniu nieruchomości, ale mogą zdarzyć się przypadki, w których możesz go przekonać, co spowoduje opóźnienie aby zachować przewagę lub publikować w modelu podwójnej licencji.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.