Co każdy deweloper powinien wiedzieć o kwestiach prawnych? [Zamknięte]

Dzisiaj miałem niemiłą niespodziankę, gdy dowiedziałem się o pewnych implikacjach licencji GPL, głównie z tego, że nie mogłem jej używać tak swobodnie, jak myślałem.

Teraz wiem.

Co jeszcze powinienem wiedzieć, a szerzej, co każdy programista powinien wiedzieć o takich kwestiach prawnych?

Możesz oddzielić pracowników, freelancerów, współpracowników projektów open source (itp.) Lub udzielić szerszej odpowiedzi.

Dwanaście aspektów prawnych dotyczących tworzenia oprogramowania

1. Oprogramowanie jest chronione prawami autorskimi, jeśli jest publicznie dostępne. Nie jest już konieczne umieszczanie informacji o prawach autorskich w aplikacji lub w kodzie źródłowym. Właścicielem praw autorskich jest autor (autorzy) lub firma płacąca autorowi (autorom).

2. Prawa autorskie do oprogramowania mogą być przypisane przez właściciela praw autorskich lub mogą być one zachowane przez właściciela, a licencja na oprogramowanie może być udzielana użytkownikowi lub użytkownikom przez właściciela.

3. Biblioteki używane w rozwoju prawdopodobnie mają ograniczenia w ich używaniu i dystrybucji. GPL nie czyni biblioteki domeną publiczną, ani fakt, że biblioteka jest wyposażona w platformę programistyczną. Przed rozpowszechnieniem aplikacji należy przeczytać i zrozumieć licencję. Niektóre biblioteki wymagają opłat licencyjnych, chociaż w ostatnich latach stało się to mniej powszechne.

4. Pozwy dotyczące patentów na oprogramowanie to bzdury. Nie należy oczywiście świadomie naruszać patentu na oprogramowanie. Istnieje jednak niewielka, ale realna szansa, że ​​jakaś firma pozwie Cię za naruszenie ich patentu. Może się tak zdarzyć, nawet jeśli samodzielnie opracowujesz oprogramowanie, nigdy nie słyszałeś o patencie, a patent obejmuje technikę, która jest intuicyjnie oczywista i prawie całkowicie niezwiązana z Twoim oprogramowaniem. Biorąc pod uwagę obecne polisy USPTO, niewiele można zrobić, aby tego uniknąć, poza wykupieniem ubezpieczenia. Dobra wiadomość jest taka, że ​​trolle patentowe zazwyczaj pozywają duże firmy z dużymi pieniędzmi.

5. Jeśli do tworzenia oprogramowania korzystasz z usług pracownika lub freelancera, powinieneś wyjaśnić na piśmie, kto jest właścicielem praw autorskich do aplikacji, w tym kodu źródłowego. Niektórzy freelancerzy i firmy zajmujące się tworzeniem kontraktów uważają kod źródłowy za swoją własność, pozostawiając firmę zależną od pierwotnego programisty (-ów). Jest to zgodne z prawem, jeśli jest zawarte w umowie deweloperskiej.

6. Jeśli masz pracownika, który tworzy oprogramowanie „poza godziną”, powinieneś jasno określić, kto jest właścicielem tego oprogramowania i jakiego rodzaju oprogramowanie powinien móc pisać i rozpowszechniać poza firmą.

7. Jeśli jesteś pracownikiem lub freelancerem tworzącym oprogramowanie, powinieneś jasno określić, kto będzie właścicielem praw autorskich do Twojej aplikacji, zanim zaczniesz tworzyć. Powinieneś także wiedzieć lub wyjaśnić, kto jest właścicielem oprogramowania, które piszesz w wolnym czasie. Niektóre firmy mają klauzule w umowach o pracę, które twierdzą, że są własnością oprogramowania napisanego przez programistę w okresie zatrudnienia, czy to w domu, czy w pracy. Wiele firm ma klauzule o zakazie konkurencji w umowach o pracę, które ograniczają oprogramowanie, które pracownik może wytwarzać w celu dystrybucji poza firmę. Czasami te ograniczenia są dość szerokie.

