Jak już pewnie wiecie, Cisco zostało pozwane przez FSF. Chodzi, rzecz jasna o rzekome naruszenie przez Cisco warunków licengji GNU GPL.

Jeśli dojdzie do procesu, będzie to ważne wydarzenie dla całego ruchu FLOSS - pierwsze przetestowanie licencji GPL w ogniu amerykańskiego systemu prawnego. Jest kilka możliwości. Jeśli wygra FSF, wiele się nie zmieni, poza dodaniem pewnej dozy pewności racji środowisku. Jeśli wygra Cisco, prawdopodobnie ruszy lawina podobnych naruszeń, która będzie trudna do powstrzymania.

Kto ma rację? Ideologicznie, stronniczo, i moim zdaniem: FSF. Z drugiej jednak strony, nie wierzę aby Cisco użyła jakiegokolwiek kodu zanim ich prawnicy nie prześwietlili jego licencji na wylot na wszelkie możliwe sposoby. Wypuszczenie produktu z wadą prawną dobiło już niejedną firmę. Możliwe (i bardzo prawdopodobne) że w grę wchodzi kod firm trzecich, do którego Cisco nie ma pełni praw - ale to już problem (bo i produkt) Cisco.

Negocjacje pomiędzy FSF a Cisco trwały pięć lat. Proces potrwa pewnie następne pięć. Poczekamy, zobaczymy.

Przeglądając podprojekty Gnome, wpadłem na BillRemindera. Wejdźcie tam, kliknijcie w Download i.... fajne nie? Ciekawe tylko jak z dostępnością takiego rozwiązania dla czytników dla niewidomych. Ale ogólnie, mnie się spodobał taki patent.

Google zaprezentowało światu swój nowy produkt: NativeClient. W wielkim skrócie - jest to technologia pozwalająca odpalać programy w oknie przeglądarki. W odróżnieniu od Javy czy Silverlight, programy te są natywne.

Idea ta jest rozwinięciem pomysłu ActiveX. Różnica polega na tym, że NativeClient wykonuje programy w 'piaskownicy' (sandbox) która jest odizolowana od reszty systemu, w związku z czym, program nie jest w stanie namieszać w systemie tak jak robiły to czasami kontrolki ActiveX. Do tego, NativeClient jest multiplatformowy - Google zaprezentowało równocześnie wersję na Windows, Maca i Linuksa. No i rzecz jasna, NativeClient jest oprogramowaniem wolnym, z otwartym kodem źródłowym.

Idea jest ciekawa i ma spory potencjał. Ma także sporo wad. Pierwszym problemem jest bezpieczeństwo - wszystko zależy od jakości sandboxa. Miejmy nadzieję że otwartość kodu będzie tu pomocna.

Drugi, i zasadniczo największy problem, to natywność. Paradoksalnie jest to główny filar całego rozwiązania. Natywność oznacza że mamy do czynienia z kodem x86, i każdy kto ma inny procesor będzie miał problem. Spory problem. Ba, różne procesory z rodziny x86 często potrafią dziwnie się zachowywać, potrafią mieć błędy (wypływające np. na bezpieczeństwo czy stabilność systemu). Ogólnie, dziwi to, szczególnie gdy na całym świecie widać tendencję do odchodzenia od kodu natywnego na rzecz maszyn wirtualnych, czy to Java, CLR, Python czy cokolwiek innego.

Wydaję mi się, że NativeClient, to pomysł nieco na siłę. Tak jakby, chcąc ustrzec się oskarżenia o NIH (tworząc kolejną VM), postanowili zrobić coś mniej lub bardziej oryginalnego i oprzeć się na na kodzie natywnym. Cóż, pożyjemy zobaczymy.

Tym niemniej, możliwość odpalenia natywnego Quake w oknie przeglądarki robi wrażenie :)