Czy powinienem podać się jako autor po zmodyfikowaniu kodu innej firmy?

Powszechną praktyką jest wprowadzanie drobnych poprawek lub poprawek w kodzie innej firmy (czy to zwykła lista, czy cała biblioteka). Ale często zdarza się, że wiele z tych kodów ma własne reguły licencjonowania i ostatecznie nagłówek każdego pliku z informacjami o prawach autorskich.

Co należy zrobić po dokonaniu tych modyfikacji? Czy informacje o licencji są nietykalne, czy próbujesz je zaktualizować, włączając w to siebie za pomocą tagów @authorlub @revisiontagów?

Innym częstym problemem jest zmiana przestrzeni nazw / pakietu innej firmy, aby dopasować ją do konwencji projektu. Niektóre typy licencji zawierają tego rodzaju informacje w bloku licencji. Czy mogę je dowolnie zmieniać?

Wiem, że odpowiedź na te pytania zależy od każdego rodzaju licencji, więc aby moje pytanie było bardziej szczegółowe ...

Biorąc pod uwagę ogólne zasady licencyjne (zwykle różnią się one w mniejszych aspektach, prawda?), Jest etyczne (lub przynajmniej dozwolone), że swobodnie dodam informacje do bloku licencyjnego o moich modyfikacjach, a może także modyfikuję sposób, w jaki odnoszę się do tego w moim kodzie (np. użyć YACorp.YALibjako Utils.YALib)?

Co należy zrobić po dokonaniu tych modyfikacji? Czy informacje o licencji są nietykalne, czy próbujesz je zaktualizować, włączając w to siebie za pomocą tagów @author lub @revision?

Myślę, że mylisz licencję na oprogramowanie i prolog, który może być częścią oprogramowania.

Licencja polega na tym, że właściciele praw autorskich do programu określają warunki użytkowania (licencja) dla innych osób. Niektóre licencje są bardzo liberalne, inne są znacznie bardziej restrykcyjne.

W prologu autorzy wstawiają @authori @revisiontagi, aby zapewnić sposób na śledzenie zmian w kodzie źródłowym. W niektórych przypadkach uzyskanie statusu nietrywialnego dodatku do kodu może spowodować roszczenie dotyczące praw autorskich do tej sekcji kodu. Rozwiązywanie problemów związanych z prawami autorskimi może być trudne i najlepiej rozwiązywać je przez prawników. Jednak wyraźnie stwierdziłeś, że nie interesujesz się tym aspektem, więc przejdę dalej.

Innym częstym problemem jest zmiana przestrzeni nazw / pakietu innej firmy, aby dopasować ją do konwencji projektu. Niektóre typy licencji zawierają tego rodzaju informacje w bloku licencji. Czy mogę je dowolnie zmieniać?

To naprawdę zależy od konwencji projektu.

Jeśli rozwidlisz projekt, możesz zrobić, co chcesz.

Jeśli planujesz wnieść swój wkład z powrotem do projektu, powinieneś trzymać się ustalonej konwencji. Jeśli istnieje ważny powód, aby zmienić przestrzeń nazw, musisz przedstawić to społeczności aplikacji.

Biorąc pod uwagę ogólne zasady licencyjne (zwykle różnią się one pod niewielkimi względami, prawda?),

czy etyczne (lub przynajmniej dozwolone) jest to, że swobodnie dodaję informacje do bloku licencyjnego o moich modyfikacjach, a może także modyfikuję sposób, w jaki odnoszę się do nich w kodzie (np. używam YACorp.YALib jako Utils.YALib)?

Nie zmieniaj licencji!

Po pierwsze, prawdopodobnie nie masz praw do zmiany licencji. Po drugie, wszelkie wprowadzone zmiany prawdopodobnie zepsują licencję. Pozostaw zmiany licencji prawnikom.

Jeśli chodzi o aktualizację prologu, zależy to od norm projektu. Niektóre projekty nie chcą prologu, ponieważ używają kontroli źródła do śledzenia tego. Inne projekty tak. Postępuj zgodnie z konwencjami projektu.

W rzeczywistości moje obawy dotyczą bardziej „szacunku dla społeczności” niż aspektów prawnych. Pytam więcej o to, jak bardzo możemy „oszaleć”, pozostając etycznymi, jeśli nasz projekt można uznać za prywatny lub osobisty.

Jeśli zachowujesz swoje zmiany dla siebie, dlaczego przejmujesz się tym, co myślą inni? Coś, z czego korzystasz tylko dla siebie i nigdy nie udostępniasz go innym, nie ma wpływu na oryginalny projekt. Więc nie obchodzi ich, co robisz.

Jeśli planujesz rozpowszechnić swoje zmiany lub wnieść je z powrotem do projektu, musisz ocenić konwencje tego projektu. Niektóre projekty nie chcą być rozwidlone i będą posiadały licencję, która to uniemożliwi. Inni posuwają się tak daleko, że mówią „rób, co chcesz”, a dostajesz carte blanche według własnego uznania. Ostatecznie odpowiedź tutaj zależy od konkretnego projektu, na który patrzysz.

Dodałbym komentarz, częściowo w celu zasygnalizowania czytelnikowi, że plik nie jest „waniliowy”, wraz z linkami do odpowiedniej dokumentacji lub systemu śledzenia problemów.

Edycja: Ta sytuacja przypomina mi, kiedy dystrybucja Linuksa pakuje np. Bibliotekę. Debian ma wytyczne i standardy dotyczące tego, jak należy budować i nazywać pakiety, które mogą się różnić od tego, jak biblioteka jest zwykle dystrybuowana w stanie wstępnie zbudowanym.

Nie sądzę, że powinieneś się wstydzić nazywania / budowania / modyfikowania biblioteki, ponieważ domyślam się, że nie będziesz rozpowszechniał wyników w szerszym świecie? W takim przypadku dołączę plik README wraz ze źródłem opisującym dokonane zmiany i dlaczego. Np. README. $ {CompanyName} .changes

Będziesz musiał zapoznać się z regułą licencyjną kodu.

Ogólnie rzecz biorąc, wiele aplikacji frontendowych typu open source (np. Firefox, OpenOffice) traktuje nazwę swojej aplikacji i logo jako znak towarowy; więc jeśli wydasz zmodyfikowaną wersję aplikacji, nie będziesz mógł używać oryginalnych znaków towarowych / sukienek handlowych (a więc IceWeasel, Torbrowser, LibreOffice).

Jednak większość bibliotek programistycznych jest często mniej zaniepokojona znakami towarowymi, o ile jest dość jasne, kto co robi (zwykle można to znaleźć w metadanych kontroli wersji).

Informacje o autorze służą dwóm celom:

1. Przyznawanie kredytu tam, gdzie jest to należne
2. Obwinianie tam, gdzie na to zasługuje

Te ostatnie stają się ważniejsze, gdy twoje zmiany stają się większe. Rzeczywiste informacje o autorstwie można ogólnie znaleźć w kontroli wersji, ale niektóre projekty formalnie przypisują zestaw autorów w osobnym pliku. Punkt odcięcia, w którym ludzie byliby formalnie uznawani, jest różny dla każdego projektu, w razie wątpliwości skontaktuj się z oryginalnymi autorami.