8. Znak towarowy to nazwa lub symbol, a nie samo oprogramowanie. Jeśli rozpowszechniasz oprogramowanie, powinieneś (a) upewnić się, że nazwa aplikacji i „znak” lub projekt nazwy nie są „łudząco podobne” do innych aplikacji, oraz (b) zarejestrować swój znak towarowy. Data pierwszego użycia jest ważna przy rozwiązywaniu konfliktów, dlatego należy udokumentować, kiedy aplikacja jest po raz pierwszy używana w handlu.

9. Nadając nazwę aplikacji, poszukaj zarejestrowanych znaków towarowych, ale także sprawdź Google. Wniosek z pierwszym użyciem nazwy może być w stanie objąć Twoje nazwisko i znak towarowy po pomyślnym rozpatrzeniu wniosku, nawet jeśli nie zarejestrował znaku towarowego, a ty to zrobiłeś.

10. Kiedy używasz lub podpisujesz umowę lub porozumienie, upewnij się, że obie strony to rozumieją. W umowie o pracę wspomnienie z góry o wszelkich potencjalnie wrażliwych obszarach może zapobiec wielu późniejszym problemom. W umowie deweloperskiej, jeśli obie strony wiedzą, kto jest właścicielem kodu źródłowego, kto jest odpowiedzialny za aktualizacje, kto jest odpowiedzialny za utrzymanie itp., Wchodząc do projektu deweloperskiego, istnieje znacznie mniejsze prawdopodobieństwo pozwu po złożeniu wniosku została ukończona. W umowie dystrybucyjnej upewnij się, że dystrybutor rozumie obowiązki i warunki umowy.

11. Każda nietrywialna aplikacja zawiera błędy (lub „kwestie projektowe” :-)). Każda umowa użytkownika lub umowa dystrybucyjna powinna jasno określać, że nie jesteś odpowiedzialny za oprogramowanie wolne od błędów i nie możesz oczekiwać, że naprawisz wszystkie błędy. Wyjaśnij, że zmiany, poprawki i aktualizacje są dokonywane według uznania (lub najlepszych starań) programisty, i wyjaśnij, kto płaci za poprawki i aktualizacje.

12. Nawet jeśli skonsultujesz się z prawnikiem w sprawie umów dotyczących tworzenia i dystrybucji oprogramowania, powinieneś przeczytać umowy innych firm programistycznych i zobaczyć, co wymyślili ich prawnicy.

13. Nie jestem prawnikiem, a to nie jest porada prawna.

W razie wątpliwości skontaktuj się z prawnikiem.

Nie jestem prawnikiem, ale z biegiem czasu zebrałem kilka praktycznych zasad od osób prawnych, których możesz użyć, aby zaoszczędzić czas:

• Licencja GPL jest „kopiowana w lewo” lub „wirusowa”. Oznacza to, że każdy napisany przez Ciebie kod, który zależy od składnika GPL, musi również zostać wydany na GPL. Ogólna zasada jest taka, że ​​jeśli potrzebujesz składnika GPL do skompilowania swojego oprogramowania, Twoje oprogramowanie musi być wydane na licencji GPL.
• Nie masz obowiązku udostępniania źródła, jeśli nie rozpowszechniasz swojego oprogramowania. Na przykład, jeśli uruchamiasz oprogramowanie do celów wewnętrznych lub na serwerze internetowym, nie musisz ujawniać źródła. Dlatego Google nie musi wydawać swojego oprogramowania, które korzysta z bibliotek GPL. To był kluczowy punkt sporny w GPL v3.
• Licencja LGPL (Library lub Lesser GPL) wymaga od Licencjobiorcy GPL własnego kodu źródłowego tylko wtedy, gdy włączysz bibliotekę wydaną na licencji LGPL w taki sposób, że stanie się ona niezastąpiona. Twoje własne oprogramowanie nie musi być objęte licencją GPL, jeśli tylko „używasz” biblioteki. Dołączanie plików nagłówkowych i linkowanie do .dll/ .soz biblioteki to jeden ze sposobów „używania” kodu wydanego na licencji LGPL bez żadnych zobowiązań, z wyjątkiem odpowiedniej informacji o prawach autorskich.
• Licencja BSD (licencja Apache jest bardzo podobna) pozwala na tworzenie komercyjnych rozszerzeń wykorzystujących komponent open source. Dlatego Apple wybrał FreeBSD zamiast Linuksa jako jądro dla OSX.
• MPL jest bardzo przyjazny komercyjnie, ponieważ Netscape myślał, że może zarobić trochę pieniędzy na Mozilli w czasie pisania licencji.

