Fundacja NetBSD zakazuje umieszczania kodu generowanego przez SI w repozytoriach.

NetBSD słynie z jakości kodu. Nic dziwnego, skoro działa na 57 architekturach. Oczywiście, stopień rozwoju poszczególnych architektur jest różny, bo zdecydowanie więcej osób używa i386/amd64 czyli odpowiendio 32-bitowej i 64-bitowej wersji systemu, niż np. NetBSD na dreamcast'cie. Niemniej jednak, bazowy kod jest taki sam, a różnice dotyczące danego portu (architektury), są wprowadzane osobnymi patchami.

Aby utrzymać wszystko w porządku, NetBSD ma jedną z lepszych dokumentacji jakie widziałem w projektach open source. Słynny The Guide rozwijany od 1999 roku, z którego korzystam za każdym razem kiedy np. ściągam drzewo pkgsrc od zera, bo tak jest wygodniej niże pamiętanie wszystkich przełączników cvs.

Tak samo, wytyczne i standardy dla developerów i pasjonatów są spisane w wytycznych dotyczących wprowadzania zmian w NetBSD Commit Guidelines.

I tu nastąpiła niedawno zmiana, o której wspominam w temacie tego posta. Co prawda punkt o nie umieszczaniu "skażonego" kodu istniał od dawna, ale miał on postać jak niżej, wskazując aby nie umieszczać kodu nie pisanego przez siebie, lub takiego co do którego nie jesteśmy pewni czy licencja na to pozwala.

Natomiast od niedawna punk ten rozszerzył się o nowy akapit:

Wprost jest zabronione umieszczanie kodu generowanego przez SI jako kodu niespełniającego standardów "nie skażonego kodu", bez wcześniejszej zgody tzw core, czyli zarządu fundacji.

Dodatkowo, kod generowany przez SI (nie wiem czy wszystkie, ale na pewno GitHub/Copilot) nie za bardzo wpisuje się w postanowienia licencji open-source. Dość powiedzieć, że Microsoft trenuje swoje SI na kodzie open-source z GitHuba, a nie na swoim kodzie closed-source, aby później sprzedawać dostęp do Copilota.

Moim zdaniem, bardzo dobra decyzja. Nie jestem programistą, bardziej skrypto-pisarzem, i przeważnie fragmenty kodu systemu operacyjnego pojawiające się np w patchach na mailing listach wyglądają dla mnie jak hieroglify. Przy próbie wykorzystania SI do różnych zadań, czy to konfiguracyjnych, czy pomocy w skryptach, zauważam jednak, że inteligencji tam nie ma za dużo. Jeżeli SI trafi z rozwiązaniem to jest efekt wow, gdy jednak nie za bardzo działa, i to czasem z bardzo błahych powodów, np założonej złej ścieżki, albo arbitralnemu wykorzystaniu narzędzi przypisanej do innej platformy to nawet "tłumaczenie" gdzie jest błąd nie pomaga.

Dopuszczenie kodu pisanego przez SI, który po prostu działa na jednej platformie, zapewne z czasem doprowadziłoby do poważnych rozjazdach w innych portach, a cofanie zmian mogłoby być jeszcze bardziej kłopotliwe.

Jestem ciekaw, czy ten trend się utrzyma, czy wręcz odwrotnie, pogoń za szybkimi rozwiązaniami oraz "działa - nie ruszaj", wygrają w bardziej komercyjnych projektach. Oby nie.