Wiem, że firma, dla której pracujesz, jest właścicielem kodu i oczywiście zostaniesz aresztowany, jeśli spróbujesz go sprzedać. Ale czy programiści często przechowują osobistą kopię napisanego przez siebie kodu (do wglądu w przyszłości)?
Najwyraźniej ten facet został wysłany do więzienia za kopiowanie kodu źródłowego.
Odpowiedzi:
Nie wiem, jak często to jest, ale często czy nie, to wciąż zły pomysł.
Programiści często działają w myśleniu, że dwukrotne rozwiązanie tego samego problemu to strata czasu. Staramy się zaprojektować nasz kod tak, aby nadawał się do ponownego użycia (czasami). Budujemy biblioteki klas i funkcji do ponownego wykorzystania w pewnym momencie w przyszłości. Czasami wręczamy nasz kod, aby nikt inny nie musiał pisać kodu, aby rozwiązać ten sam problem, który właśnie zrobiliśmy. Dlatego może być zrozumiałe, że chcesz zabrać ze sobą „swój” kod podczas przechodzenia z jednego zadania do drugiego. Ale nadal nie powinieneś tego robić z następujących powodów:
To nie jest twój kod do wzięcia.
Kod napisany dla byłego pracodawcy jest częścią firmy, którą zbudowali. Ich kod stanowi część ich przewagi konkurencyjnej. Oczywiście konkurenci mogą napisać własny kod, aby rozwiązać ten sam problem, ale nie powinni czerpać korzyści z budowania pracy, za którą pracodawca zapłacił, jest właścicielem i nie upoważnił Cię do podjęcia pracy.
Jeśli mają jakiś sens, twój nowy pracodawca nie chce żadnej części kodu, którą wziąłeś od swojego byłego pracodawcy. Im częściej „polecasz” pracę wykonaną dla poprzedniego pracodawcy, tym bardziej narażasz nowego pracodawcę na prawne niebezpieczeństwo.
Jeśli kiedykolwiek przypadkowo pozwolisz, aby ujawniło się u Nowego Pracodawcy, że nadal masz kopię rzeczy, które zrobiłeś dla Starego Pracodawcy, Twój szef w New prawdopodobnie zrozumie, że weźmiesz kopię ich kodu, kiedy odejdziesz do innego praca. To może nie pasować do niego.
Nawet jeśli nie przeklinasz faktycznych wierszy lub po prostu niejasnych pomysłów ze swoich starych rzeczy, po prostu posiadanie starych rzeczy w posiadaniu może budzić podejrzenia, że możesz to wykorzystać do czegoś. Wyobraź sobie, że Stary Pracodawca pozywa Nowego Pracodawcę i jako jeden z niewielu pracowników, którzy przenieśli się ze Starego do Nowego, nagle składasz zeznanie. Nikt z was tak naprawdę nie skopiował kodu Olda do produktu New, ale prawnik przed tobą pyta: „Panie SuperFoo, czy ty teraz lub masz go w dowolnym momencie od czasu opuszczenia Old Employer, miałeś w posiadaniu kopię dowolnego kodu, który ty lub ktoś jeszcze napisał podczas pracy w Old Employer? ”
Nie potrzebujesz kodu, który napisałeś w zeszłym miesiącu, w zeszłym roku lub dłużej. Rozwiązałeś problem raz i teraz wiesz, jak rozwiązać problem ponownie. Lub możesz wiedzieć, jak nie rozwiązać problemu - nowa implementacja będzie lepsza, ponieważ masz doświadczenie.
Istnieją lepsze sposoby. Trudno jest wrócić i nauczyć się czegoś przydatnego, odczytując stary kod z kontekstu. Dziennik lub dziennik opisujący to, czego się uczysz, pomysły, które posiadasz itp., Jest o wiele bardziej użyteczny w przyszłości.
Nawet jeśli Stary Pracodawca wie, że masz ich kod i nie przeszkadza ci to, nadal go nie chcesz! Jedyne, co może się z tym wiązać, to telefon o 3 nad ranem: „Hej, SuperFoo? Jak się masz? Słuchaj, masz kopię naszych rzeczy, prawda? Słuchaj, mamy problem z i zawęziliśmy go do kilku plików, które napisałeś, których nasz nowy facet po prostu nie rozumie. Wiem, że jest późno, ale czy mógłbyś poprowadzić go przez SuperDuper.pl? ”
Odpuść sobie. Nie potrzebujesz tego.
źródło
for (int i=0; i < N; ++i)Zawsze przechowuję kopię kodu, który piszę i przenoszę go między zadaniami. Kolejni pracodawcy nigdy nie widzą / nie uruchamiają kodu, ale używam go jako referencji w domu: „Ach tak, czy nie zrobiłem czegoś podobnego do tego w Projekcie X?”.
Czy to jest legalne? Zależy od jurysdykcji i okoliczności, ale jest to dość powszechne. Moralnie nie mam z tym problemu, pod warunkiem, że nie dajesz kodu nowym pracodawcom ... To przypomnienie i pokaz tego, co zrobiłeś, a nie bezpłatne zasoby dla twojego pracodawcy.
[Druga strona to nieunikniony wstyd, który pojawia się, gdy spojrzysz na starszy kod: „Co ja sobie myślałem? Dlaczego, u licha, zrobiłem to w ten sposób? ']
źródło
To bardzo zły pomysł. Ten kod nie należy do ciebie (prawnie mówiąc), a posiadanie go może sprawić ci wiele kłopotów. Staje się to jeszcze bardziej prawdziwe, kiedy przenosisz się do nowej pracy i nadal trzymasz ten kod źródłowy w pobliżu. Gorzej, jeśli jest to konkurent. Twoja firma nie byłaby zadowolona, gdybyś miał dostęp do kodu źródłowego, gdy już dla nich nie pracujesz.
Chodzi o zarządzanie ryzykiem. Oczywiście oczekuje się, że zatrzymasz rzeczy poprzedniego pracodawcy, których możesz użyć gdzie indziej. Właśnie dlatego sprawiają, że Twój znak zakazuje konkurowania przez ostatnie X miesięcy / lat po ich opuszczeniu, jednak posiadanie kodu sprawia, że jesteś bardziej narażony na oskarżenia o rażące kopiowanie kodu firmy (nawet jeśli tego nie zrobiłeś, i użyłem tych samych pomysłów). Czy posiadanie kodu jest warte zarządzania tym ryzykiem?
Z pewnością użyteczne rzeczy, które otrzymałeś po napisaniu kodu, nie są dokładną składnią; to wiedza, którą zdobyłeś. Prawdopodobnie nie warto zajmować się tymi wszystkimi legalnymi sprawami.
źródło
To nie jest rzadkie.
Mam kopię prawie 1 każdego kodu, który napisałem profesjonalnie, a na pewno cały kod z moich bieżących projektów, niezależnie od tego, kto go napisał 2 . Wraz z kodem mam ogromną stertę legalnej dokumentacji, która jasno określa, co mogę, a czego nie mogę z tym zrobić. Sam kod nie jest tym samym, co próba czerpania z niego korzyści.
To powiedziawszy, jest to kwestia prawna, a kwestie prawne są zwykle bardzo skomplikowane i zlokalizowane. W razie wątpliwości naprawdę musisz porozmawiać z prawnikiem. Mogę zachować swój kod, ale jestem w 99% pewien, że nie będę miał z tego powodu kłopotów.
1 Brakuje przede wszystkim tego, czego nie chciałem zarchiwizować. Z powodów prawnych brakuje tylko jednego kodu małego projektu.
2 Charakter projektów i moja rola w nich, jestem jednym z facetów, którzy muszą mieć przynajmniej pojęcie o tym, co się dzieje, nawet jeśli nie byłem zaangażowany w budowę konkretnego modułu.
źródło
Widzę twojego aresztowanego Chińczyka i wychowuję cię „kodem nie jest własność, dlatego nie można go ukraść”.
Ref .: Kod „nie własność fizyczna”, zasady sądowe w sprawie szpiegowskiej Goldman Sachs
To powiedziawszy.
źródło
Oto proste pytanie dla Ciebie. Idź do swojego szefa i powiedz: „Mam kopię całego kodu, który napisałem podczas pracy tutaj. Tylko kod, który napisałem, a nie innych ludzi. To jest dla mojej własnej edukacji i nigdy go nie wydam”.
Kolejne ich działania będą dyktować (tak, to słowo istnieje w Ameryce Północnej / Świecie), jeśli jesteś w błędzie lub w ich oczach.
Niezależnie od własnej „etyki” pracujesz dla pracodawcy. Jeśli uznają, że to, co robisz, jest złe, to jest złe na podstawie ich etyki. Gdy ci płacą, a ty jesteś przez nich zatrudniony, to do twojego sądu należy albo się z nimi zgodzić, albo nie zgodzić, co może cię zwolnić.
Teraz jest to kwestia uczciwości. Pozwoliłem, aby poprzedni pracownik zabrał część naszego kodu, ale najpierw wszystko sprawdziłem.
To, że uważasz, że masz rację, nie czyni cię po prawicy. Zazwyczaj programiści podpisują umowy, gdy są zatrudnieni. Jeśli go podpisałeś, musisz żyć zgodnie ze swoim słowem.
źródło
Odpowiadając bezpośrednio na pytanie, w moich doświadczeniach powiem, że jest to rzadkie. Wyjątkiem tego, że widziałem to ludzie, którzy robią dużo Freelancing i zachować kod na rękę dla przyszłych projektów konserwacji i poprawiania swoich klientów, i wyobrażam sobie, że jest to wyraźnie określone w umowie (choć nie jestem w nawyk recenzowania umów o wolnym handlu z moimi przyjaciółmi, więc kto wie). Znane mi osoby, które pracują w większych firmach, nigdy nie przyznały się do przechowywania kodu od byłych pracodawców.
Wiem, że nie zrobiłbym tego, ponieważ nie mogę wymyślić jednej sytuacji, w której byłby użyteczny (nie wspominając, że jestem prawie pewien, że mój obecny pracodawca zabrania takich rzeczy - musiałbym po prostu sprawdzić dokumenty, aby mieć pewność ). Kod, który napisałem / naprawiłem, jest zazwyczaj tak specyficzny dla konkretnego wymagania biznesowego, że nie wyobrażam sobie, aby kiedykolwiek pojawił się w przyszłości w taki sposób, że łatwiej byłoby ponownie użyć starego kodu niż napisać nowy kod.
źródło
W tamtych czasach programiści często mieli osobistą bibliotekę procedur, których mogliby używać do rozwiązywania problemów w bieżącej pracy. Źródło pozostanie w tyle, gdy programista odejdzie, ale wszelkie ulepszenia również poszły z nim.
Spowodowało to sytuację korzystną dla wszystkich. Był to również podzbiór całego napisanego kodu.
Oczywiście większość tego, co było w bibliotekach osobistych, znajdowałaby się dzisiaj w bibliotekach standardowych.
źródło
W ramach relacji pracodawca-pracownik w większości części Ameryki Północnej nielegalne jest przesyłanie lub przesyłanie materiałów cyfrowych (tj. Kodu źródłowego) ze sprzętu pracodawcy bez uprzedniej prawnej zgody pracodawcy.
Częścią przepisów prawnych dotyczących definicji pracownika w miejscu pracy jest opis, że pracownik nie zapewnia własnego sprzętu roboczego, chyba że umowa o pracę stanowi inaczej, z wyjątkiem zawodów, które wymagają od pracownika zakupu własny sprzęt (np. pracownik budowlany).
Większość przepisów prawa pracy w Ameryce Północnej definiuje pracodawcę jako główny podmiot podejmujący ryzyko w relacji pracownik-pracodawca. Pracownik otrzymuje wynagrodzenie za swój czas, podczas gdy pracodawca zapewnia materiały, sprzęt i kontroluje czynności pracownika związane z pracą.
W jakim momencie podczas tej relacji okradzione jest kradzież cennego materiału od pracodawcy, który zapłacił i zaryzykował tworzenie tego materiału?
Kluczowym problemem było pytanie „kod źródłowy, który napisałeś?”. Nie, proszę pana, to nie ty to napisałeś. Pod kierunkiem twojego pracodawcy to oni go napisali. Jesteś tylko wynajętą ręką, która ją napisała. W Ameryce Północnej nie ma sądu, który byłby po twojej stronie, gdyby Twój pracodawca podjął kroki prawne w celu zabezpieczenia ich własności. Wystarczy skopiować kod źródłowy na pamięć USB, aby dostać się do gorącej wody.
To powiedziawszy, jeśli pracodawca zezwolił ci na użycie własnego sprzętu (np. Laptopa) lub przesłanie materiału, to inna sprawa. Po zakończeniu pracodawca musi powiadomić cię, że wszelkie materiały powinny zostać zwrócone / zniszczone.
Pomyślałem, że opublikuję tę odpowiedź, ponieważ wygląda na to, że niektórzy sądzą, że to szara strefa. Naprawdę nie sądzę, jeśli jesteś programistą, że powinieneś chodzić po Internecie, że przechowujesz kopie materiałów pracodawcy. Mam na myśli, że już znałeś odpowiedź na to pytanie, ponieważ utworzyłeś nowe konto członkowskie, aby zadać to pytanie. ;)
źródło
Zrobiłem to w przeszłości kilka prac temu.
Jednak nigdy nie wróciłem i nie spojrzałem na to. Od czasu do czasu wykorzystywałem pomysły i rzeczy, których się nauczyłem, ale ani razu nie znalazłem powodu, aby wrócić i spojrzeć na kod.
Więc nie zawracałbym sobie głowy. Jest to prawnie wątpliwe i nigdy tak naprawdę nie przydało mi się w praktyce.
źródło
Pewnie. Lubię przechowywać kopię całej mojej pracy - czy to pisania kodu, czy w inny sposób. Nazwij to notatnikiem, jeśli chcesz. Łamać zasady? Być może.
Komentarze na temat przewagi konkurencyjnej są nieistotne, chyba że twój następny pracodawca jest bezpośrednim konkurentem. Jeśli przeprowadzasz się z firmy telefonicznej do domu oprogramowania lub od twórcy gier do twórcy baz danych, nie ma to znaczenia. Jeśli planujesz ponownie użyć kodu - cóż, to inna historia.
Co ciekawe, często słyszysz o twórcach stron internetowych, którzy przynoszą ze sobą „zestaw narzędzi” ze standardowym zestawem bibliotek JavaScript i arkuszy stylów CSS . Ale nie widziałem tego wspomnianego tutaj.
źródło
Niedawno usunąłem cały stary kod, który zachowałem od mojego poprzedniego pracodawcy. Zachowałem tylko te fragmenty kodu, które moim zdaniem były dobre na przyszłość. Odkąd odszedłem, zauważyłem, że znacznie się zmieniłem i nigdy nie odwoływałem się do starego kodu. Znalazłem / odkryłem / nauczyłem się znacznie lepszych sposobów rozwiązywania tych samych problemów.
To była fajna wycieczka w dół linii pamięci :)
źródło
Myślę, że należy wprowadzić rozróżnienie między wzorcem projektowym a rzeczywistym kodem (kopiowanie linia po linii)
Zapisanie jakiegoś psuedokodu w stylu - to świetny sposób na leniwe ładowanie X w Y to jedno. Zapisywanie całego kodu to coś innego.
źródło
Za zgodą pracodawcy opublikuj czysty kod wielokrotnego użytku jako projekty typu open source, z których mogą korzystać inni ludzie. Wtedy twój pracodawca może również skorzystać ze składek innych osób na ten kod.
W ten sposób możesz zachować kod zgodnie z prawem, zbudować publiczne portfolio napisanego kodu, a kod może przynieść korzyści innym osobom.
źródło
Z różnych powodów, takich jak praca w domu, równie dobrze możesz mieć już kopię, a ja z jednej strony nie chciałbym ich usuwać po pracy, dlaczego to robisz? To nie jest sprzeczne z moimi przekonaniami ani czymś takim.
Ale jeśli chodzi o korzystanie z niego, nie jest on tak przydatny jak post na blogu!
Konkluzja: napisz swój kod, bloguj o problemach, które napotkałeś i jak je rozwiązałeś (szczególnie, gdy są to ogólne i szerokie rzeczy), i nie przejmuj się (prawdopodobnie zaszyfrowaną) pamiątką z ostatniej pracy.
źródło
W finansach CFA rozwiązuje ten problem. Nie wolno pobierać informacji związanych z klientami lub pracą dla firmy (w tym przypadku kodem). Ale nic nie stoi na przeszkodzie, aby zapamiętać, co możesz, a następnie zapisać to później.
Nie jestem pewien, czy to uzasadnione, ale myślę, że najlepiej jest zostawić kod źródłowy, ale zapisz swoje pomysły i jak to zrobiłeś, gdy tylko wrócisz do domu. Kradzież to kradzież i w sądzie starają się dowiedzieć, czy zdecydować, czy skopiowałeś kod, czy nie.
źródło
Jeśli zapisujesz kod w celu ponownego użycia go później, mam z tym dwa problemy:
Jeśli kod jest specyficzny dla domeny, prawdopodobnie jest również zastrzeżony. W każdym razie nie ma dwóch takich samych firm lub problemów, a próba rozwiązania jednego problemu za pomocą rozwiązania innego nie jest dobrym wzorcem.
Jeśli zapisywany kod rozwiązuje typowy problem, powinieneś zakwestionować swoje podejście. Dlaczego poświęcasz dużo wysiłku, aby rozwiązać typowy problem, gdy prawdopodobnie istnieją (i lepsze) rozwiązania open source?
Jeśli uważasz, że masz najlepsze rozwiązanie typowego problemu, powinieneś naprawdę spróbować udostępnić swój kod publicznie w publicznym repozytorium i / lub blogu z kodem podczas pisania, a nie przechowywać go dla siebie. Twój szef nie powinien sprzeciwić się udostępnianiu ogólnej biblioteki ani zmusić cię do ponownego wynalezienia koła (jeśli to zrobi, znajdź nową pracę).
Jeśli zapisujesz swój kod, ponieważ chcesz pokazać go potencjalnemu pracodawcy lub poprawić swoje umiejętności, sugeruję, abyś zamiast tego wziął udział w projekcie open source.
źródło
Nie zachowałem jeszcze żadnego kodu, który napisałem dla pracodawców. Zachowałem niezależne rzeczy (utrata kodu może być trudna do obsługi klienta).
Zastanawiam się jednak nad zachowaniem kodu, który stworzyłem dla tego pracodawcy. Powodem jest to, że jestem programistą i opracowałem wiele rzeczy po stronie klienta, które wyglądają raczej ładnie. Nie zaprojektowałem ich, ale wdrożyłem je i często wpadałem na pomysł. Chciałbym zachować kopię tych rzeczy, aby zbudować portfolio online. Jak wszyscy wiemy, strony nie trwają wiecznie, więc nie mogę realistycznie liczyć na to, że moja praca pozostanie online. Posiadanie kopii zapasowej pozwoliłoby mi mieć portfolio online.
Wiem, że projektanci często przechowują kopie swoich prac (nawet jeśli była to praca najemna) na potrzeby portfolio.
Nie jestem pewien, jaka jest to legalność (nie jest to wyraźnie wymienione w mojej umowie).
źródło
but what are your thoughts on this?Nie zapraszaj otwarcie do rozmowy na swoją odpowiedź, przedstawiając kolejne pytanie. Powiedz nam, czy powinniśmy zachować kopię całego kodu, który piszemy. Możesz poprawić odpowiedź, edytując ją.Cóż, aby rozwinąć logikę biznesową dla mojej firmy, nie mogę zachować kodu, ponieważ jest to nielegalna i osobista własność firmy. Jako programista wiem, jak rozwinąć tę logikę, więc mogę o niej pamiętać. Zasadniczo domyślnie jest przechowywany w twoim umyśle, a jeśli będziesz go potrzebować następnym razem, to automatycznie powinieneś wdrożyć logikę / lepszą logikę niż poprzednia. To ludzka natura i inteligencja. :)
Ale problem pojawia się, gdy rozwijasz logikę narzędziową, są one do ponownego użycia i zawsze ważne, może być potrzebne często w różnych projektach. Więc powinieneś chcieć to mieć przy sobie.
Mam alternatywne rozwiązanie tego. Po prostu utwórz plik JAR bez źródła / dokumentacji dla tych narzędzi i dodaj go jako zewnętrzny plik JAR innej firmy w swoim projekcie. Prawdopodobnie robiąc to, możesz potwierdzić swoją odpowiedzialność, a także samozadowolenie z posiadania kodu ;)
źródło
Nie trzymam kodu z prostego powodu: firma zapłaciła mi za napisanie kodu dla nich. Daję im mój kod, a oni dają mi moją wypłatę. Facet, który zrobił mój lunch, nie zachowuje tego dla siebie, dlaczego kod miałby być inny?
Ponadto, jak już wspomniałem, odchodzę z pracy, wszystkie bóle głowy pozostają tam, nowa praca, nowy start, ale z nieco większym doświadczeniem i zrozumieniem rodzajów problemów w tej starej pracy.
źródło