Często pomaga kontakt z opiekunem projektu Open Source. To oni są w stanie najlepiej udzielić Ci porad dotyczących pierwotnego celu licencji, a także własnych poglądów na temat oprogramowania open source. Czasami opiekunowie są skłonni wydać oprogramowanie na wielu licencjach, aby ci pomóc. Często tak nie jest. Zależy od osoby, która jest właścicielem praw autorskich.

Projekt KDE ma poręczną macierz

Myślę, że poradnik prawny dotyczący tworzenia sieci i oprogramowania autorstwa prawnika Stephena Fishmana jest tym, czego szukasz.

Przejrzeć

Niesamowita książka! Odpowiada na prawie każde pytanie prawne, jakie możesz sobie wyobrazić, i na takie, o których nigdy byś nie pomyślał. - John Dvorak, PC Magazine

Obejmuje każdy możliwy do wyobrażenia szczegół ważny dla tak szybko rozwijającego się i niematerialnego nośnika. - Przedsiębiorca

Ta książka przechodzi mój osobisty test dla poradników prawnych - z wyższymi ocenami niż jakikolwiek inny poradnik prawniczy. - Jeff Duntemann, redaktor, magazyn PC Techniques

Opis produktu

Chroń swoje prawa i swoją ciężką pracę!

Przepisy dotyczące tworzenia stron internetowych i oprogramowania są złożone i zagmatwane, ale jeśli ich nie rozwiążesz, może to kosztować tysiące dolarów honorariów prawników i procesów sądowych.

Na szczęście Przewodnik prawny po tworzeniu stron internetowych i oprogramowania odszyfrowuje tę złożoną dziedzinę prawa, dokładnie i przystępnie po angielsku. Zawiera również umowy, umowy i formularze prawne na CD-ROM, z instrukcjami krok po kroku, jak je wypełnić, dzięki czemu możesz chronić swoje oprogramowanie i witrynę internetową bez płacenia okupu prawnika.

Skorzystaj z Przewodnika prawnego po tworzeniu stron internetowych i oprogramowania, aby dowiedzieć się:

• jakiego rodzaju ochrony prawnej potrzebujesz
• mocne i słabe strony każdego rodzaju ochrony
• jak uniknąć naruszenia
• jakie postanowienia są Ci potrzebne przy sporządzaniu umowy
• jak uzyskać zgodę na wykorzystanie materiałów innych osób

Znajdziesz pełne instrukcje krok po kroku, aby przygotować:

• umowy o pracę
• umowy z wykonawcą i konsultantem
• umowy dotyczące rozwoju
• umowy licencyjne

Piąte wydanie Przewodnika prawnego po tworzeniu stron internetowych i oprogramowania jest całkowicie zaktualizowane i zawiera najnowsze orzecznictwo i poprawki ustawowe.

Kilka innych sugestii:

• Praca dla siebie: prawo i podatki dla niezależnych wykonawców, freelancerów i konsultantów (ten sam autor).
• Umowy z konsultantami i niezależnymi wykonawcami (ten sam autor).
• Podręcznik licencjonowania oprogramowania autorstwa Jeffrey'a I. Gordona.
• Praktyczny przewodnik po licencjonowaniu oprogramowania dla licencjobiorców i licencjodawców autorstwa H. Warda Classena.
• Kieszonkowy przewodnik dotyczący umów technicznych: Umowy dotyczące oprogramowania i usług dla sprzedawców, kierowników kontraktów, deweloperów biznesowych i prawników autorstwa Davida Tollena.

Jeśli jesteś wolnym strzelcem lub kontrahentem: upewnij się, że masz dobre ubezpieczenie od odpowiedzialności cywilnej i wiesz, co obejmuje.

Na przykład mój nie obejmuje odpowiedzialności za błędy popełnione w kodzie, które mogą ujawnić numery kart kredytowych. Więc nie dotykam już tego wszystkiego!

Dla pracowników: powinniśmy być w stanie udzielić pierwszej rundy porad Twoim klientom - na przykład czy oni / my używamy komponentu, który chcemy, w ich zastosowaniu?

Dla freelancerów: musimy być w stanie doradzić Twoim klientom; i wybierz komponenty, których możemy użyć w aplikacjach, które dla nich tworzymy.

Oczywiście, twoje słowo nie jest tak dobre, jak porady, które może ci uzyskać prawnik; ale możesz już pomóc w pierwszej rundzie; na przykład, aby powiedzieć „zdecydowanie nie możemy tego użyć, ponieważ oznaczałoby to ...”
W końcu prawnik będzie wiedział dużo o sprawach narożnych - ale jeśli możesz trochę pomóc ...

Dla współpracowników OSS: znajomość pewnych różnic między wolnymi licencjami może mieć znaczenie, jeśli obchodzi Cię, co ludzie mogą zrobić z Twoim kodem (rozpowszechniać? Modyfikować? Używać go w aplikacji komercyjnej? Używać w zastrzeżonej aplikacji?)

Jedna odpowiedź głosi, że prawo nie jest jak kod. Nie zgadzam się.

Na początku IBM płacił programistom instrukcją. (Ktoś, kogo znałem, powiedział, że pracował z programistą, który wzbogacił się w ten sposób. Najwyraźniej facet nie wiedział, jak używać rejestru indeksów maszyny; napisał procedurę zerowania pamięci, która ręcznie zapisywała zero w każdym adresie pamięci.)

Był też czas (dawno temu), kiedy prawnikom płacono słowo. Pomogło to spopularyzować praktyki, takie jak zwracanie się do ludzi jako do „najbardziej cenionych takich a takich” oraz inne słownictwo.

Właśnie przeczytałem odpowiedź na SO, która mówi, że VB.NET 2008 nadal zezwala na numery linii . Nadal możesz uruchomić czysty DOS na nowoczesnym komputerze. I jest wiele prawdy w żartach, że wszystkie programy w języku COBOL zostały przejęte od wspólnego przodka przez stopniowe zmiany. W naszej dziedzinie powszechna jest kompatybilność wsteczna i „powody historyczne”.

Można to porównać do prawa. Istnieją prawa, które wprowadzają małe (lub duże) zmiany w innych prawach. Masz coś w rodzaju piekła zależności. Istnieje kilka absurdalnych praw historycznych (w Hobart na Tasmanii noszenie kobiecej sukienki po zachodzie słońca jest nielegalne - ponieważ kiedyś skazani przebierali się za kobiety i kradli ludzi), o których egzekwowaniu nikt nie marzyłby, tak jak istnieją pewne historyczne cechy oprogramowania, z których nikt już nie korzysta.

Przepisy często mają niezamierzone konsekwencje (błędy!), Są wykorzystywane w kreatywny sposób (hacki!), Zawierają luki w zabezpieczeniach (luki w zabezpieczeniach!), Z których niektóre są celowe (backdoory!), Są modyfikowane (łaty!) Lub przewracane (odinstalowywanie!) .

