Kernel Traffic #170 For 2002/06/10

Byłem zaangażowany w walkę z tym patentem przez ostatnie 2 lata. Przez ten czas rozmawiałem z wieloma osobami o tej kwestii. Dziś mogę Was zapewnić, że patent rtlinux zdecydowanie hamuje rozwój Linuksa.

W obecnej sytuacji, Linux nigdy nie będzie nadawał się do użytku jako osadzony SO, dopóki patent rtlinux nie zniknie. Co więcej, wiele osób z tej branży decyduje się na WinCE właśnie ze względu na patent rtlinux.

Wiele osób ze społeczności Linuksa czasu rzeczywistego jest bardzo zaniepokojonych faktem, że deweloperzy jądra sądzą, że zastosowania czasu rzeczywistego dotyczą niszowego rynku, ponieważ członkowie społeczności Linuksa czasu rzeczywistego widzą szkodę dla udziału Linuksa w rynku systemów osadzonych z powodu tego patentu.

Ostatni raport VDC wskazuje (http://www.linuxdevices.com/articles/AT6328992055.html), że główną przyczyną powstrzymującą przystosowanie Linuksa jako osadzonego SO są kwestie czasu rzeczywistego.

Nic dziwnego, że uznani dostawcy rozwiązań wbudowanych (WindRiver, QNX itp.) nie czują zagrożenia ze strony Linuksa. Wiedzą, że za każdym razem, gdy Linux będzie oceniany, pójdzie w odstawkę właśnie z powodu tego patentu.

Biorąc pod uwagę fakt, że rynek urządzeń wbudowanych wkrótce prześcignie rynek stacji roboczych i serwerów pod względem liczby sprzedwanych urządzeń, uważam, że to jest znacznie więcej niż tylko rynek niszowy.

Dopóki patent rtlinux nie zniknie, Linux pozostanie na obrzeżach zastosowań czasu rzeczywistego i urządzeń wbudowanych. Niestety.

Ten patent ma jednoznaczną licencję dla jąder na GPL, czyli m.in. dla Linuksa.

Być może jest to problem dla innych SO, ale nie dla Linuksa.

Zobacz "http://www.fsmlabs.com/about/patent/openpatentlicense.htm".

Słyszałem wiele dyskusji na temat takich patentów do ,,licencji na oprogramowanie Open Source'', które wskazywały, że będą one tym samym dla systemu patentowego, czym lewa autorskie (ang. copyleft) dla praw autorskich.

Nawet FSF wspiera ten konkretny patent (mieli wątpliwości w kwestii odwołalności licencji patentu, ale teraz licencja patentu mówi ,,tak długo, jak licencjobiorca zgadza się z tą licencją oraz z warunkami GPL'').

[ Właściwie, to FSF jest trochę nieszczęśliwe ze względu na to, że licencja patentu bezpośrednio wskazuje GPL v2, tak samo jak _jądro_ bezpośrednio wymienia, że wersja 2 GPL jest wersją domyślną. Victor, jak ja, nie dowierza FSF na tyle, aby wierzyć, że licencja zawsze pozostanie zgodna z oryginalnymi. ]

W skrócie, jeśli zaczniesz grać szybko i przestaniesz przestrzegać GPL, stracisz prawa do kodu objętego patentem. Źle. Jeśli natomiast będziesz robił wszystko po Bożemu, będziesz miał licencję na patent, za darmo. Dokładnie tak, jak wymaga tego GPL.

Rozumiem to, co mówisz, ale istnieje duża cząść historii patentu rtlinux, która nie została prawidłowo zakomunikowana deweloperom jądra. Postaram się zrobić to najlepiej, jak umiem, ale pytajcie, jeśli coś będzie wymagało wyjaśnień. Napiszę tyle, ile można zmieścić w pojedynczej wiadomości.

Jako pierwszy patent zauważył Jerry Epplin na początku 2000 roku i wysłał pytanie na ten temat na listę dyskusyjną rtlinux. Oto odpowiedź Victora z tamtego czasu: http://lwn.net/2000/0210/a/vy-patent.html W tej wiadomości jest wyraźnie napisane: ,,Głównym powodem patentu jest obrona ...''

Więc społeczność Linuksa czasu rzeczywistego zaczęła czekać na rozwój wypadków.

Następnie nadeszła pierwsza wersja licencji patentu. Ta wersja naruszała GPL wymagając rejestracji wszystkich użytkowników oprogramowania w FSMLabs. Dodatkowo miała następującą sekcję ,,ZAAPROBOWANE UŻYCIE'':

Oprócz innych warunków tej Licencji, użycie Opatentowanego Procesu
jest dozwolone bez opłat, gdy jest używane:

A.      Przez oprogrwamowanie licencjonowane na GPL; lub

B.      Przez oprogramowanie uruchamiane wewnątrz Środowiska Wykonawczego
        Open RTLinux - niezależnie, czy oprogramowanie jest licencjonowane na zasadach
        GPL, czy nie.

Innymi słowy, Victor mówił, że każdy, kto chce napisać aplikację czasu rzeczywistego, musi ją albo licencjonować na warunkach GPL, albo używać Środowiska Wykonawczego Open RTLinux, wersją RTLinuksa dystrybuowaną przez FSMLabs.

Wiele osób ze środowiska związanego z Linuksem czasu rzeczywistego było oczywiście bardzo niezadowolonych z takiego obrotu spraw i próbowało uzyskać wyjaśnienia od Victora. Do tego dnia społeczność Linuksa czasu rzeczywistego czekała na na odpowiedzi na tak proste pytania, jak: ,,Czy ktoś rozwijający aplikacje nie-GPL dla RTAI (inne rozszerzenie czasu rzeczywistego dla Linuksa) musi płacić opłaty licencyjne FSMLabs?''

Ta kwestia pozostała nietknięta do momentu, gdy FSF publicznie ogłosiła, że patent narusza GPL. Wówczas Eben Moglen publicznie wyjaśnił implikacje patentu oraz ,,poprawionej'' licencji patentu. Oto wyjaśnienie Ebena: http://www.aero.polimi.it/~rtai/documentation/articles/moglen.html

To nieco uspokoiło wszystkich, w szczególności zespół RTAI, w tym mnie, i zaczęliśmy dostosowywać się do zaleceń Ebena.

Wszystko szło dobrze, aż w pewnym momencie ponownie pojawił się Victor i zasiał ziarno niepewności: http://linuxdevices.com/articles/AT6164867514.html

W momencie, gdy Eben Moglen mówił o tym, że aplikacje czasu rzeczywistego nie są przedmiotem patentu, Victor Yodaiken wyskoczył zza węgła i powiedział: ,,Jeśli chcecie tworzyć, używać, sprzedawać, dystrybuować, importować itd. oprogramowanie nie-GPL -- niezależnie czy takie oprogramowanie jest nazywane ,,aplikacją'', ,,modułem'', czy jakkolwiek inaczej -- upewnijcie się, proszę, że uzyskaliście opinię prawną, czy takie użycie jest zgodne z Licencją Patentu Open RTLinux lub, czy taką licencję dla patentu RTLinux trzeba zabezpieczyć dla zgodnego z prawem istnienia tego oprogramowania.''

To nie było pomocne. Gdy spytałem Victora, czemu to zrobił, usłyszałem: ,,Nie mogę dawać porad prawnych. Z tego, co rozumiem, te rzeczy są bardzo skompilowane.''

Mógłbym zrozumieć, że to było rzeczywiście prawdą, ale mieliśmy opinię Ebena Moglena, uznanego prawnika, który publicznie wyjaśnił sytuację. I zamiast siedzieć cicho, wyskoczył i zaczął stawiać pod znakiem zapytania każde wyjaśnienie poczynione przez Ebena.

Saga trwa cały czas, a społeczność Linuksa czasu rzeczywistego cały czas jest w impasie. Na tym etapie, o ile dobrze rozumiem, FSF jest bardzo niezadowolone z komentarzy Victora. Ale punkt widzenia FSF czy też jego układy z patentem Victora to jedynie częściowy obraz tej historii.

Tak naprawdę, to patent jest jedynie czubkiem góry lodowej.

Aby zobaczyć pełny obraz, musicie zrozumieć, co się stało z różnymi istniejącymi już projektami czasu rzeczywistego: RTAI i RTLinux. Dziś RTAI jest zdecydowanie liderem w grupie dodatków czasu rzeczywistego do Linuksa. Stało się tak dlatego, że wszystkie osoby pracujące dziś nad nim, onegdaj próbowały coś zrobić dla RTLinuksa, ale zostały spacyfikowani przez Victora. I w większości przypadków przenieśli się do obozu RTAI.

I jest bardzo logiczny powód ku temu. Dualne licencje FSMLabs na RTLinuksa w postaci zamkniętych źródeł dla wielu ich klientów. To powoduje, że FSMLabs będzie właścicielem całego kodu RTLinuksa. W rzeczywiście, gdy zajrzycie do podstawowych plików w RTLinuksie, to zobaczycie, że należą one tylko i wyłącznie to FSMLabs. Nie ma nic złego w samym fakcie jako takim. Ale to ma znaczący wpływ na politykę rozwoju RTLinuksa -- żadne wspomaganie z zewnątrz nigdy nie znajdzie się w podstawowym kodzie RTLinuksa.

Co prawda istnieje gdzieś tam plik ,,contributors'' z kilkoma nazwiskami, ale żadne prawa autorskie nie są wymienione w plikach. To się aż prosi o podstawowe pytanie: Czy nikt, nigdy nie napisał nic dla RTLinuksa? Jeśli ktoś to zrobił, dlaczego nie ma innych nazwisk/nazw w nagłókach plików poza FSMLabs?

W tym momencie cały główny rozwój RTLinuksa nie jest dostępny na GPL i trzeba go kupować.

To w zasadzie nie jest problem, ponieważ RTAI już prześcignęło RTLinuksa pod względem możliwości, portów i wsparcia. Jednakże problemem pozostaje to, że patent rtlinux jest wykorzystywany w FUD-owej kampanii przeciw RTAI.

Każdy, kto chce pobawić się z czasem rzeczywistym w Linuksie przekopuje się przez dostępne informacje i znajduje RTLinux i RTAI. Później wypróbowuje najnowszego i najlepszego RTLinuksa i okazuje się, że GPL-owy RTLinux jest całkiem nieprzydatny. Więc zaczyna bliżej się przyglądać RTAI, ale szybko dostrzega te ostrzeżenia Victora na temat RTAI i decyduje się zrezygnować z Linuksa na rzecz innego systemu operacyjnego.

To nie jest całkiem wydumany scenariusz. Tak działo się wiele razy i to ze znanymi nazwiskami. Mogę udostępnić listę emaili osób, których możecie o to spytać.

Aby to podsumować, każdy, kto chce dziś rozwijać jakąś aplikację czasu rzeczywistego na Linuksie natrafia na mur niepewności. Nawet jeśli używa GPL-owego RTAI, nie jest pewien, czy powinien kupić licencje na swoje nie-GPL-owe aplikacje.

Zauważcie, że argument mówiący, że zadania czasu rzeczywistego działające na RTAI muszą być również na GPL ponieważ RTAI jest na GPL, nie ma racji bytu, bo RTAI pozwala dowolnemu procesowi Linuksa stać się pełnym zadaniem twardym czasu rzeczywistego. Jest to możliwe dzięki zastosowaniu pojedynczego wywołania rt_make_hard_real_time() do warstwy RTAI. Gdy ta funkcja jest wołana, RTAI kradnie zadanie Linuksowemu schedulerowi i szereguje je własnoręcznie. Dzięki temu całe zadanie jest w przestrzeni użytkownika.

Tak jak mówi notka o prawach autorskich w źródłach jądra, aplikacje przestrzeni użytkownika nie podlegają GPL. Dodaliście to sami, bo czuliście, że programiści aplikacji nie powinni być ograniczani przez GPL. Społeczność Linuksa czasu rzeczywistego oczekuje tego samego. Nie chcemy nie-GPL-owego środowiska wykonawczego czasu rzeczywistego, ani nie-GPL systemu operacyjnego. Wszystko, czego chcemy, to prawo do rozwijania aplikacji na naszych licencjach tak, jak inni to robią z Linuksem. Próbowaliśmy to uzyskać w drodze dyskusji i wymuszenia GPL. Za każdym razem napotykaliśmy na FUD i nieodpowiedziane pytania. Jedynym elementem, który jeszcze pozostał jest całkowite oddalenie patentu.

Ostatnia rzecz: Nikt nie ma wątpliwości, że jeśli aplikacje nie-GPL nie mogłyby działać z Linuksem, nie rozmawialibyśmy dzisiaj. To samo powstrzymuje aplikacje nie-GPL RT.

Mam nadzieję, że to wniosło lepszy obraz obecnej sytuacji. Jak już mówiłem, nie krępujcie się, aby poprosić o więcej wyjaśnień.

Ehh. To wszystko to fud. Twoje (2) _nie_ jest żadną opcją.

Czy część RT musi być GPL? Tak. Wielkie mi coś. To samo odnosi się w ogólności do modułów jądra - jeśli stanowią pracę bazującą na Linuksie (co w naszym przypadku oczywoście ma miejsce).

Więc dzielisz swój problem pomiędzy sterownik urządzenia RT a użytkownika. Koniec opowieści. Skończ z tym głupim FUD-em.

To co mnie zniesmacza to to, że ta cała sprawa ,,z patentem'' jest wykorzystywana jako temat zastępczy, a prawdziwym problemem jest to, że niektórym nie podoba się to, że jądro jest na GPL.

Przestań się sprawiedliwiać. Osobiście jestem szczęśliwy widząc kolejny powód, dla którego trzeba udostępniać swoje moduły do jądra na GPL. Widzę zdecydowanie zbyt wiele problemów z rzeczami takimi, jak moduły jądra nVidii itp. i zdaję sobie sprawę, że GPL przeraża wielu ludzi, ale nie dbam o to.

Niektórzy ludzie (Ty i Karim) myślą, że wymaganie GPL będzie krzywdzić Linuksa na polu rozwiązań wbudowanych. Rozumiem. To jest to samo, co ludzie od BSD mówili o Linuksie na polu rozwiązań serwerowych, o Linuksie na stacjach roboczych, czy Linuksie gdziekolwiek.

Sam stawiam na otwarte oprogramowanie. Nawet na rynku urządzeń wbudowanych. I jeśli ktoś się chce ze mną założyć, to nie dbam o to, bo to w żaden sposób na mnie nie wpływa.

Patenty są złe, ale myślę, że ludzie ,,dający czerwoną kartkę'' patentom również robią źle.

Wydaje mi się, że Alan sugerował Andrei, aby poprosił o papier _stwierdzający_, że jest w porządku, zamiast panikować.

Bardzo nie lubię patentów, ale musimy z nimi żyć. Podejrzewam, że najlepszą rzeczą jaką możemy zrobić, to nauczyć się z nich korzystać. I dlatego właśnie myślę, że to, że RedHat i FSMlabs starają się o patenty, nie stanowi problemu.

Czy te patenty zaowocują problemami? No jasne. Powiedzmy to w ten sposób: Jestem _zdecydowanie_ bardziej szczęśliwy z tego, jak RedHat/FSMlabs licencjonują patent względem użytkowników GPL, niż z tego, jak ktoś inny mógłby to zrobić, chcąc zaszkodzić GPL.

Możesz, przynajmniej tak rozumiem załączoną erratę. Jeśli dobrze rozumiem, to upewnij się proszę, że uruchomienie jądra specyficznego dla PII na ppro kończy się jego ,,paniką'', gdyż drobny błąd blokowania nie jest przyjemny, gdy ktoś uruchamia złe jądro.

To, że coś jest specyficzne dla PII oznacza także obecność MMX. To może być użyteczne w przyszłości, przy przyspieszaniu kopiowania stron.

Przy ostatnim porywie włączeń, przez Trivial Patch Monkey na trivial@rustcorp.com.au przesłano 100 łatek, które zostały odcedzone i poprzydzielane do różnych jąder: 5 do 2.2, 55 do 2.4 i 71 do 2.5. Linus i Marcelo wydają się już być nauczeni jak brać łatki (jakkolwiek są wciąż problemy ze źle przypisanymi zasługami).

Pamiętając o tym zaskakującym sukcesie (sądziłem, że to cholerstwo umrze po kilku dniach), będę w dalszym ciągu utrzymywał usługę, która zajmuje mi tylko około godziny tygodniowo.

Uwagi na temat użytkowania:

1. Przesyłajcie proszę jedną łatkę w jednym liście, nawet jeśli to oznacza konieczność wysłania 50 listów.
2. Upewniajcie się, że wasze diffy są zgodne z -p1, tzn: +++ linux/drivers/net/foo.c
3. MIME jest w porządku.
4. Przesyłanie do trivial z CC jest w porządku: zwykle jedynie przesyłam łatki dalej.
5. Naprawdę czytam łatki, więc nie oczekujcie odpowiedzi w czasie rzeczywistym.

Dla waszej informacji; większość łatek to (1) poprawki od ludzi pilnujących kodu, którzy nie mają szans zmusić Linusa albo linux-kernel do czytania łatek (tzw. tryb Alana Coxa) oraz (2) jednolinijkowce od doświadczonych hakerów jądra, którzy nie chcą się zajmować ich przesyłaniem (tzw. tryb zabezpieczający przed przepadnięciem).

Super! Ponieważ jestem jedną z osób, które z dużym zainteresowaniem obserwowały woj^H^H^Hdysksuję na temat ,,pingwina łatacza'', to cieszy mnie bardzo, gdy mogę usłyszeć o sukcesie trivial patch monkey. :)

