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

80

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.

marcgg
źródło
11
Wzdrygam się, kiedy słyszę: „To open source. Możesz z nim zrobić, co chcesz”. To po prostu nieprawda.
Jim
4
@Jim: Technicznie rzecz biorąc, to nie jest to, czego nie możesz zrobić, to jest problem, to jest to, do czego jesteś zmuszony, gdy zrobisz to, co chcesz.
Adam Bellaire,
20
Wzdrygam się również, gdy widzę umowę licencyjną na ponad 5000 słów wyświetlaną w czterowierszowym polu tekstowym z przyciskiem „Zgadzam się” poniżej.
NVRAM,
7
Wzdrygam się jeszcze bardziej, gdy oczekują, że przeczytasz to za każdym razem, gdy wypuszczą nową poprawioną wersję, aby sprawdzić, czy są różnice. Po prostu daj mi różnicę, cholera!
Stefano Borini
6
Po prostu bardzo się wzdrygam.
j_random_hacker,

Odpowiedzi:

135

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.

xpda
źródło
4
Przyjąłem tę odpowiedź, ponieważ była naprawdę interesująca i nie miałbym dużego widoku, ponieważ została niedawno dodana. Równie interesującą odpowiedzią jest ta: stackoverflow.com/questions/1396191/… . Oczywiście wszyscy wspominali też o tym, że konsultacja z prawnikiem jest ważna.
marcgg
1
Interesującą odpowiedzią była również ta: stackoverflow.com/questions/1396191/… , odnosząca się do niektórych książek na ten temat.
marcgg
Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.Jeśli jako wolny strzelec nie radzisz sobie lepiej, pobieraj dodatkową opłatę. Jeśli poświęcisz czas na zaprojektowanie czystego systemu podstawowego, dlaczego miałbyś pozwolić im zabrać go do jakiegoś warsztatu, aby czerpać korzyści? Zainwestowałeś w bazę kodu, w ten sposób opłacasz swoją inwestycję. Pozwala to również na ponowne użycie wspólnej logiki w innym miejscu dla następnego klienta.
Sanki
1
@ArtB ponieważ już otrzymujesz zapłatę?
Rob Fox
Biorąc pod uwagę wybór między pieniędzmi a czymś, co sprawi, że pieniądze przejmą kontrolę nad pieniądzem. Długoterminowy biznes będzie tego wart. Pozwoli Ci to nawet zaoferować niższe początkowe oferty. Do diabła, możesz nawet sprzedać kod innemu deweloperowi! Jeśli nie masz czegoś, co może wygenerować wyższą stopę zwrotu, pochłonąć mniej pieniędzy i więcej kapitału, jest to po prostu doskonały model biznesowy dla niezależnego wykonawcy.
Sanki
28

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

mmr
źródło
18
... i błądzić po stronie zwątpienia.
Beska
2
Chodzi mi również o to, że jeśli znasz jakieś rzeczy, będziesz w stanie łatwiej powiedzieć, kiedy konieczne jest skontaktowanie się z prawnikiem. Jak powiedział jim w komentarzu do pytania, niektórzy myślą: „To open source. Możesz z nim zrobić, co chcesz”.
marcgg
3
W razie wątpliwości tak. Ale „wątpliwości” powinny być na tyle małe, że nie wszyscy musimy zatrzymywać prawników na pensji. Każdy programista powinien mieć rozsądną wiedzę na temat prawa własności intelektualnej oraz dobrze rozumieć ograniczenia i obowiązki wynikające z powszechnych licencji open source. Prawnicy odpowiadają na trudne pytania.
Adam Jaskiewicz
1
@Adam - z prawnego punktu widzenia, nawet łatwe pytania mogą stać się „trudne”, jeśli ktoś pokłóci się o nie ...
Rook
1
Nie idziesz do lekarza za każde ukłucie, nie idziesz do prawnika z każdym pytaniem prawnym. Co do potrzeby dorosłych wystarczająco dowiedzieć się o medycynie i prawie pod którym działają, że są prawdziwe - i wiedzieć, kiedy naprawdę zrobić trzeba zadzwonić w pomocy profesjonalnego!
Tom Swirly,
26

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

leonm
źródło
1
Ok, wszyscy wiemy, że odpowiedzi typu „zapytaj prawnika” są (miejmy nadzieję) zdrowym rozsądkiem, jeśli chodzi o szczegóły. Poza tym, jest to doskonała odpowiedź podsumowująca ... Samo łącze do macierzy KDE jest bardzo przydatne!
Ogre Psalm33,
2
Jedna poprawka do pierwszego punktu: tylko jeśli „zależy od” obejmuje łączenie (dynamiczne lub statyczne) kodu GPL z plikiem wykonywalnym twojego programu lub w inny sposób skomplikowane wiązanie programów razem (np. Zrzuty pamięci). Jeśli napiszesz prawnie zastrzeżony program dla Linuksa, który używa grepa i działa tylko z wersją GNU, nadal powinieneś być w porządku, o ile kod grep nie znajduje się w twoim pliku wykonywalnym. Jednak IANAL.
Michael Ekstrand
Inną kwestią dotyczącą GPL jest to, że ma ona zastosowanie tylko do oprogramowania, które rozpowszechniasz. Jeśli uruchamiasz go na własnych serwerach, nie jest on automatycznie objęty licencją GPL.
mpeters
> Licencja LGPL (Library lub Lesser GPL) wymaga od Ciebie udzielenia licencji GPL na własny kod źródłowy tylko wtedy, gdy włączysz bibliotekę wydaną na licencji LGPL w taki sposób, że stanie się ona niezastąpiona. Nigdy o tym nie słyszałem. Gdzie mogę przeczytać więcej?
Esben Skov Pedersen
2
Łącze do poręcznej macierzy nie zwraca już poręcznej macierzy.
oob
8

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

tekst alternatywny

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:

Moayad Mardini
źródło
4

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!

Jeremy McGee
źródło
3

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?)

Pascal MARTIN
źródło
3

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ę .

Artelius
źródło
1

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.

Beska
źródło
Ale zawsze warto mieć podstawową wiedzę na ten temat, aby zaoszczędzić pieniądze i zobaczyć, że pojawi się problem prawny, nie sądzisz?
marcgg
Absolutnie. (I z tego powodu przegłosowałem to pytanie.) Ale myślę, że najważniejszą kwestią jest to, że na początku procesu uczenia się nowej koncepcji ludzie często mają błędne wyobrażenie o tym, ile wiedzą ... a dopiero później odkryj, o ile głębsze i subtelniejsze jest to pole. Może to być niebezpieczne w wielu dziedzinach, a prawo zdecydowanie nie jest wyjątkiem. Chciałbym wiedzieć jak najwięcej, aby móc rozpoznać sygnały ostrzegawcze i przekazać je ekspertowi do analizy.
Beska
1

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.

Stefano Borini
źródło
1

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.

Tom Savage
źródło
1
  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.
Stephan Eggermont
źródło
0

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

EBGreen
źródło
0

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

George Birbilis
źródło
-1

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

Paul Biggar
źródło