Tak, prawa (w przeciwieństwie do kodeksu) podlegają interpretacji. Ale myślę, że jest to raczej konserwacja kodu. Pomaga dostosować prawo do nowych norm społecznych.

Odpowiadając bezpośrednio na pytanie: każdy programista powinien wiedzieć, że prawo jest raczej absurdalnie ogromnym projektem programistycznym, nad którym pracowano od setek lat. (Właściwie każdy kraj ma własny projekt i rozwiązuje problemy na różne sposoby.) Teoretycznie po przeczytaniu licencji będziesz wiedział, co możesz, a czego nie możesz zrobić ze swoim kodem. Ale jeśli kompetentny programista nie może wykryć wszystkich błędów w swoim kodzie po prostu go czytając, to jaką szansę ma osoba niebędąca prawnikiem , aby przeanalizować sprawy narożne i szare obszary dokumentu prawnego?

Podobnie jak w przypadku kodu źródłowego oprogramowania, treść dokumentu prawnego można zwykle uzyskać, czytając go, ale jeśli chcesz wiedzieć coś konkretnego, zapytaj profesjonalistę .

NOLO (nie pracuję dla nich) publikuje dobry zbiór poradników prawnych dla laika.

http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html

Odpowiedziałbym na to w taki sam sposób, w jaki odpowiedziałbym „co każdy prawnik powinien wiedzieć o programowaniu?” To znaczy, wiedz, że nie ma możliwości, abyś mógł poznać głębię pola wystarczająco dobrze, aby zrobić coś więcej niż najprostsze rzeczy. Uzyskaj eksperta.

Powinieneś znać podstawowe prawa i obowiązki licencji, z której zamierzasz skorzystać. Nie jest to takie trudne, a nawet jeśli jest ich dużo, musisz uważnie czytać tylko te, których będziesz używać lub dotykać. Po prostu przeczytaj je, w większości przypadków są dość jasne.

Wszystko, czego potrzebujesz, cóż, to zależy. Patentowanie? Znaki towarowe? Jeśli potrzebujesz tych rzeczy, prawdopodobnie jesteś w firmie i masz dział prawny, który zrobi to za Ciebie.

Zawsze zakładałbym, że programiści projektu chcą, aby każde oprogramowanie korzystające z ich pracy było wydane na dokładnie tej samej licencji. Przeczytaj ich często zadawane pytania i strony prawne, aby uzyskać więcej informacji i nie wahaj się skontaktować z programistami / opiekunami, jeśli nadal nie jesteś pewien.

Jeśli potrzebujesz pomocy w zrozumieniu szczegółów umowy licencyjnej, porozmawiaj z prawnikiem.

1. Nie pracuj w kraju, w którym jest więcej prawników niż programistów.
2. Niezwykle duży procent wszystkich (amerykańskich) patentów na oprogramowanie jest fałszywych, ale nie można płacić ani czekać, aż zostaną unieważnione.
3. Jeśli chcesz używać / rozwijać oprogramowanie open source, skorzystaj z istniejącej licencji i nie modyfikuj jej. Nie zbliżaj się do granic tego, co ma oznaczać pozwolenie.

Nazwisko dobrego prawnika zajmującego się własnością intelektualną.

6. Jeśli masz pracownika, który tworzy oprogramowanie „poza godziną”, powinieneś jasno określić, kto jest właścicielem> tego oprogramowania i jakiego rodzaju oprogramowanie powinien móc pisać i rozpowszechniać poza firmą.

prawo do wolności słowa, jak stwierdzono w większości konstytucji (zwłaszcza jeśli deweloperzy robią to samo po godzinach) może sprawić, że takie warunki zawiodą w sądzie

Prawo to nie kod. Nie jest to dobrze opracowany zestaw kroków i zasad, które można jednoznacznie zrozumieć.