Jeszcze tego nie używałem, ale będę pamiętał gdy będę miał jednolinijkowe poprawki. :)

Pięknie dziękuję. Może masz jakiś przykład na to, co miałeś na myśli powyżej? Jeśli biorę cudzą pracę, to zasługi przypisuję właśnie tej osobie i nie wydaje mi się bym to do tej pory w ogóle zrobił, na pewno nie ,,często''.

Oczywiście, że będę brał różne kawałki, cóż - o to w tym wszystkim chodzi.

W każdym razie, ponieważ nic nie rozumiesz na temat wewnętrznych szczegółów procesu kbuild (ani o kbuild-2.4, ani o kbuild-2.5), czego dowiodłeś publicznie nie raz, a Twoim celem jest udowodnienie, że potrafisz prowadzić politykę na l-k, nie oczekuj że odpowiem na jakiekolwiek dalsze listy na ten temat (i oszczędź sobie wysiłku odpowiadania na ten, wiem jednak, że tego nie zrobisz).

Linus sądzi, że Kai jest najbardziej obiecującym gościem, który może zintegrować kbuild2.5 właśnie teraz (patrz http://marc.theaimsgroup.com/?l=linux-kernel&m=102307114005894&w=2), a Kai chce się tym zająć w taki sposób, w jaki chce tego Linus. Warto chyba pozwolić Kaiowi i Linusowi na chwilowe wątpliwości, nawet jeśli oznacza to potrzebę całkowitej zmiany łatki kbuild-2.5 za każdym razem, gdy Linux zaakceptuje jedną z łatek Kaia.

Osobiście niecierpliwie czekam na kubild-2.5 włączony do jądra, ale mam też wrażenie, że korzyści z takiego wprowadzenia będą widoczne tylko, jeśli zostanie dokonany silny przegląd całości w taki sposób, w jaki to się odbywa w trakcie stopniowej ewolucji procesu budowania jądra w kierunku technik użytych w kbuild-2.5.

Dzięki wszystkim, Keithowi, Danielowi, Thunderowi i Kaiowi, którzy pracują (razem albo i nie!) nad przejściem z procesem budowania jądra do nowej ery.

To uwaga na boku, tylko po to by wyjaśnić _dlaczego_ wolę by odbyło się to w ten sposób, tak by ludzie zrozumieli - niekoniecznie się z tym zgadzając - dlaczego preferuję właśnie takie podejście.

Tak naprawdę jest kilka powodów:

• Zawsze nienawidziłem łat dnia. Czy one się zdarzają? Jasne. Niektórzy ludzie już dali przykłady takich wielkich łat dnia, jednym z pierwszych podawanych jest włączenie ALSA. To nie znaczy, że z tego powodu ta łata przestała mi się podobać.

  W skrócie: jeśli tylko jest to możliwe, to _dużo_ bardziej wolę stopniowe włączenia, gdzie ,,stopniowe'' naprawdę oznacza, że poszczególne elementy są dodawane po jednym (a _nie_ znaczy ,,buduj całą infrastrukturę wolno, tak by ostateczna ,,łata dnia'' sama była mała, ale dotyczyła wielu rzeczy'').

• Kai już pokazał, że potrafi ze mną pracować przy włączaniu kawałków kodu, zajął się jednym z tradycyjnych projektów dnia (ISDN: każde pojedyncze włączenie było włączeniem dnia) i zmienił to w bardzo łatwe dla mnie łączenie stopniowe. Kiedyś bardzo się bałem włączeń ISDN, obecnie nawet o nich nie myślę.
• Kai oczywiście już zna system budowania i wykonał na nim sporo rzeczy przyrostowych.
• Kai nie wspiera entuzjastycznie kbuild-2.5. Właściwie to nawet część mu się nie podoba. To jest plus w moim pojęciu: to oznacza, że cokolwiek tylko Kai spróbuje przepchać przeze mnie, będę się z tym czuł dużo lepiej, wiedząc, że ktoś się temu wcześniej krytycznie przyjrzał.

Zobaczmy zatem jak to wyjdzie. Może się nie uda, ale wydaje się to do zrobienia, przynajmniej w teorii.