Od kilku tygodni jedna z firm komputerowych nie znika ze szpalt gazet, ekranów TV, audycji radiowych itp. Jak wielkie są koszty tak szerokiej i intensywnej kampanii reklamowej? Zdziwicie się Państwo – 0 zł! (słownie ZERO PLN).

Dlaczego media tak ochoczo rezygnują z sowitych apanaży? Odpowiedź jest prosta – ponieważ tą firmą jest Microsoft i wypuścił właśnie nową (oczywiście lepszą!) wersję swego systemu operacyjnego – WINDOWS 7!

Czy wyobrażacie sobie Państwo, że media tak skwapliwie poinformują społeczeństwo o nowej wersji oprogramowania nawet wiodącej polskiej firmy? Ale skąd!!! Usłyszymy odpowiedź:

Niestety, nie możemy wymienić nazwy, bo byłaby to kryptoreklama. Proponujemy Państwu artykuł sponsorowany lub zamieszczenie płatnego ogłoszenia…

Reguła ta jednak nie dotyczy firmy Microsoft…

Ponieważ wiele osób kontaktuje się z Fundacją w sprawie Windows 7 pytając o zalety i wady tego systemu muszę dość wyraźnie podkreślić, że Fundacja nie zajmuje się recenzowaniem systemów komercyjnych – a jedynie jak sama nazwa wskazuje promocją Wolnego Oprogramowania.

Poniższa odpowiedź wyraża więc moje osobiste poglądy i nie stanowi oficjalnej krytyki nowego systemu Microsoftu:

Dlaczego nie zainstaluję Windows 7 ?

Przede wszystkim dlatego, że po prostu nie widzę powodu. Na stronie Microsoftu podano 10 najważniejszych powodów, dla których powinienem to zrobić i żaden z nich mnie nie przekonał!

1. Szybszy dostęp do plików i programów?
Przecież w moim Linuksie mogę sobie umieścić dowolne ikonki na pasku lub w menu! Na czym więc polegają tak mocno reklamowane właściwości jak Pin lub Jump List?

2. Łatwiejsze zarządzanie oknami?
O co tu właściwie chodzi? O nowe właściwości dekoracji okna?

3. Windows Search?
A co to za nowość? Przecież to podstawowa funkcja każdego pulpitu!

4. Współdzielenie plików i drukarek pomiędzy PC-tami?
Microsoft pisze, że mogę wymieniać pliki, muzykę, zdjęcia a nawet drukarki w domowej sieci. Przepraszam, ale wydawało mi się, że to już po prostu standard!

5. Centrum rozrywki – mogę nawet oglądać na swym PC telewizję – w tym również internetową (sic)! I to ma być wielkie osiągnięcie?

6. Obsługa filmów i pokazów slajdów – znów, proszę mnie nie rozśmieszać! To ma być nowa funkcja?

7. Łatwe połączenia z siecią – można podłączyć się do wykrytej sieci bezprzewodowej w trzech krokach! Na moim dość starym laptopie Fujitsu-Siemensa (Centrino) z SuSE Open Linuksem jest to oczywiste – nawet w starszych wersjach systemu nie było z tym kłopotu.

8. Funkcje Sleep i Resume (podobno przyspieszone) – przecież to dziś standard w każdym systemie… Jeśli działają szybciej niż poprzednio – to bardzo dobrze.

9. Obsługa ekranów dotykowych – łatwiejsza i bardziej intuicyjna. Przecież takie stwierdzenie niewiele znaczy, a obsługa nakładek dotykowych też nie jest niczym nowym.

10. Zarządzanie urządzeniami peryferyjnymi – to chyba konieczność?

Przykro mi, Panowie z Microsoftu, ale nawet suma tych powodów nie zdołała mnie przekonać, aby zakupić ten system w cenie 660 PLN (a nawet w najpełniejszej wersji ponad 1000 PLN!). I jeszcze w dodatku otrzymam za swoje pieniądze jedynie „nieprzenaszalne prawo do korzystania z oprogramowania” z zakazem prób poznania i ewentualnej modyfikacji jego kodu. W dodatku oferuje mi się tak zwaną „ograniczoną gwarancję”, która de facto oprócz wymiany wadliwego nośnika niczego mi nie gwarantuje (oczywiście „w maksymalnym zakresie dozwolonym przez prawo”). Mam zwyczaj czytać dokumenty licencji i gwarancji…

Poza tym mam historyczną pewność, że za trzy-cztery lata znów zapragniecie sięgnąć do mojej kieszeni oferując mi (oczywiście w atrakcyjnej, promocyjnej cenie!) nowy, jeszcze lepszy system operacyjny.

Dziękuję – nie potrzebuję. Na szczęście komputera używam do takich celów, że nikt mnie nie zmusza do zainstalowania Windows 7. Oprogramowanie OpenOffice z nawiązką spełnia moje potrzeby w zakresie typowej pracy biurowej, Firefox, Thunderbird i Kompozer z powodzeniem zapewniają mi pełny kontakt ze Światem, Gimp – obróbkę zdjęć i grafiki, MPlayer odtwarzanie multimediów itp., itd. A w dodatku mam możliwość pracy na wielu konsolach, współpracy z dowolnymi serwerami (także MS Windows!) – również w trybie terminalowym – a  współdzielenie zasobów (plików, drukarek, usług internetowych itp.) jest po prostu standardem.

I co najważniejsze – większość potrzebnych mi programów jest udostępnianych mi bezpłatnie wraz z kodem źródłowym i mogę je modyfikować dla własnych celów. Nikt mnie również nie inwigiluje, nie próbuje ścigać za przekazanie ich przyjacielowi. Nie boję się również wirusów…

Zdaję sobie sprawę, że wielu użytkowników rozważy zainstalowanie Windows 7 – bo po prostu nie ma innego wyjścia, gdyż używa programów, które działają jedynie w środowisku systemu MS Windows. Jest to jednak typowy przykład pułapki uzależnienia się od jednego dostawcy (VendorLock-In). Takie zjawisko jest dość typowe w początkowym rozwoju technologii, gdy naturalną przewagę zdobywa jeden wytwórca – przed II Wojną Światową w Polsce wydawano specjalne prawo jazdy uprawniające do prowadzenia Forda T – funkcjonowało też powiedzenie „pan kierowca, czy tylko na Fordzie?”. Można je sparafrazować „Pan informatyk, czy tylko Windows?”…

Tomasz Barbaszewski
Przewodniczący Rady Ekspertów
Fundacji Wolnego i Otwartego Oprogramowania
www.fwioo.pl

Projekt DDTP jest częścią, wielkiego projektu jakim jest społecznościowe tworzenie wolnej dystrybucji systemu operacyjnego Debian GNU/Linux. Jest on obecnie drugą pod względem wieku dystrybucją tworzoną przez wolontariuszy z całego świata. Jedną z bardziej istotnych części tego projektu jakim jest Debian, oprócz dostarczania oprogramowania i wsparcia technicznego jest internacjonalizacja dystrybucji poprzez tłumaczenie jej komponentów na różne języki.

Obecnie tłumaczenia stron projektu, dokumentacji, opisów pakietów obejmują ponad czterdzieści języków w tym polski i znajdują się w różnych stadiach zaawansowania. My jesteśmy grupką tłumaczy (przynajmniej tak o sobie mówimy) zrzeszonych przy tłumaczeniach opisów pakietów dla Debiana. To dzięki nam możesz przeczytać opis pakietu po polsku, aby móc zapoznać się z jego zawartością. Jest nas niewielu i tłumaczymy w wolnym czasie, ale nie przeszkadza nam to wykonywać około 100 (lub więcej) tłumaczeń opisów na miesiąc. Przeważnie każdy z nas zaczyna od przeczytania posta Grabosia na forum debian.linux.pl. Potem tłumaczymy. Każde nasze tłumaczenie jest jeszcze weryfikowane przez trzech innych tłumaczy, którzy albo nas poprawią, albo zaakceptują nasze tłumaczenie. Po trzech akceptacjach tłumaczenie trafia do bazy opisów Debiana. Oczywiście jak każdy zespół, my również mamy pewne zasady. Zatem jeśli masz czas i chcesz nam pomóc, zapoznaj się z nimi. A potem do zobaczenia na stronie z interfejsem do tłumaczeń.

Co to jest?

Dotychczas tłumaczenia odbywały się za pośrednictwem e-maila (ta forma jest wciąż dostępna lecz niezalecana, wyjątek stanowi grupa tłumaczy z Czech dla których stanowi ona podstawę działalności). Należy podać numer pakietu, język, jeśli wybieramy inne kodowanie znaków, to taką informację należy również umieścić w wiadomości.

• Obecnie przy tłumaczeniach wykorzystywany jest interfejs DDTSS, który napisał Martijn van Oosterhout. Jest znacznie prostszy w użyciu, a oprócz tego ma kilka innych zalet:
• Sam dba o właściwe kodowanie znaków.
• Opisy pakietów do tłumaczenia dostępne są praktycznie „od ręki”.
• Nigdy nie tłumaczymy sami – działamy zespołowo. Po przetłumaczeniu pakiet musi przejść weryfikację i trzech tłumaczy musi go zaakceptować, co ogranicza ryzyko popełnienia błędu.
• Posiada system wiadomości, którymi tłumacze mogą przekazywać między sobą informacje.
• System pokazywania różnic między opisem pakietu, który został zmieniony przez tłumacza, a jego poprzednia wersją.
• Dostępny jest przez przeglądarkę internetową (nie jest potrzebny klient pocztowy).

Techniczne zasady

DDTSS nie wymaga zakładania konta, ale warto to zrobić, gdyż dzięki temu będziemy mogli wysyłać i otrzymywać wiadomości oraz korzystać z sekcji Suggestions (patrz niżej). W przeciwnym wypadku będziemy identyfikowani po numerze IP.
Po wejściu na stronę tłumaczeń mamy do dyspozycji kilka sekcji:

Pending translation – Znajdują się tu tłumaczenia wyciągnięte przez system, który co jakiś czas (nie jest to automatyczne i zależy od szybkości tłumaczenia opisów pakietów) dołącza do listy pakiety , które wymagają tłumaczenia opisu. Bądź też „ręcznie” poprzez „Fetch specific description”. Z boku każdej nazwy pakietu znajduje się jej priorytet. Im wyższy tym opis pakietu powinien zostać szybciej przetłumaczony.

Fetch specific description – Opcja, którą można pobierać opisy pakietów do tłumaczenia. Obok pola do wprowadzania nazwy pakietu znajduje się opcja „Force fetching even if not untranslated”. Należy się nią jednak posługiwać bardzo ostrożnie, gdyż można pobierać za jej pomocą wszystkie opisy – także te już przetłumaczone. Jest to przydatne do poprawiania błędów w tłumaczeniach już istniejących, ale niewłaściwie użyte może wprowadzić niemałe zamieszanie i spowodować konsternację niektórych tłumaczy.

Pending review – Tu trafiają pakiety, które zostały przetłumaczone, ale czekają na akceptację bądź zmiany innych tłumaczy. To najlepsze pole dla początkujących tłumaczy. Mogą oni podglądać, jakie błędy zostały już poprawione i jakich unikać.

Suggestions – Jeśli ktoś nie jest pewny tłumaczenia, może umieścić je w tej sekcji jako sugestię. Z racji, iż to nie do końca działa w taki sposób, w jaki powinno, nie jest to przez nas używana opcja. Utarło się nawet, że początkujący zaczynają od przeglądania tłumaczeń w sekcji Pending review, a nie w Suggestions.

Messages for you – Sekcja zawiera wiadomości wysłane przez innych użytkowników.

Reviewed by you – Pakiety, które tu trafiają zostały przez nas albo przejrzane i zaktualizowane, albo zaakceptowane bez wprowadzania zmian i oczekują teraz na akceptację innych tłumaczy.

Recently translated – Pakiety, które zostały zaakceptowane przez trzech tłumaczy, zostały przesłane na serwer są widoczne na liście w tej sekcji. Można je stamtąd przywrócić, oczywiście tylko jeśli zostanie znaleziony poważny błąd w tłumaczeniu. Ta sekcja daje przy okazji szybki podgląd na ostatnio przetłumaczone opisy. Jest to przydatne, gdy istnieją pakiety współdzielące akapity lub o bardzo podobnych opisach, które można szybko uzupełnić o zatwierdzony wzór. Umieszczając taką informację w komentarzu do własnego tłumaczenia zostanie ono na pewno znacznie szybciej sprawdzone przez innych tłumaczy, ewentualnie skorygowane i zaakceptowane.

Gdy wybierzemy już, z której sekcji chcemy skorzystać oraz pakiet, którego opis chcemy przetłumaczyć, przystępujemy do działania. Tłumaczenia składają się z tytułu oraz części właściwej, w której akapity są rozdzielone znakiem „.” (kropki). Każdy akapit jest oznaczony w polu do tłumaczeń jako <translation> i zamiast tego oznaczenia mamy wstawić przetłumaczony tekst. Oczywiście, jeśli mamy wątpliwości, możemy je opisać w polu komentarza, najlepiej dodając informację, o który akapit chodzi, jeśli opis pakietu jest obszerny.

Pod spodem znajdują się dwa przyciski Abandon i Submit. Jeśli nie jesteśmy w stanie przetłumaczyć danego tekstu, powinniśmy kliknąć Abandon zostawiając tłumaczenie bardziej doświadczonym tłumaczom. Jeśli zaś przetłumaczyliśmy tekst – Submit. Decydując się porzucić tłumaczenie i wybierając Abandon, pakiet trafi na listę Pending translation (zachowają się dodane przez nas komentarze, więc możemy zostawić sugestie dla innych). Warto wspomnieć o jeszcze jednej ważnej części – niewidocznej na powyższym zrzucie ekranu. Pojawi się ona, gdy dany opis był już wcześniej tłumaczony. Pod przyciskami Submit i Abandon znajdzie się wtedy niemniej ważna część tłumaczenia.

Może się w niej znajdować różnica pomiędzy poprzednim opisem pakietu oraz poprzednie tłumaczenie.
Potem ktoś przeglądając nasze tłumaczenie, będzie miał podobny widok. Różnica będzie tylko polegała na przyciskach, których będzie mógł użyć. I tak:

Accept as is – Zatwierdzi tłumaczenie bez nanoszenia poprawek (można dodawać jedynie komentarze).

Accept with changes – Zatwierdzi tłumaczenie z własnymi, uprzednio wykonanymi poprawkami w tłumaczeniu. Proces tłumaczenia rozpocznie się od nowa i znowu trzech tłumaczy będzie musiało zatwierdzić te zmiany, aby były one wprowadzone. Jeśli naniosą własne poprawki, proces znów rozpocznie się od nowa (zachowywane są również dodane nowe komentarze).

Change comment only – Doda komentarz (wprowadzony w polu Comment field), bez wprowadzania zmian w tłumaczeniu.

Pod przyciskami znajdzie się też rejestr użytkowników, którzy dokonali zmian. Następna osoba przeglądająca zmiany, widzieć będzie elementy usunięte przez poprzednią osobę na czerwono, a nowo dodane – na zielono. I tak do trzech akceptacji bez poprawek.

Jak pobrać opis pakietu do tłumaczenia, którego nie ma na listach pending translation?

Najprościej po prostu wpisać jego nazwę w polu Fetch specific description i wcisnąć enter. Pobierze się nam wtedy opis dla dystrybucji stabilnej. Najczęściej jest on taki sam jak dla dystrybucji testowej i niestabilnej. Po wyświetleniu okna tłumaczenia możemy sprawdzić, czy tłumaczenie odnosi się do wersji pakietu, której opis chcieliśmy przetłumaczyć. Jeśli tak nie jest, to najlepiej udać się na stronę główną DDTP gdzie na górze strony zobaczymy alfabetycznie ułożone odnośniki do stron z nazwami zaczynającymi się na daną literę. Przypuśćmy, że chcemy dokonać tłumaczenia opisu pakietu wymienionego wcześniej: desktop-file-utils. Klikamy „d” i przechodzimy na stronę z listą pakietów. Odszukujemy pakiet i zobaczymy tam przykładowo:

desktop-file-utils
33783: squeeze 2009-02-16…2009-08-18; lenny 2007-06-14…2009-08-18; lliurex_gaia 2008-08-15…2009-08-18; sid 2007-04-30…2009-08-18;
1652: sid 2005-07-16…2007-04-30; etch 2005-07-16…2009-08-18;

W zależności, dla której wersji systemu chcemy dokonać tłumaczenia (przykładowo Squeeze) wpisujemy numer znajdujący się na początku linii (w tym wypadku 33787) w pole Fetch specific description. Pobieranie opisów do tłumaczenia po ich numerach jest znacznie dokładniejsze niż wpisywanie samej nazwy pakietu (aktualnie koncentrujemy się głównie na opisach pakietów z wersji testowej i niestabilnej Debiana). Dodatkowo możemy sprawdzić w tym miejscu, czy nie ma wcześniejszego, polskiego tłumaczenia dla pakietu.
(Uwaga! Na listach znajdują się też pakiety, których nie ma już w Debianie, aby bez potrzeby nie tracić na nie czasu, dobrze jest przyjrzeć się datom. Nieodpowiednie użycie tej opcji spowoduje niemałe zamieszanie – dlatego prosimy o dużą rozwagę i ostrożność podczas jej używania.)

Zasady tłumaczeń

Kwestie techniczne

1. Należy pamiętać o zachowaniu identycznego podziału na akapity jak w oryginale (akapity są rozdzielane znakiem „.”). Jest to o tyle istotne, że przy zmianie jednego z akapitów w wersji źródłowej, przy ponownym tłumaczeniu tego pakietu do zaktualizowania będzie właśnie tylko ten jeden akapit.
2. Nie należy poprawiać zbędnych przełamań wiersza w polu tekstowym – zostaną zignorowane przez system, a ich poprawianie wprowadza tylko zbędne zamieszanie (wyjątek stanowią wiersze rozpoczynające się od spacji – patrz niżej).
3. Wiersze rozpoczynające się od spacji są inaczej formatowane i są zawsze wyświetlane od nowej linii. Jest to wykorzystywane przy różnego rodzaju listach i wyliczeniach. Jeżeli dany punkt nie mieści się w jednej linijce, kolejną należy również zacząć od spacji, aby zachować to samo formatowanie
4. Przy aktualizowaniu już istniejącego tłumaczenia, dobrze jest napisać, który akapit uległ zmianie. Oszczędzi to konieczności analizy, co zostało zmienione w tłumaczeniu, innym tłumaczom.
5. W czasie tłumaczenia w oryginalnych opisach pakietów można natrafić na podkreślone słowa. Po najechaniu na nie kursorem, powinien pojawić się tooltip (tzw. dymek) z podpowiedzią pobraną z DDTSS wordlist (pl).
6. Niestety nie są dostępne tłumaczenia opisów pakietów z sekcji non-free. Wpływ mają na to licencje, które w wielu przypadkach uniemożliwiają wykonywanie tłumaczeń.

Zasady ustalone wewnętrznie

1. Tytuły opisów pakietów są pisane wielką literą, pomimo tego, że na ich końcu nie stawiamy kropki. Traktujemy je nie tylko jako skrócony opis, ale jako formę nagłówka.
2. Unikamy zaimków osobowych (zwłaszcza zaimka „Ty”), jeśli nie można to piszemy je wielką literą (staramy się unikać pisania bezpośrednio do użytkownika).
3. Budując zdania, staramy się używać strony biernej. Zdecydowanie lepiej czyta się tak napisane opisy.
4. Nazwy pakietów i poleceń piszemy bez cudzysłowów. Jak również nie piszemy wyrazów między apostrofami (sporadycznie dopuszczane są wyjątki gdy wynika to z kontekstu).
5. Konsekwentnie używamy słów menedżer (pomimo również poprawnego menadżer), GNOME (zamiast „Gnome”), widżet (zamiast angielskiego „widget”). „Package” to dla nas zawsze pakiet, a nie paczka, zaś „command line” to wiersz poleceń.
6. Używamy starej odmiany słów zakończonych na x (Linux-Linuksa itp.). Jest ona częściej spotykana i lepiej akceptowana.
7. Opisy pakietów, które różnią się od siebie w niewielkim stopniu (np. pakiety językowe) lub takie, które posiadają dużą wspólną część, tłumaczymy według uzgodnionej zależności. Zawsze tłumaczymy najpierw główny pakiet (w przypadku pakietów językowych, pakiet z językiem polskim), a dopiero gdy ustalimy wspólną wersję, kolejne pakiety z tej grupy.
8. Choć może nie jest to dobre, nie ma wśród nas lidera. Kwestie sporne przeważnie są rozstrzygane metodą demokratycznego głosowania.

Ogólnie przyjęte normy

1. Używamy poprawnej polszczyzny. Zarówno jeśli chodzi o gramatykę, ortografię, interpunkcję czy stylistykę. Wszystkie zdania powinny być napisane poprawnie zarówno pod względem ortograficznym, stylistycznym, interpunkcyjnym jak również gramatycznym (co nie jest rzeczą prostą). W kwestiach spornych pomocne będą słowniki PWN-u.
2. Interpretujemy tekst ,a potem go tłumaczymy. Unikamy w ten sposób tłumaczenia dosłownego i „słowo w słowo”, które nie odzwierciedla sensu, a wprowadza czytającego w zdumienie.
3. Nie dodajemy niczego od siebie. Czyli nie dopisujemy niczego, co nie wynika bezpośrednio z tłumaczenia. Dopuszczalne są oczywiście pewne uzasadnione wyjątki. Jednak tylko w sytuacjach gdy przetłumaczony tekst zbyt wiernie trzymający się oryginału jest nieprecyzyjny lub mógłby wprowadzić w błąd użytkownika.
4. Używamy słowników:
   ling.pl
   LEKSYKA.PL
   MEGAslownik
   DICT
   Słownik informatyczny angielsko-polski
   Słownik referencyjny Wolnego Oprogramowania
5. Unikamy syndromu gadającego komputera. Wszelkiego rodzaju zwroty w pierwszej osobie powinny zostać zastąpione wyrażeniami w formie bezosobowej.
6. Kierujemy się innymi tłumaczeniami i je ujednolicamy. Unikamy tworzenia wielu tłumaczeń tych samych zwrotów i akapitów.
7. Nie kierujemy się osobistymi sentymentami do osób tłumaczących. W dyskusji każdy ma prawo zabrać głos.
8. Nie staramy się tworzyć tłumaczeń „byle więcej i szybciej”. Wszelkie zauważone błędy należy poprawiać. W razie wątpliwości należy zostawić komentarz, by inni mogli się zastanowić nad daną kwestią.
9. Oryginalne opisy czasem zawierają błędy rzeczowe, które również staramy się poprawiać . Należy wtedy sięgnąć po źródła w internecie (np. strony domowe), by rozstrzygnąć jak prawidłowo powinna być napisana np. nazwa programu, systemu etc.
10. Opisy pakietów do tłumaczenia należy wybierać takie, które jesteśmy w stanie przetłumaczyć i jesteśmy tego tłumaczenia w miarę pewni. Metoda może nie jest odkrywcza, ale zmniejsza ilość pracy przy korekcie. Oczywiście nabierając doświadczenia, dobrze jest czasem wziąć „na warsztat” trudniejszy opis.
11. W komentarzach używamy podpisów. Aby łatwiej było je czytać i dyskutować ustalony został pewien schemat. Używamy trzech pierwszych liter z pseudonimu, po nich stawiamy dwukropek, a przed nimi spację – aby łatwiej wyróżnić nowy post.
    

     xxx: Treść komentarza.

12. Pracując nad tłumaczeniami należy mieć świadomość pewnej odpowiedzialności za projekt. Tłumaczenia mogą funkcjonowac w bazie Debiana przez lata i być czytane przez setki osób. Dlatego też akceptując tłumaczenie, a w szczególności zatwierdzając trzecie by wysłac tłumaczenie do bazy, należy robić to w przekonaniu o jego poprawności. W przypadku zmęczenia, braku koncentracji, niepewności lepiej dołączyć tylko komentarz lub odłożyć takie operacje na inny termin albo zdać się na kogoś innego. Pośpiech jest całkowicie niewskazany.

Przydatne strony

1. Na stronie statystyk znajdziemy odnośniki do statystyk tłumaczeń. Aktualnie są to gałęzie Etch, Lenny, Squeeze i Sid . Dbamy o to, aby pakiety z trzech pierwszych kategorii, czyli Wymaganych, Ważnych i Zwykłych (ang. Required, Important i Standard) były przetłumaczone w 100%. Dążymy również, aby przetłumaczyć wszystkie opisy z kategorii Popcon500 (czyli 500 najczęściej używanych pakietów według statystyk projektu Popcon). Po najechaniu myszą na daną kategorię wyświetlanych jest kilka przykładowych nazw pakietów z brakującym tłumaczeniem.
2. Wyszukiwarka pakietów umożliwia sprawdzenie opisów w różnych dystrybucjach Debiana, a także szybkie sprawdzenie tłumaczeń na inne języki (o ile oczywiście istnieją).
3. Główna strona DDTP. Oprócz wykresów stanu tłumaczeń dla różnych języków, kliknięcie jednej z liter na górze strony powoduje wyświetlenie wszystkich pakietów dostępnych do tłumaczenia na daną literę. Ponadto, strona pokazuje wszystkie wersje opisów, wraz z ich identyfikatorami (numerami). Niekiedy jest to przydatne, gdy chcemy przetłumaczyć inną wersję opisu niż ta proponowana przez system – wystarczy wtedy wprowadzić jej numer w polu Fetch specific description.
4. Wszystkie już przetłumaczone opisy, które weszły do wydania Sida można znaleźć tutaj. Bywa to pomocne przy ujednolicaniu tłumaczeń (zmieniając w adresie nazwę gałęzi np. squeeze otrzymamy analogiczny dla niej spis).

Kilka form pomocy

• Umiesz tłumaczyć. Zapraszamy. Jak zawsze nowym użytkownikom proponujemy rozpoczęcie tłumaczenia od akceptowania zmian w tłumaczeniach z sekcji „Pending review”.
• Mile widziane są osoby z dobrą znajomością zasad polskiej pisowni, mogące się spełnić w roli nie tylko tłumacza ale i korektora. Naszym celem jest nie tylko otrzymanie zgodności kontekstu tłumaczeń z oryginałami ale również to aby te tłumaczenia, odpowiadały normom języka polskiego.
• Nie umiesz/nie możesz tłumaczyć. Trudno. Jednakże mamy prośbę, zainstaluj u siebie pakiet popularity-contest i wykonaj:

  
dpkg-reconfigure popularity-contest

  Program ten będzie wysyłał anonimowe statystyki najczęściej używanych aplikacji w systemie do deweloperów Debiana. Pomogą one nam w ustawianiu priorytetów na tłumaczenia opisów. Im wyższy priorytet – tym szybciej dane tłumaczenie opisu zostanie wykonane. Statystyki te można podejrzeć na stronie projektu Popcon.

• Znalazłeś błąd, a nie chcesz samodzielnie go poprawiać? Masz wątpliwości. Opisz je w komentarzu lub napisz do któregoś z tłumaczy.

Podsumowanie

Tłumaczenie opisów pakietów to jeden z elementów projektu internacjonalizacji dystrybucji. Niestety projekt boryka się z kilkoma problemami, z których najpoważniejszy to braki kadrowe do wykonania tej ogromnej pracy. Na chwilę obecną w repozytoriach Debiana znajduje się ponad 25000 pakietów, których z roku na rok przybywa. Jak widać pracy nie brak. Na ostatniej konferencji deweloperów Debiana – Debconf zaproponowano pewne zmiany odnoszące się do długich opisów pakietów mające na celu zmniejszenie liczby tłumaczeń, które tracą ważność z powodu drobnych zmian w oryginale. Dzięki temu mniej czasu będzie trzeba poświęcać na czuwanie nad utrzymywaniem aktualności tłumaczeń, co oczywiście przekłada się na czas jaki można poświęcić na tłumaczenia nowych opisów.
Polska w projekcie DDTP plasuje się w środku stawki, choć powodów do wiwatów, biorąc pod uwagę statystyki na razie nie ma. Obecnie nie mamy szans rywalizować z tak prężnymi ekipami tłumaczy jak niemiecka czy czeska, standardowy powód – brak tłumaczy. Mamy nadzieję, że ten artykuł–poradnik pokazał jak przebiega proces tłumaczenia od strony technicznej. Jednocześnie zachęcając użytkowników Debiana, którzy mają stosowne predyspozycje do tłumaczenia do podzielenia się swoim czasem i wiedzą dla projektu.

Pozdrawiamy i zapraszamy do udziału w projekcie DDTP.

Autorzy: Yantar, Mickul oraz Swamper

W tym poście postaram się przedstawić listę najważniejszych zmian, jakie zaszły od czasu poprzedniego wydania Kubuntu 9.04. Nowe Kubuntu to nie tylko zaktualizowane pakiety aplikacji, jądra, czy bibliotek, ale także nowe możliwości systemu. Zagłębmy się zatem, w te najważniejsze. Zacznijmy od najbardziej widocznych, czyli KDE.

KDE4 – Interfejs przyszłości

O samym środowisku można poczytać tu, albo tu, czy też tu. Jeżeli chodzi o zmiany, które wprowadzono do Kubuntu, to są to nowe powiadomienia znane ze środowiska GNOME. Można wybierać pomiędzy rodzajem powiadomień. Jeżeli chodzi o te, znane z GNOME, to użytkownik może określić ich położenie na ekranie.

Do samego KDE dodano moduł konfiguracji motywu GTK, dla aplikacji, które są napisane przy użyciu tej biblioteki. Poza wyborem motywu można określić czcionkę aplikacji, czy też wybrać własną ścieżkę dla motywów.

Domyślnie w Kubuntu 9.10 na pulpicie znajduje się dodany plasmoid, który umożliwia nam korzystanie z takich serwisów jak Twitter, czy Indeti.ca. Domyślnie pokazywane są wiadomości, które zachęcają do pomocy przy pracy nad Kubuntu. Wchodząc w ustawienia możemy podać własną nazwę użytkownika i hasło, oraz wybrać serwis, z którego chcemy korzystać.

Jeżeli chodzi o zmiany w samym KDE, to wymieniłem najważniejsze. Reszta nie odbiega od oryginalnej wersji dostarczonej przez programistów KDE.

KpackageKit

Menedżer pakietów Kubuntu posiada teraz nowe powiadomienia, które są zintegrowane ze środowiskiem. Duża część interfejsu samego okna instalacji/usuwania programów została poprawiona usuwając niepotrzebny tekst. Cały proces instalacji został wzbogacony o ładne animacje, które prezentują aktualnie wykonywaną czynność. KpackageKit otrzymał również ikonę w tacce systemowej.

Aplikacje

W końcu będzie można cieszyć się K3B przeportowanym na Qt4. Nie potrzebne już są zależności z KDE3. Dragon Player zastąpiony został nową wersją Kaffeine dla KDE4. Amaroka znajdziemy w najnowszej wersji 2.2, która wnosi wiele usprawnień. Użytkowników ucieszy fakt, iż kreator USB został przeportowany na bibliotekę Qt4. OpenOffice integruje teraz swój wygląd ze stylem Oxygen. Dodatkowo zobaczymy w nim ikony z zestawu Oxygen. Mimo propozycji zmian, domyślną przeglądarką WWW zostaje Konqueror. Teraz nie potrzebujemy aplikacji KUser, aby graficznie zarządzać użytkownikami i grupami w systemie. W nowym Kubuntu znajdziemy odpowiedni do tego moduł, który znajduje się w aplikacji Ustawienia systemowe. Posiada on przejrzysty interfejs, który ułatwi nam wykonywane czynności.

Instalator Firefoksa, to łatwy i wygodny sposób na zainstalowanie w swoim systemie przeglądarki Firefox. Wystarczą trzy kliknięcia myszką i możemy cieszyć się najnowszą wersją Firefoksa.

Ubiquity

Ubiquity to nowy instalator Kubuntu. Posiada odświeżony wygląd, którym jeszcze bardziej zachęca do zainstalowania i przetestowania Kubuntu na swoim komputerze. Jest intuicyjny i łatwy w obsłudze, co pozwoli nowicjuszom na bezproblemową instalację systemu.

Podsumowanie

Podsumowując, całość działa bardzo sprawnie. Testy przeprowadzane na wersji beta systemu przy użyciu LiveCD dla procesorów 64bitowych. Jeszcze 15 dni i nowe Kubuntu zagości na moim domowym “piecyku”. Zapraszam wszystkich zainteresowanych do przetestowania nowego Kubuntu.

Wiadomość źródłowa: Kubuntu Karmic Koala – przegląd zmian

Jesień Linuksowa 2009 za nami. Kto nie był — niech żałuje. Ja byłem, widziałem, przemawiałem, w związku z czym postanowiłem na świeżo zrelacjonować to co działo się na imprezie.

Tegoroczna Jesień odbyła się w bardzo sympatycznych okolicznościach przyrody. Dzikiej przyrody. Niepowtarzalnej. O Linuksie i tym podobnych ustrojstwach biadoliliśmy bowiem u podnóża Gór Świętokrzystkich, w hotelu Jodłowy Dwór w miejscowości Huta Szklana. Zaowocowało to nietypowym planem zajęć. W sobotę bowiem, w przerwie między wykładami a lightening speeches, wybraliśmy się na wyprawę po zamku Krzyżtopór. Kto chciał mógł wejść też na Święty Krzyż, zwiedzić gołoborza i spędzić czas w towarzystwie kółek różańcowych licznie nawiedzających te okolice, w szczególności w weekendy.

No ale do rzeczy.

Na Jesieni pojawiliśmy się w sobotę rano (co zawdzięczamy li tylko silnej woli, która pozwoliła nam wstać wczesnym ranem na pociąg relacji Warszawa-Kielce, odjazd 5:20). Udało nam się więc obejrzeć pierwszy wykład drugiego dnia, prezentację specjalisty od standardów, Dominika Tomaszuka, na temat dwóch nowych formatów internetowych tworzonych przez organizację W3C: XHTML 2 oraz HTML 5. Dowiedzieliśmy się o wspólnych założeniach tych nadchodzących standardów, o głównych różnicach oraz o tym, że Dominik woli XHTMLa, bo strony powinni tworzyć specjaliści a nie amatorzy nie potrafiący zamknąć taga. Prezentacja ciekawa, (aż za) bardzo zgłębiająca temat — dla kogoś komu nigdy nie chciało się poczytać na ten temat, świetne wprowadzenie do tematu.

Niestety nie udało mi się obejrzeć drugiej sobotniej prezentacji, w której Robert Partyka (znany czytelnikom jakilinux.org i LinuxNews jako BoBsoN) rozszerzył prezentację Dominika opowiadając szczegółowo o elementach Canvas i Canvas:3D, będących częścią nowych standardów.

Po Robercie na scenie pojawił się Marcin Hłybin aka ahes, twórca serwisu hostingowego rootnode.net. Opowiadał on o tym dlaczego jego MTA jest lepsze niż twoje. Czyli o Postfiksie. Jeśli ktoś tworzyłby listę rzeczy, których należy unikać robiąc prezentacje, wystąpienie Marcina mogłaby posłużyć za antyprzykład w punkcie “zawsze przygotuj sobie backup materiałów (w tym plików konfiguracyjnych, stron internetowych) w razie jakby nawalił Internet”. Ubuntu Marcina niestety uznało, że na czas prezentacji odłączy się od sieci, w związku z czym nie dane nam było obejrzeć wszystkich ciekawych przykładów związanych z konfigurowaniem Postfiksa (bo o nim był wykład) ani też zobaczyć jak wygląda wypasiona konsola na serwerach rootnode. Na szczęście dzięki entuzjazmowi prowadzącego i dynamicznemu sposobowi prezentowania, udało się uniknąć zupełnej tragedii. Otrzymaliśmy dość ogólny wykład na temat MTA, możliwości Postfiksa i przykładów jego wykorzystania w praktyce.

Po wykładzie Marcina odbył się uroczysty obiad, a następnie prawie cała Jesień ruszyła na podbój Krzyżtoporu. Krzyżopór to zamek Ossolińskich, ulokowany ok 30 kilometrów od hotelu. Przetrwał on z lepszym lub gorszym (w większości z tym drugim) skutkiem wiele najazdów, ale nigdy jeszcze nie został nawiedzony przez ponadpięćdziesięcioosobową hordę Linuksiarzy. Jak to wyglądało możecie obejrzeć na dwóch moich amatorskich filmikach:

Jesień Linuksowa – zbiórka przed Krzyżtoporem from michuk on Vimeo.

Krzyżtopór from michuk on Vimeo.

Po powrocie z podboju Krzyżtopora przyszedł czas na krótkie pięciominutowe przemowy na dowolny temat:

• Pokazał się więc przedstawiciel projektu OpenStreetMap, który opowiedział w ekspresowym tempie czym jest projekt i jak można się przyłączyć.
• Był też honey, który jak zwykle namawiał do promowania zamkniętych standardów, lobbowania za większą liczbą umów SELECT w administracji publicznej i powiedzeniu w końcu dość utopii jaką jest neutralność sieci (jeśli do kogoś przemówiły te niedorzeczne argumenty, warto się z nim skontaktować w celu otrzymania instrukcji na temat spamowania naszych europarlamentarzystów).
• Pojawił się ponownie ahes, który opowiedział tym razem o swoim innym projekcie pod nazwą “alleDrogo”.
• Krzysiek Leszczyński zaapelował o pomoc przy tworzeniu Pingwinariów 2010, bo bez niej impreza ta może się po prostu nie odbyć (Agusia-mama raczej ma ważniejsze zajęcia niż organizowanie zlotu Linuksiarzy).
• Mówił też ktoś jeszcze, kogo niestety pominę z powodu sklerozy. Aktualizacja: Skleroza pominęła Savika, strzelającego bez ładu i składu (z powodu braku czasu na podrapanie się po głowie) o projekcie Moovida.

Na tym skończyła się oficjalna część drugiego dnia Jesieni. Wieczorem wszyscy zajadali kiełbaski z bigosem, pili i dobrze się bawili. A ja poszedłem spać.

Ojciec Dyrektor Jesień (Darek Grzesita) i Ojciec Dyrektor Grupy Jakilinux (michuk)

Ostatniego dnia Jesieni, w niedzielę, odbyły się trzy prezentacje. Pierwszą, na temat projektu Apache Hadoop, wygłosił Piotr Praczyk. Potem mówiłem ja na temat otwartych serwisów internetowych na przykładzie serwisu Filmaster.pl, którym zajmuję się od ponad roku. Na koniec Dariusz Puchalak zaprezentował mniej typowe zastosowania SSH. Prezentację Dariusza śmiało mogę określić najlepszą jaką dane mi było oglądać. Temat wprawdzie bardzo oklepany i opisany na niejednym blog/serwisie, w tym na jakilinux.org w takich tekstach jak Sztuczki z SSH czy SSH tunele, ale Darek przedstawił go w ciekawy sposób, dynamicznie i na licznych przykładach. Przyjemnie się tego słuchało a prezentacja (warto ściągnąć bo nie będzie tam zapewne leżeć wiecznie) jest świetnym kompendium wiedzy na temat tego popularnego protokołu.

Dariusz Puchalak z SSH korzysta z zamkniętymi oczami

Pomiędzy niedzielnymi wykładami rozlosowano też nagrody, m.in. książki związane z Linuksem i wolnym oprogramowaniem, koszulki oraz dziwne urządzenia do trenowania mięśni dłoni (dziękuję Przemkowi Kulczyckiemu za fachowe wyjaśnienie o co w tym chodzi :>).

Jesień Linuksowa – losowanie nagród from michuk on Vimeo.

Niestety ze względu na pracę i dojazd nie mogłem być na imprezie od piątku. Przeoczyłem więc dwa wykłady: projektu P.I.W.O. oraz Mariusza Droździela na temat wysokowydajnych i wysokodostępnych systemów pod Linuksem. Ten drugi uratował mi za to życie podwożąc nas z Huty do Warszawy, za co jeszcze raz wielkie dzięki!

Organizacyjnie “Jesień” jak zwykle stała na wysokim poziomie. Nie obyło się oczywiście bez kilku zonków, typu brak ogrzewania w hotelu pierwszego dnia imprezy, czy przerywające WiFi, ogólnie jednak jak na takiej wielkości imprezę (przybyło około 80 fanów Linuksa z całej Polski) było bardzo dobrze, co najmniej porównywalnie z zeszłym rokiem (tu moja relacja). Na szczególne wyróżnienie zasługuje świetny pomysł ze streamowaniem wideo na żywo. Drugie tyle osób co na sali oglądało prezentacje na żywo w Internecie. Wszystkie wykłady mają też być dostępne niedługo w sensownym formacie i lepszej jakości do ściągnięcia ze strony organizatorów, a już teraz ściągnąć można PDFy ze strony z materiałami z Jesieni.

Do zobaczenie za rok!

Wczoraj wydana została nowa wersja środowiska graficznego GNOME. Zespół Aviary.pl dzielnie przetłumaczył informacje o wydaniu. Jest co czytać więc zapraszam do lektury.

Tłumaczenie zostało oryginalnie opublikowane na stronie dokumentacji GNOME pod tytułem GNOME 2.28 ― informacje o wydaniu. Nie mam pojęcia na jakiej jest licencji, ale zakładam że na wolnej. Jeśli się mylę, bardzo proszę o naprowadzenie.

1. Wprowadzenie

GNOME 2.28 to najnowsza wersja popularnego, wieloplatformowego, graficznego środowiska do pracy z komputerem. Najważniejszymi cechami środowiska jest łatwość użycia, stabilność oraz najlepsza dostępność i tłumaczenie. Projekt GNOME tworzy oprogramowanie o wolnym kodzie źródłowym, które zawiera wszystkie elementy nowoczesnego środowiska pracy z komputerem. Są to programy do: obsługi poczty elektronicznej, pracy grupowej, zarządzania plikami i multimediami oraz gry. GNOME to także elastyczna platforma programowania o dużych możliwościach, przeznaczona dla komputerów osobistych i urządzeń przenośnych.

Rysunek 1 GNOME 2.28

Środowisko GNOME jest wydawane co sześć miesięcy. Każde wydanie zawiera wiele nowych funkcji, usprawnień, poprawek błędów i tłumaczeń. Wydanie GNOME 2.28 nie jest wyjątkiem. Więcej informacji o środowisku GNOME i o cechach (użyteczność, dostępność, internacjonalizacja i wolność), które wyróżniają je spośród innych systemów i środowisk, można znaleźć na stronie About GNOME (w języku angielskim).

Dołącz do nas i przekonaj się, że każdy może zmieniać świat.

Wydanie GNOME 2.28 zawiera wszystkie usprawnienia dokonane w wersji GNOME 2.26 i wcześniejszych. Więcej informacji o zmianach w wersji GNOME 2.26 można znaleźć w odpowiednich informacjach o wydaniu.

3. Nowości dla użytkowników

Użytkownicy i użyteczność są od zawsze w centrum uwagi projektu GNOME. W wersji 2.28 poprawiono setki błędów i dodano wiele usprawnień wnioskowanych przez użytkowników. Wypisanie ich wszystkich w tym miejscu nie jest możliwe, dlatego wspomnimy tylko o najważniejszych i najciekawszych funkcjach przeznaczonych dla użytkowników.

• 3.1. Bez kabli
• 3.2. Lepsze zarządzanie czasem
• 3.3. Komunikator Empathy
• 3.4. Przeglądarka WWW Epiphany
• 3.5. Usprawnienia odtwarzacza multimediów
• 3.6. Uśmiechnij się do zdjęcia!
• 3.7. Adnotacje w plikach PDF
• 3.8. Regulacja głośności kanałów przednich i tylnych
• 3.9. Ale to nie wszystko…

3.1. Bez kabli

GNOME 2.28 zawiera pierwsze wydanie modułu GNOME Bluetooth, zarządzającego urządzeniami Bluetooth. Moduł ten obsługuje setki urządzeń Bluetooth takich jak myszy, klawiatury i zestawy słuchawkowe. Moduł GNOME Bluetooth jest zintegrowany z serwerem dźwięku PulseAudio, co pozwala obsługiwać zestawy słuchawkowe i słuchawki stereo.

Moduł GNOME Bluetooth obsługuje także połączenia internetowe przez telefon komórkowy. Po powiązaniu telefonu z modułem GNOME Bluetooth, Menedżer sieci uzupełni listę połączeń o wpis dotyczący dostępu przez telefon komórkowy.

Rysunek 2 Moduł GNOME Bluetooth

3.2. Lepsze zarządzanie czasem

Aplet Zarządzania czasem, który pomaga w zarządzaniu czasem i zadaniami, zawiera szereg nowych usprawnień.

Całkowicie nowy ekran przeglądu zadań ma bardziej przejrzysty układ, który łączy kategorie i okresy. W interfejsie po raz pierwszy wykorzystano kolory, aby ułatwić wyświetlanie proporcji czasu względem różnych czynności.

Inne funkcje to m.in. poprawione automatyczne dopełnianie, które pozwala aktualizować na żywo czas rozpoczęcia zadania, udoskonalone funkcje dla użytkowników pracujących w nocy oraz możliwość dodawania zadań, które zostały już ukończone. Wiele usprawnień można znaleźć w funkcjach eksportu – możliwość filtrowania wg kategorii i dacie oraz nowe typy eksportowanych plików: iCal do eksportu do programu Evolution, Kalendarza Google i innych klientów oraz XML i TSV (wartości rozdzielone znakiem tabulatora), które łatwo można importować do arkuszy kalkulacyjnych.

Rysunek 3 Zarządzanie czasem

3.3. Komunikator Empathy

Komunikator Empathy, który korzysta z biblioteki komunikacyjnej Telepathy, uzyskał kilka nowych i ważnych funkcji pomocnych w komunikacji.

Ulepszono wiele elementów listy kontaktów. Można ustawić własny stan bezpośrednio wprowadzając go jako tekst lub wybrać go z poprzednio używanych. Organizowanie kontaktów jest łatwiejsze, ponieważ przeciąganie i upuszczanie powoduje ich przenoszenie, a nie kopiowanie. Dodane zostało menu Widok, które umożliwia szybki dostęp do sortowania kontaktów, wyświetlania użytkowników niepodłączonych, a także do zmiany preferencji rozmiaru listy kontaktów.

Rysunek 4 Kontakty Empathy

Okno rozmowy obsługuje teraz kilka nowych motywów, włączając w to wiadomości w stylu programu Adium. Nad “użytkownikami” w liście kontaktów wyświetlane są teraz podpowiedzi; lista użytkowników w pokojach rozmów może zostać ukryta; menu Kontakty zostało usunięte z menu Rozmowa; jeśli pseudonim użytkownika został użyty podczas rozmowy w pokoju rozmów lub zwykłej rozmowy, to tekst karty zmieni się na czerwony.

Rozmowy głosowe i wideorozmowy mogą teraz odbywać się na pełnym ekranie, a jeśli rozmówca nie przesyła obrazu, to wyświetlany jest jego awatar. Dodana została funkcja ponownego wybierania, aby ułatwić ponowne połączenie.

Użytkownicy mogą teraz współdzielić swój pulpit przez komunikator Empathy, używając przeglądarki zdalnych pulpitów Vino.

Dla kontaktów XMPP takich jak Jabber czy Google Talk dodano obsługę geolokalizacji za pomocą usługi Geoclue. Można wyświetlać położenie kontaktów zatrzymując kursor myszy nad wybranym kontaktem w liście. Informacja ta jest też dostępna w oknie dialogowym informacji oraz w widoku mapy. Komunikator Empathy obsługuje także tryb zmniejszonej dokładności dla użytkowników, którzy życzą sobie więcej prywatności. Użytkownicy Google Talk mogą wyświetlać położenia kontaktów, ale nie mogą publikować własnego, ponieważ Google nie obsługuje standardu PEP.

Komunikator Empathy zawiera także nową dokumentację, w której nacisk położono na pomoc w wykonywaniu określonych zadań w programie.

3.4. Przeglądarka WWW Epiphany

Przeglądarka WWW Epiphany używa teraz modułu renderowania WebKit zamiast Gecko. Zmiana powinna być niewidoczna dla użytkowników, istnieją jednak pewne korzyści wynikające z lepszej wydajności. W dłuższej perspektywie zmiana na moduł WebKit przyniesie istotne korzyści dla użytkowników przeglądarki Epiphany. Moduł Webkit poprawia także wiele błędów związanych z poprzednim modułem Gecko. Zachęcamy do testowania tej nowej wersji i sprawdzenia, czy uprzednio napotkane problemy nadal występują.

Jedną z usterek związaną ze zmianą na moduł wyświetlania WebKit jakiej mogą doświadczyć użytkownicy przeglądarki Epiphany, to niemożność zapisywania danych logowania w formularzach. Ten błąd zostanie poprawiony podczas cyklu wydania 2.30.

3.5. Usprawnienia odtwarzacza multimediów

Odtwarzanie filmów DVD w Odtwarzaczu filmów Totem zostało usprawnione dzięki umożliwieniu nawigacji po menu DVD i wznawiania odtwarzania od ostatniej pozycji. Wtyczka YouTube działa teraz szybciej.

3.6. Uśmiechnij się do zdjęcia!

Cheese, program do robienia zdjęć i nagrywania filmów za pomocą kamery internetowej, zawiera wiele usprawnień. Zaktualizowano interfejs użytkownika i dodano tryb zdjęć seryjnych. Można wybrać liczbę zdjęć do zrobienia w jednej serii oraz opóźnienie czasowe między zdjęciami. Program Cheese umożliwia także ręczne robienie zdjęć za pomocą przycisku migawki w kamerach internetowych.

Interfejs użytkownika programu Cheese został zoptymalizowany pod kątem mniejszych ekranów, takich jak w netbookach, poprzez przeniesienie paska miniaturek na prawo. Poniższy zrzut ekranu ilustruje tryb zdjęć seryjnych programu Cheese w nowym, szerokim trybie wyświetlania, zoptymalizowanym dla netbooków.

Rysunek 5 Tryb szeroki dla netbooków

Aby dowiedzieć się więcej o programie Cheese, można zajrzeć na stronę przeglądu jego funkcji (w języku angielskim).

3.7. Adnotacje w plikach PDF

Przeglądarka dokumentów Evince umożliwia teraz dodawanie i modyfikowanie adnotacji tekstowych, z którymi powiązane są wyskakujące okna. Program Evince obsługuje także odzyskiwanie dokumentów po wystąpieniu awarii.

Program Evince został także przystosowany do pracy na platformach Microsoft Windows®.

3.8. Regulacja głośności kanałów przednich i tylnych

Program Kontrola głośności umożliwia regulację natężenia głośności głośnika niskotonowego oraz głośników przednich i tylnych. Zmiany są teraz stosowane natychmiastowo.

Rysunek 6 Obsługa głośnika niskotonowego oraz głośności przednich i tylnych głośników

3.9. Ale to nie wszystko…

Obok dużych zmian w każdym wydaniu środowiska GNOME jest też wiele małych dodatków i usprawnień.

• Przyciski i menu w środowisku GNOME zostały ujednolicone tak, aby domyślnie nie wyświetlały się w nich ikony. Elementy menu z dynamicznymi obiektami, włącznie z programami, plikami i zakładkami oraz urządzenia są wyjątkami i mogą wyświetlać ikonę. Ta zmiana standaryzuje wygląd menu i sprawia, że interfejs użytkownika jest bardziej przejrzysty.
• Notatnik Tomboy przechowuje teraz notatki i pliki konfiguracji w położeniu zgodnym ze specyfikacjami Freedesktop.org.
• Menedżer zasilania obsługuje teraz laptopy z wieloma akumulatorami, ma także dodaną obsługę zatrzymywania pracy dysków twardych zarządzanych przez usługę systemową DeviceKit.
• Mechanizmy drukowania GTK+ file i lpr obsługują drukowanie wielu stron na pojedynczej kartce.
• Program Gedit został przystosowany do pracy na platformie Mac OS® X.
• Polepszono renderowanie tekstu w Pango przy pomocy nowego silnika OpenType, w którym zmniejszono zużycie zasobów pamięci i poprawiono wsparcie dla czcionek typu broken.
• Dzięki usprawnieniom w VTE, GNOME Terminal będzie zużywał mniej zasobów.
• Brasero, program do nagrywania płyt CD/DVD w GNOME, posiada obecnie możliwość nagrywania danych na wielu nośnikach. Dodano do interfejsu wyświetlanie graficzne dostępnego miejsca na nośnikach przed dokonaniem zapisu na nich.

8. Plany dotyczące GNOME 2.30

Prace nie kończą się wraz z wersją GNOME 2.28. Rozpoczęły się już prace nad GNOME w wersji 2.30, które ukaże się dokładnie sześć miesięcy po wersji 2.28.

Ostateczna decyzja, czy GNOME 2.30 (wydanie w marcu 2010), czy GNOME 2.32 (wydanie we wrześniu 2010) będzie określone jako GNOME 3.0 zostanie podjęta na początku listopada 2009. Ta decyzja będzie oparta na postępie rozwoju nowych i bieżących programów oraz bibliotek GNOME, a także ich wpływie na dostępność, stabilność i użyteczność.

GNOME 2.30 nadal będzie dostarczać środowisko i programy jak zawsze, a także potencjalnie nowy interfejs użytkownika w Powłoce GNOME oraz Dziennik Aktywności GNOME, które mogą w łatwy sposób pomóc w przeglądaniu i odnajdywaniu plików. W GNOME 2.30 niektóre biblioteki zostaną wycofane z użytku.

Wersja poglądowa Powłoki GNOME jest dostępna w wersji 2.28 i można ją pobrać. Powłoka GNOME to innowacyjny interfejs użytkownika, który korzysta z możliwości animowanego pulpitu. Powłoka GNOME pozwala na łatwe dodawanie dodatkowych obszarów roboczych, uruchamianie często używanych programów, a także na dostęp do najczęściej używanych plików i dokumentów.

Rysunek 7 Powłoka GNOME

Dziennik aktywności GNOME to narzędzie pozwalające na łatwe przeglądanie i odnajdywanie plików. Przechowuje chronologiczny dziennik aktywności zmian i dostępu do wszystkich plików, obsługuje etykiety i powiązania między grupami plików. Dziennik Aktywności GNOME jest graficznym interfejsem użytkownika dla Zeitgeist, mechanizmu śledzącego aktywność na pulpicie, z obsługą etykiet i zakładek.

Tomboy Online jest planowny dla GNOME 2.30, będzie umożliwiał użytkownikom synchronizację i dostęp do notatek programu Tomboy przez Internet.

Strona GNOME’s roadmap (w języku angielskim) zawiera szczegółowy plan programistów dla następnego cyklu wydania. Strona harmonogramu wydania GNOME 2.30 została wydana w tym roku i jest dostępna na stronach wiki projektu GNOME (w języku angielskim).

Z zainteresowaniem przeczytałem artykuł zamieszczony jako “Artykuł tygodnia” — pod tytułem “O kłopotach z chmurami” — i muszę stwierdzić, że uczucia jakie mi towarzyszyły podczas lektury to, oprócz zainteresowania, ból zębów (to od zgrzytania) oraz lekkie pragnienie. Pragnienie właśnie zaspokajam pisząc artykuł polemiczny, który mam nadzieję, zostanie opublikowany po starej znajomości.

Autorem artykułu w oryginale zatytułowanego “Not every cloud has a silver lining” jest kanadyjski dziennikarz oraz autor powieści SF Cory Doctorow. Jest też aktywistą, działającym m.in. w EFF, o ewidentnie lewicowym zacięciu — co tłumaczy jego obecność na łamach lewicowej gazety, jaką jest Guardian. To, że autor jest nade wszystko dziennikarzem i powieściopisarzem częściowo tłumaczy poziom owego arcydzieła żurnalizmu spod znaku “bardzo jasne stanowisko niezmącone jakąkolwiek znajomością tematu”.

Na jaki temat rozmawiamy?

Pamiętacie zapewne głoszone w latach 90. przez firmę Sun hasło “Network is a Computer”? Ówczesna interpretacja tej dewizy ograniczała się do wizji monitora podłączonego do internetu — z doświadczenia wiemy, że ten pomysł był wysoce nietrafiony i oprócz nielicznych wyjątków praktycznie nie jest stosowany obecnie.

Nie wiedzieć dlaczego Cory Doctorow uważa, że Cloud Computing sprowadzi jego stacje roboczą do poziomu terminala bezdyskowego. W przeciwnym razie dlaczego porównuje koszt dysku do komputera z kosztem utrzymania powierzchni dyskowej w serwerowni?

Autor wyraźnie nie dostrzega czegoś co obecnie staje się coraz bardziej jasne — Internet może dostarczać kolejnej warstwy, która lokuje się między systemem operacyjnym i lokalnymi zasobami przetwarzania, a aplikacjami i zdalnymi zasobami przetwarzania (Cloud Computing). Tak jest — aplikacje oddalają się od systemu operacyjnego stacji klienckiej (a tym samym od jej sprzętu), co pozwala na dostęp do tej samej funkcjonalności oraz danych z dowolnego urządzenia (telefon, netbook, laptop, macbook etc.).

Prawdziwe koszty IT – magia 6%

Powodem dla którego świat tak bardzo interesuje się Cloud Computing (a w konsekwencji także Software as a Service) jest chęć ograniczenia kosztów, jakie obecnie są ponoszone na technologie informatyczne. Tylko tyle. Per saldo stosowanie tego podejścia powinno nam się dużo bardziej opłacać niż trzymanie się tradycyjnego modelu.

Do myślenia dają dwa badania — relacja poziomu kosztów utrzymania IT (czarna dziura kosztów monitorowania i zarządzania coraz bardziej skomplikowanych środowisk) do wydatków, które mają bezpośrednie przełożenie na przewagę konkurencyjną inwestora to 80% do 20%. Z tego oczywiście biorą się wielomiliardowe obroty gigantów branży IT. Portfolio produktów przeznaczone tylko dla działów IT (nie usprawniających w żaden sposób biznesu firmy, która je kupuje!!!) przyprawia o zawrót głowy…

Drugie badanie pokazuje równie szokujący obraz — przeciętne wykorzystanie zasobów IT posiadanych przez firmy to… 6%. Badanie zrobiła firma McKinsey więc można zakładać w nim wiele uśrednień i czasami przekłamań, ale jeśli nawet pomylili się w znacznym stopniu, to i tak wynik szokuje.

Dla Cory Doctorowa jednak wykupienie usługi płatnej miesięczne wydaje się być równie zachęcające, co wybranie się na herbatkę i ciasteczka z wąglikiem do Lukrecji Borgii. Najwspanialszy jednak jest powód tej niechęci — bo firmy sprzedające subskrypcje będą na tym zarabiały!

Zaiste świat się wali! Kupno od Steve Ballmera paczki z MS Office lub budowanie w małych firmach działów IT jest zapewne równie chwalebne jak karmienie małych kotków butelką ze smoczkiem — jeśli jednak ktoś koszt systemu rozłoży nam na raty i udostępni w taki sposób, aby wygodnie było go używać z wielu urządzeń i w obrębie całego świata, staje się automatycznie sługą szatana i prawie na pewno jego dzieci nazywają się Belzebub i Lucyfer (nie mylić z Lucjan).

Konsolidacja głupcze!

Proste zadanie do wykonania w domu — proszę do 10 szklanek o pojemności 250 ml wlać po 100 ml wody (lub piwa — będzie pretekst żeby otworzyć — w końcu robimy eksperyment naukowy). Następnie kolejno zlewać wodę (ew. piwo) do szklanek tak, żeby jednak nie wylać, no i żeby zostało jeszcze trochę wolnego miejsca (powiedzmy 50 ml).

Ile zostało wam pustych szklanek? Czy jeśli zamienicie szklanki na serwery, a wodę na aplikacje, to widzicie oczyma wyobraźni spadek kosztów ponoszonych na technologie informatyczne przez firmy?

Ta koncepcja ma dokładny odpowiednik w świecie IT — w co najmniej dwóch postaciach. Pierwszą postacią zdobywającą coraz więcej zwolenników jest wirtualizacja. W wielu miejscach (głównie w małych i średnich firmach) jest to jednak próba naprawienia problemu, który tam nie powinien istnieć.

Drugim sposobem jest konsolidacja użytkowników aplikacji na platformach SaaS. I ta koncepcja z kolei niesie ze sobą ogromne konsekwencje dla świata IT jaki znamy — ma ogromny wpływ na indywidualnych użytkowników jak i małe i średnie firmy.
Co powiecie na uwolnienie się od pewnych monopolistów, których mamy na karku od wielu wielu lat?

Koszmarne sny Steve’a Ballmera

Trwające od wielu lat prace nad ulepszeniem przeglądarki internetowej mają na celu jedną rzecz: zniwelować różnicę w tzw. “user experience” jaki towarzyszy pracy na aplikacji dostępnej przez przeglądarkę w porównaniu z pracą z aplikacją instalowaną. Pojawienie się standardu HTML 5 oraz kilku jego rozszerzeń (m.in. webworkers, czyli współbieżność przetwarzania po stronie przeglądarki, czy możliwość pracy na aplikacji po odłączeniu od sieci) powoduje, że to jaki system operacyjny pracuje na stacji klienckiej traci na ważności.

Jeśli przeglądarka jest tym uniwersalnym środowiskiem pracy aplikacji, mamy do czynienia z dekompozycją nierozerwalnego do tej pory układu, jakim jest OS i Aplikacja. Stąd pomysł np. Google, aby wprowadzić system operacyjny Google Chrome OS, który zapewni rozwiązanie kilku problemów na raz — dostarczy stabilne środowisko pracy na stacji końcowej, będzie na tyle bogaty, że da możliwość pracy lokalnej, obsługi urządzeń peryferyjnych i szerokiej gamy sprzętu (stąd jądro Linuksa w układance), a jednocześnie na tyle ubogi w dodatki i zbędne aplikacje lokalne, aby nie powodować typowych obecnie problemów z MS Windows, tj. degradacji wydajności czy niskiego bezpieczeństwa ze względu na wszelkiej maści wirusy.

Wszelkie aplikacje niezbędne do pracy dostaniemy z “chmury”. Aby się przekonać jak może to wyglądać w przyszłości warto sprawdzić np. http://docs.google.com.

Jeśli weźmiemy pod uwagę fakt, że Microsoft czerpie ogromną większość swoich dochodów ze sprzedaży systemu operacyjnego oraz aplikacji biurowych, to widzimy, że wizja ta wydaje im się nieco przerażająca.

Słowo końcowe

Podnoszenie kwestii bezpieczeństwa informacji oraz stopnia zależności użytkowników od dostawców usług jest jak najbardziej ważkie. Omówienie tego to jednak zupełnie inny artykuł. Mam nadzieję jednak, że czytelnicy zgodzą się ze mną, że Cloud Computing, czy blisko spokrewniony z nim Software as a Service, to nie dzieło szatana, a twórcy tego rodzaju środowisk i aplikacji mają jeden cel — spowodować, że koszty dostępu do zaawansowanej technologii IT spadną drastycznie. W jednym zdaniu? Power to the people!

Korzystając z okazji, że za oknem pogoda dość nieciekawa, zrobiłem mały przegląd, co ciekawego zmieniło się od mojej ostatniej rewizji rozwojowego KDE 4.4. Jako, że mam nosa niczym Szarik z Czterech pancernych, trafiłem na prawie okrągłą wersję oznaczoną numerem r1024000.

KDE 4.4 r1024000

Nowy menadżer dodawania elementów Plazmy

Pierwsze co rzuciło mi się w oczy, to nie działający menadżer dodawania nowych apletów Plazmy z menu kontekstowego, dostępnego w prawym-górnym rogu ekranu. No to klops – ale można je przecież dodać z panelu – i tu niespodzianka. Wszystkie dostępne aplety wyświetlane są w postaci listy ikon, ułożonych w szeregu. Można je przewijać, odinstalować i dodawać. Naturalnie możemy wybrać konkretną kategorię lub wyszukać konkretny Plazmoid. Niby działa, ale miejmy nadzieje, że to nie jest końcowa wizja – bo nie czarujmy się, ani ładne, ani wygodne to nie jest.

Z lewej…

… Z prawej

Menu kontekstowe wybranego apletu

Motyw pulpitu za pomocą ustawień systemowych

Ustawienia motywu Plazmy dostępne są również w Ustawieniach systemowych. Tak jak się można było wcześniej spodziewać, z tego właśnie poziomu będą dostępne kompletne opcje dopasowania wyglądu całego biurka.

Wybór motywu Plazmy

Dziura ozonowa i Oxygen

Wydawałoby się, że styl Ozone wyprze Oxygena. Na chwilę obecną Ozone nie znalazł się w opcjach, za to stary Oxygen dorobił się kilku interesujących opcji.

Ustawienia Oxygena

Styl Oxygen z aktywną ramką

Udostępnianie apletów Plazmy

Nie jestem do końca przekonany i pewny, ale wszystko wygląda na to, że nowe KDE 4.4 będzie posiadało możliwość udostępniania apletów Plazmy poza maszynę na której zostały uruchomione, umożliwiając ich zdalną kontrolę.

Udostępnianie apletu Plazmy

Oczywiście nie obejdzie się bez określenia reguł, zarówno dla połączeń przychodzących jak i wychodzących. Plasmawall ?

Polityka zdalnych apletów

Wikipedio, powiedz przecie…

O tym, że KRunner to potężny element KDE 4 wie już chyba każdy. Za jego pomocą można zrobić bardzo wiele. A można jeszcze więcej – chociażby zapytać co sądzi o danej frazie Wikipedia.

KRunner – Wikipedia

Black Board

Black Board

Fancy Tasks

Fancy Tasks to ciekawy aplet, zachowujący się podobnie jak Cairo-Dock. Może wyświetlać zarówno ikony programów do uruchomienia, jak i aktualnie uruchomionych. Możliwe jest ustawienie zachowania ikon oraz ich animacji, czyniąc go czymś naprawdę unikatowym.

Standardowy wygląd

Ustawienia Fancy Tasks

Ustawienia wyglądu i zachowań

Konfiguracja ikon

Animacje na wskazanie ikony myszką

Animacje na kliknięcie ikony

Fancy Tasks po małych ustawieniach

PlasMate

PlasMate ma być kompletnym narzędziem do tworzenia apletów Plazmy, motywów, silników danych (dataengines) oraz wtyczek KRunnera.

PlasMate

Nowy Device Notifier?

Obok apletu Device Notifier znalazł się również Device Notifier Refactor. Pomimo tego, że jeszcze nic ciekawego nie oferuje, to warto zasygnalizować jego istnienie.

Device Notifier Refactor

Wiadomość źródłowa: KDE 4.4 r1024000 (Blog Korneliusza Jarzębskiego)

Wśród autorów fachowych artykułów roi się od zwolenników przejścia do "obróbki w chmurze" (cloud-computing) – przeniesienia wszystkich danych oraz ich obróbki do ogromnych, profesjonalnie zarządzanych centrów.

Ten artykuł jest tłumaczeniem tekstu: Not every cloud has silver lining autorstwa Cory Doktorowa. Tłumaczenie wykonał Włodzimierz Natorf.

Jest jednak rzecz, o której nikt głośno nie wspomina: głównym celem, jaki widzą w "chmurze" inwestorzy i przedsiębiorcy to wieczne i coraz to nowe opłaty pobierane od usług, które dziś można mieć za darmo albo za zryczałtowaną opłatą, bez rezygnacji z prywatności i wydawania pieniędzy, z których powstaną fortuny cloud companies.

Od chwili powstania komercyjnego, cywilnego Internetu inwestorzy marzyli o powrocie do gwarantującego wysokie zyski systemu zmonopolizowanej telekomunikacji, pochłoniętego przez skrajnie konkurencyjny rynek Sieci. Podobał im się bardzo model usług, gdzie od każdej, nawet najdrobniejszej "funkcji", jak choćby "prezentacja numeru", naliczany był rachunek – pamiętacie czasy¹, gdy trzeba było płacić za możliwość sprawdzenia, kto do nas dzwoni? Wyobraźcie sobie, że wasz dostawca internetu każe Wam płacić za możliwość zobaczenia nagłówka "From:" w mailach, zanim je odczytacie! W USA działalność takich dostawców jak Minitel, AOL czy MSN nasuwa skojarzenia z iPhone’m – kontrolowali oni całkowicie rynek usług w swoich sieciach, w szczególności wysokość pobieranych od usługodawców opłat za możliwość świadczenia usług użytkownikom.

Jednak odkąd powstała Sieć – publiczny Internet, gdzie każdy mógł stworzyć nową usługę, protokół czy aplikację, zawsze znajdował się ktoś chętny do odgryzienia kawałka dla siebie, oczywiście po cichu i nie bez zysku. Pierwsze serwisy pobierały opłaty za każdy wysłany i odebrany e-mail. Następna generacja wyparła je oferując ryczałtowe opłaty za pocztę. Krok po kroku, konkurencja zlikwidowała licznik tykający z każdym kliknięciem myszy w czasie sesji w Sieci. "Cloud services" mogą, przynajmniej częściowo, przywrócić poprzedni stan rzeczy. Zamiast kupować twardy dysk i płacić dodatkowo jedynie rachunki za prąd, możesz kupić miejsce na dysku i płacić za jego użytkowanie dostawcy. Podobnie, zamiast kupować szybki procesor, możesz prowadzić obliczenia zdalnie i płacić za każdy użyty cykl procesora.

Ma to sens dla pewnej ograniczonej liczby zastosowań. Jeśli jesteś usługodawcą, dostęp do takiej ilości przestrzeni dyskowej i hostingu otwiera wspaniałe perspektywy. Wiele firm takich jak Twitter stwierdziło, że kupowanie hurtem przestrzeni dyskowej, szybkich łącz i mocy obliczeniowej dostępnej na żądanie od firm hostingowych jest bardziej opłacalne niż inwestowanie we własną serwerownię i sprzęt. Z kolei jeśli prowadzisz obliczenia wymagające superkomputerów, dobrym rozwiązaniem może być podłączenie się do kilku klastrów administrowanych przez centra fizyki.

Jednak dla przeciętnego ciułacza cloud computing jest, delikatnie mówiąc, mało dochodowe. Dostęp poprzez sieć pozostaje wolniejszy, droższy i mniej pewny niż tradycyjny. Firmy z branży rozrywkowej, spyware, botnety, węsząca policja czy bezczelny szef, dając sobie prawo do łamania zabezpieczeń, śledzenia, czy wręcz przerywania połączeń sprawiają, że Twój dostęp do sieci staje się z dnia na dzień coraz bardziej uciążliwy.

Niestety, nie wygląda na to, żeby w najbliższym czasie sytuacja uległa zmianie. Wejście na rynek dysków czy komputerów nie jest tanie, nawet jeśli wykorzysta się "chmurę" chińskich wytwórni, jest jednak tańsze niż wejście na rynek dostawców Internetu – okablowanie każdego domu w całym państwie to poważne zadanie. Dlatego masz szczęście, jeśli na rynku dostawców konkurują ze sobą dwie czy trzy firmy, i dlatego możesz kupić trzydzieści rodzajów twardych dysków na Amazonie. Wątpię, czy dostęp poprzez sieć kiedykolwiek będzie tańszy, wydajniejszy i pewniejszy od użycia lokalnego dysku i procesora. Dziś można kupić terabajtowy dysk za 57 funtów i raczej ciężko go zapełnić, chyba, że zgrywa się regularnie programy telewizyjne.

Podobnie, za 348 funtów można kupić niemarkowy komputer z czterordzeniowym procesorem i wspomnianym terabajtowym dyskiem. Maszyna ta bez większego wysiłku przeliczy wszystkie arkusze, jakie kiedykolwiek stworzysz.

Łatwo sobie wyobrazić pewne skrajnie wyspecjalizowane środowiska współpracy, które zyskują na cloud computing – używaliśmy arkusza kalkulacyjnego Google tworząc listę gości na nasze wesele, oraz kalendarza Google przed spotkaniem z moimi rodzicami w Kanadzie – jeśli jednak projektuje się te aplikacje mając na względzie maksimum wygody użytkowników, a nie dochodu twórców, uzyska się przestrzeń dyskową, gdzie przechowywane będą zaszyfrowane dane, od czasu do czasu odczytywane przez szybkie komputery, dokonujące większości obliczeń lokalnie.

W ten sposób korzystam z przestrzeni dyskowej S3 Amazona: nie jako wolnego i niepewnego twardego dysku, ale jako miejsca na zaszyfrowane kopie ważnych plików, zapisywanych na S3 za pomocą narzędzia JungleDisk. To rozwiązanie tańsze i lepsze niż jakikolwiek własny, lokalny system kopii zapasowych. Ale nie zamierzam zarabiać na S3 w najbliższym czasie.

¹ u nas wciąż aktualne, przynajmniej u wiadomo kogo… ; )

Korekta i skład: Norbert Kiszka

Tekst jest objęty licencją Creative Commons Attribution NonCommercial ShareAlike

To już ostatnia część pracy magisterskiej Przemysława Kulczyckiego dotyczącej licencjonowania oprogramowania. Dziękujemy Przemkowi za umożliwienie publikacji pracy w wortalu jakilinux.org. Mamy też nadzieję, że dzięki tej serii artykułów dowiedzieliście się czegoś wartościowego w tej bliskiej nam tematyce.

Zakończenie

Jeśli ty masz jabłko i ja mam jabłko i wymienimy się tymi jabłkami, to wtedy ty i ja wciąż będziemy mieli po 1 jabłku. Ale jeśli ty masz pomysł i ja mam pomysł i wymienimy się tymi pomysłami, to wtedy oboje będziemy mieli 2 pomysły.

George Bernard Shaw

Powyższa praca nie wyczerpuje tematyki licencjonowania oprogramowania. Wiele zagadnień, które wymagałyby dokładnego omówienia zostało potraktowanych skrótowo lub nawet pominiętych. Celem niniejszej pracy było jednak rozpoznanie i porównanie dzisiejszych modeli licencjonowania oprogramowania oraz udzielenie odpowiedzi na pytanie: jakie są ich zalety i wady?

Reasumując wszystkie analizy przedstawione w niniejszej pracy, można stwierdzić, że oba wyróżnione przeze mnie modele licencjonowania mają wiele zalet i doskonale się sprawdzają w konkretnych, zależnych od kontekstu sytuacjach.

Zdaniem autora licencje wolnego oprogramowania lepiej sprawdzają się w projektach infrastrukturalnych, takich jak: systemy operacyjne, przeglądarki www, serwery, popularne aplikacje ogólnego przeznaczenia. Wolne licencje doskonale nadają się do tworzenia referencyjnych implementacji algorytmów (np. obsługi protokołów internetowych, kryptografii, kodeków obrazu i dźwięku, formatów dokumentów). Bez otwartych programów takich jak Bind, Apache, czy OpenSSH – używanych na większości serwerów – nie byłoby Internetu w tej formie co dzisiaj. Wolne oprogramowanie nadaje się także do projektów rządowych i edukacyjnych, które z zasady mają dotrzeć do jak największej ilości odbiorców przy jak najniższym koszcie.

Licencje zamkniętego oprogramowania (EULA) lepiej sprawdzają się w projektach niszowych lub wymagających wysokich nakładów, takich jak specjalistyczne oprogramowanie, np. do projektowania samolotów. Wynika to z faktu, że dla projektów niszowych trudno jest znaleźć szerokie grono użytkowników skłonnych do współpracy przy jego tworzeniu. Osobnym przypadkiem są gry komputerowe, które w większej części składają się z utworów graficznych i dźwiękowych (a nie z kodu źródłowego).

Warto także wspomnieć o wpływie, jaki wolne oprogramowanie wywarło na inne dziedziny. Licencje wolnej dokumentacji utorowały drogę organizacji Creative Commons, która zasady wolnego oprogramowania przeniosła na grunt kultury. Dzięki nim, twórcy utworów muzycznych, graficznych, audiowizualnych, literackich i innych, mogą w wielu przypadkach swobodnie korzystać z dorobku innych twórców, a konsumenci kultury mogą się nią swobodnie dzielić. W świecie nauki zaś, udostępnianie wyników swojej pracy bez ograniczeń jest na porządku dziennym. Dzięki swobodnej wymianie wiedzy osiągnęliśmy tak daleki rozwój cywilizacyjny. Wolne oprogramowanie można także uznać za naturalną odpowiedź na zbyt restrykcyjny system prawa autorskiego – kiedy ustawodawca dał twórcom zbyt duży zakres uprawnień, to część z nich świadomie z tych praw zrezygnowała na rzecz użytkowników.

Autor: Przemysław Kulczycki
Skad: Swamper

Od redakcji

Całość pracy możecie przeczytać na stronie Licencje oprogramowania, gdzie oprócz linków do kolejnych rozdziałów umieszczać będziemy inne teksty związane z tematyką licencjonowania.

Omówiliśmy już licencje własnościowe oraz różnice między wolnym a otwartym oprogramowaniem. Czas zgłębić ten drugi temat i przyjrzeć się bliżej licencjom uznanym jako otwarte, a także kuriozum o nazwie Shared Source firmy Microsoft.

Licencje bez klauzuli copyleft

Licencje bez klauzuli copyleft nazywane są zezwalającymi (ang. permissive) lub licencjami akademickimi. Ich treść jest znacznie krótsza od licencji copyleft, dzięki czemu są prostsze do zrozumienia.

Licencja BSD

Pierwszymi programami udostępnionymi na licencji non-copyleft były elementy wydanej w latach 70-tych dystrybucji 1BSD, ale pierwszym oprogramowaniem w całości rozpowszechnianym na warunkach tej licencji była wydana w czerwcu 1989 roku dystrybucja Networking Release 1¹³⁰. Jej licencja, to 4-klauzulowa licencja BSD¹³¹, zwana także starą licencją BSD. Licencja ta zezwala na użytkowanie i redystrybucję oprogramowania, z modyfikacjami lub bez, w formie kodu źródłowego lub binarnego, pod warunkiem zachowania informacji o prawach autorskich w kodzie źródłowym i dokumentacji programu, oraz pod warunkiem nie używania nazwy Uniwersytetu Kalifornijskiego w Berkeley i nazwisk jego współpracowników do reklamowania produktów pochodnych od danego programu, bez uzyskania pozwolenia. Konsekwencją tych liberalnych warunków licencji jest zezwolenie na włączanie oprogramowania nią objętego do produktów na innych licencjach, zarówno otwartych, jak i zamkniętych. Licencja ta, tak jak większość licencji wolnego oprogramowania, zawiera także informację o braku jakichkolwiek gwarancji oraz nie ponoszeniu przez autorów i dystrybutorów programu odpowiedzialności za szkody wynikłe z użytkowania programu.

Klauzula ogłoszeniowa, 3-klauzulowa licencja BSD

Specyficzną cechą 4-klauzulowej licencji BSD jest tzw. klauzula ogłoszeniowa (lub reklamowa), która wymaga, aby wszystkie materiały reklamujące produkty korzystające z kodu na tej licencji zawierały informację:

Ten produkt zawiera oprogramowanie stworzone przez Uniwersytet Kalifornijski w Berkeley oraz jego współpracowników¹³².

Klauzula ta powoduje niekompatybilność z wieloma licencjami (zwłaszcza GPL¹³³), oraz sprawia problem praktyczny, kiedy kolejni autorzy wpisują w niej swoje nazwisko lub nazwę firmy w miejsce Uniwersytetu Kalifornijskiego. W dużych projektach, przez używanie takich klauzul, liczba informacji o autorach wymaganych w materiałach reklamowych wzrasta. Przykładem może być system NetBSD, w którego dokumentacji (jak podaje Richard Stallman¹³⁴) w 1997 roku było 75 takich informacji reklamowych o poszczególnych autorach. W 1999 roku Uniwersytet Kalifornijski zrezygnował z używania tej klauzuli i zezwolił na usunięcie jej z wszelkiego kodu do którego ma on prawa autorskie¹³⁵. Powstała w ten sposób licencja jest nazywana 3-klauzulową licencją BSD¹³⁶, lub zmodyfikowaną (albo nową) licencją BSD. Licencja ta jest kompatybilna z GPL i innymi popularnymi licencjami. Od czasu tej decyzji wszystkie systemy BSD przeszły na 3-klauzulową licencję, z wyjątkiem NetBSD, które nadal używa 4 klauzulowej wersji¹³⁷. W konsekwencji, w dokumentacji bieżącej wersji NetBSD można znaleźć 239 informacji reklamowych o poszczególnych autorach¹³⁸.

2-klauzulowa BSD, MIT (X11) oraz ISC

Część programistów używa także 2-klauzulowej licencji BSD¹³⁹, powstałej przez usunięcie klauzuli zakazującej używania nazwisk autorów do reklamowania produktów pochodnych. Licencja ta jest funkcjonalnie identyczna z licencją MIT¹⁴⁰ (zwaną także licencją X11), oraz licencją ISC¹⁴¹ (używaną m.in. przez OpenBSD¹⁴²). Mnogość licencji z „BSD” w nazwie powoduje niejednoznaczność terminu „licencja BSD”, dlatego Stallman proponuje zamiast którejkolwiek z licencji BSD używać licencji X11¹⁴³ (nazwa „licencja MIT” też może być niejednoznaczna, ponieważ MIT używało wielu licencji¹⁴⁴). Z tego samego powodu można preferować licencję ISC, która dodatkowo jest napisana prostszym językiem, dzięki czemu sprawia mniej problemów w interpretacji prawnej. Licencja X11 zawiera nieprecyzyjne sformułowania „zajmować się oprogramowaniem¹⁴⁵” (w oryg. „to deal in the Software”)
oraz „oprogramowanie i związane [dołączone] pliki dokumentacji¹⁴⁶” (w oryg. „this software and associated documentation files”), które (wg Rosena¹⁴⁷) mogą sprawiać problemy w interpretacji prawnej.

Apache License

Osobnym ciekawym przypadkiem jest licencja Apache¹⁴⁸. Jest to licencja stworzona przez Apache Software Foundation, początkowo tylko dla ich serwera protokołu HTTP – Apache. Pierwsze wersje tej licencji były podobne do 4 klauzulowej licencji BSD, z dodaniem klauzuli zabraniającej produktom pochodnym używania nazwy Apache. Wersja 2.0, opublikowana w 2004 roku, znacząco się od nich różni. Apache License 2.0, podobnie jak w/w licencje akademickie, zezwala na używanie, modyfikowanie i redystrybucję programu w postaci źródłowej, lub binarnej, bez obowiązku udostępnienia kodu źródłowego. Oznacza to, że kod na tej licencji można włączyć do zamkniętych programów, pod warunkiem zachowania zgodności z warunkami tej licencji. Podobnie jak poprzednie wersje, Apache License 2.0 nie udziela zezwolenia na używanie nazw i znaków handlowych licencjodawcy, z wyjątkiem użycia ich w informacji o pochodzeniu produktu. Najważniejszą zmianą, w porównaniu do typowych licencji akademickich, jest klauzula o patentach. Apache License 2.0 określa, że licencjobiorca otrzymuje od wszystkich autorów i współautorów licencję na użycie ich patentów mających zastosowanie w licencjonowanym programie. Jednakże, jeśli licencjobiorca wytoczy komukolwiek proces o to, że ów program narusza jego patenty, to w/w licencja na użycie patentów autorów i współautorów zostanie mu cofnięta. Apache License 2.0 jest niekompatybilna z GPLv2, ale jest kompatybilna z GPLv3¹⁴⁹. Ze względu na obejmowanie patentów i znaków handlowych, licencja ta stanowi ciekawą alternatywę dla licencji typu BSD.

Domena publiczna

Przy omawianiu licencji akademickich warto także wspomnieć o domenie publicznej. Domena publiczna nie jest licencją. Jest to ogół twórczości, do której wygasły autorskie prawa majątkowe, i która jest przez to dostępna dla wszystkich, i do dowolnych zastosowań. Do domeny publicznej należą także dzieła, które od początku ich powstania nie były objęte tymi prawami (np. teksty ustaw, statystyki sportowe, formuły matematyczne). W/w licencji akademickich, ani licencji copyleft nie należy mylić z domeną publiczną. Zarówno licencje copyleft, jak i akademickie, opierają się na prawie autorskim – w każdej z nich jest wyraźne zastrzeżenie praw autorskich. Dopiero po zastrzeżeniu tych praw autor udziela zezwolenia na używanie, kopiowanie i modyfikowanie, pod ściśle określonymi warunkami.

Podwójne licencjonowanie

Właściciel praw autorskich może licencjonować swoje dzieła wielokrotnie i na odmiennych warunkach. Firmy sprzedające oprogramowanie własnościowe często stosują kilka typów licencji jednocześnie – np. licencje dla użytkowników indywidualnych, dla użytkowników grupowych, oraz dla instytucji akademickich. Licencje te różnią się zakresem uprawnień oraz ceną. W przypadku wolnego oprogramowania jednoczesne wydawanie produktów na kilku licencjach jest stosowane ze względu na kompatybilność z innymi licencjami wolnego oprogramowania. Np. interpreter języka Perl jest wydany na Artistic License oraz na GPL¹⁵⁰, a przeglądarka Mozilla Firefox jest wydana jednocześnie na MPL, LGPL i GPL¹⁵¹. Użytkownik podczas modyfikacji programu ma możliwość wyboru jednej (lub wszystkich) z wymienionych licencji, ale po wybraniu nie może danej licencji zmienić.

Niektóre firmy stosują jednocześnie oba w/w modele licencjonowania dla swoich produktów – wydają je na licencji typu copyleft, oraz komercyjnej. Najbardziej znanymi przykładami są baza danych MySQL¹⁵² oraz biblioteka interfejsu użytkownika Qt¹⁵³. Twórcy oprogramowania korzystającego z w/w produktów mogą wybrać wersję na GPL, ale wtedy ich oprogramowanie też musi być objęte tą licencją (zgodnie z warunkami modyfikacji i dystrybucji zawartymi w licencji), lub mogą kupić licencję komercyjną, i wtedy nie muszą ujawniać swojego kodu źródłowego. Użytkownicy wybierający wersję GPL nie mogą udzielać innym komercyjnych licencji.

Jednoczesne komercyjne i otwarte licencjonowanie programów pozwala lepiej finansować rozwój programu oraz otrzymywać wsparcie niezależnych twórców-ochotników. Aby móc udzielać licencji komercyjnych na programy rozwijane przez społeczność niezależnych twórców, firma rozwijająca dany program musi otrzymać od każdego z nich zgodę na relicencjonowanie ich kodu. Udostępnienie programu na wolnej licencji pozwala na szybsze zdobycie dużej liczby użytkowników i uzyskanie efektu sieciowego¹⁵⁴, co można porównać z modelem shareware¹⁵⁵.

Podwójne licencjonowanie można łączyć z innymi cechami produktu. Produkt na licencji komercyjnej może odróżniać się od otwartego dodatkową funkcjonalnością, posiadaniem gwarancji producenta, lub wsparciem technicznym. Np. komercyjna wersja bazy MySQL jest oferowana wraz z szerokim wachlarzem usług¹⁵⁶, zaś komercyjna wersja maszyny wirtualnej VirtualBox oferuje funkcje niedostępne w wersji otwartej¹⁵⁷.

Podwójne licencjonowanie może być także rozłożone w czasie. Firma Artifex Software przez wiele lat wydawała Ghostscript (interpreter języka PostScript) na licencji komercyjnej oraz Alladin Free Public License¹⁵⁸ (licencja zezwalająca na modyfikację kodu źródłowego tylko do celów niekomercyjnych), zaś wersję na GPL wydawała z rocznym opóźnieniem¹⁵⁹. Obecnie Artifex Software zrezygnowała z licencji AFPL i wydaje bieżącą wersję Ghostscript na GPL oraz komercyjnej licencji¹⁶⁰.

Niemniej jednak, podwójne licencjonowanie ma dość wąskie zastosowanie. Jak podaje Mikko V&#228;lim&#228;ki, model ten jest praktyczny tylko w określonych warunkach¹⁶¹. Po pierwsze, nie ma sensu go stosować do licencji bez klauzuli copyleft, gdyż programy nimi objęte można bez problemu włączać do zamkniętych, komercyjnych produktów. Po drugie, do wielokrotnego licencjonowania potrzebne jest posiadanie pełni praw autorskich do kodu źródłowego programu. W dużych projektach z dużą liczbą niezależnych autorów (np. jądro Linux) uzyskanie zgody wszystkich na zmianę licencji może się okazać niemożliwe, bo np. niektórzy autorzy już nie żyją, a z kolejnymi nie ma kontaktu. Po trzecie, model ten ma największy sens wtedy, gdy potencjalni klienci mają interes w uzyskaniu licencji komercyjnej. Chodzi głównie o programy na licencji z silną klauzulą copyleft, które są podstawą do tworzenia innych programów (np. biblioteki, bazy danych). Zastosowana w nich klauzula copyleft wymusza na twórcach programów zależnych udostępnienie kodu źródłowego ich dzieł na tej samej licencji, co używana biblioteka czy też baza danych. Dzięki możliwości zakupu licencji komercyjnej, w/w twórcy mogą za opłatą uwolnić się od wymagań klauzuli copyleft. W przypadku programów samodzielnych, nieingerujących w działanie innych programów, twórcy oprogramowania własnościowego mogą z nich korzystać bez ujawniania kodu swoich programów.

Shared Source

Shared Source¹⁶² („współdzielony kod”) jest inicjatywą Microsoftu stworzoną w celu udostępniania ich kodu źródłowego osobom i organizacjom. Inicjatywa ta powstała w maju 2001 roku jako odpowiedź na żądania dużych korporacji i organizacji rządowych, które, chcąc zapewnić sobie odpowiedni poziom bezpieczeństwa, potrzebowały wglądu do kodu źródłowego używanych programów. Shared Source można także uważać za pośrednią odpowiedź na ruch open source, zwłaszcza biorąc pod uwagę podobieństwo nazw. W ramach tej inicjatywy, organizacje (instytucje rządowe, instytucje akademickie, korporacje, producenci OEM) oraz niezależni twórcy mogą, po podpisaniu odpowiedniego kontraktu, uzyskać dostęp do kodu źródłowego wybranych programów Microsoftu. Do programu dopuszczane są tylko wybrane osoby i instytucje, po spełnieniu szeregu wymagań stawianych przez Microsoft¹⁶³.

W ramach Shared Source, Microsoft udostępnił także 5 licencji, którymi niezależni twórcy mogą objąć swoje oprogramowanie. 2 z nich, Microsoft Public License (Ms-PL) i Microsoft Reciprocal License (Ms-RL)¹⁶⁴, zostały zaakceptowane przez OSI jako licencje otwartego oprogramowania¹⁶⁵. Z czasem FSF także je zaakceptowała, jako licencje wolnego oprogramowania¹⁶⁶, z zastrzeżeniem, żeby nie obejmować nimi nowego oprogramowania, ponieważ Ms-RL jest niekompatybilna z GPL, a Ms-PL duplikuje funkcjonalność licencji Apache 2.0.

Microsoft Public License można zakwalifikować do licencji akademickich¹⁶⁷, gdyż zezwala ona modyfikację i dystrybucję kodu źródłowego, oraz na włączanie kodu do własnych programów, zarówno komercyjnych jak i niekomercyjnych. Ms-PL, podobnie jak licencja Apache 2.0, zawiera także klauzulę o udzieleniu licencji na patenty oraz jej wygaśnięciu w przypadku wytoczenia autorom pozwu o naruszenie patentów. Ms-PL także wyraźnie nie udziela licencji na użycie znaków handlowych producenta. Licencja ta jest kompatybilna z trzecią wersją licencji GPL¹⁶⁸.

Microsoft Reciprocal License, podobnie jak Ms-PL zezwala na modyfikację i dystrybucję kodu źródłowego. Jednakże, Ms-RL jest licencją typu copyleft¹⁶⁹, gdyż wymaga dystrybucji zmodyfikowanych wersji pod tą samą licencją. Podobnie jak licencje MPL i CDDL, zezwala ona na włączanie do programu kodu na innych licencjach, pod warunkiem umieszczenia go w osobnych plikach. Tak samo jak MPL i CDDL, licencja Ms-RL jest niekompatybilna z GPL.

Kolejne 2 licencje, Microsoft Limited Public License (Ms-LPL)¹⁷⁰ i Microsoft Limited Reciprocal License (Ms-LRL)¹⁷¹, są modyfikacjami w/w licencji, które ograniczają użycie programów nimi objętych tylko do systemu Microsoft Windows. Z tego powodu nie mogą one być uznane za licencje wolnego ani otwartego oprogramowania.

Ostatnią licencją Shared Source jest Microsoft Reference Source License (Ms-RSL)¹⁷². Licencja ta zezwala tylko na podgląd kodu źródłowego, bez prawa do modyfikacji, oraz bez prawa do dystrybucji poza własną firmą. Jest to najbardziej restrykcyjna licencja z całej inicjatywy Microsoftu. Mimo tych ograniczeń, dany kod źródłowy może być użyty do zrozumienia działania programu i uzyskania dzięki temu poprawy działania własnych produktów współdziałających z danym programem na licencji Ms-RSL. Licencja ta również nie jest licencją wolnego ani otwartego oprogramowania.

W ramach Shared Source, Microsoft udostępnił na w/w licencjach kod źródłowy niektórych drobnych programów¹⁷³. Microsoft wydał także kilka programów na indywidualnych licencjach, które nakładają szereg dodatkowych ograniczeń – np. zabraniają użycia danego programu do celów komercyjnych. Przykładami są Shared Source Common Language Infrastructure¹⁷⁴ (implementacja CLI, głównego komponentu platformy .NET) oraz system Windows CE 6.0¹⁷⁵.

Inicjatywa Shared Source spotkała się z szeroką krytyką ze strony środowiska wolnego oprogramowania. Richard Stallman określił program Shared Source jako:
inną nazwę dla umów o zachowaniu poufności (ang. NDA)¹⁷⁶.

Bruce Perens (współzałożyciel OSI) podsumował Shared Source słowami:

patrz, ale nie dotykaj – my wszystko kontrolujemy¹⁷⁷.

Michael Tiemann (prezes OSI) stwierdził, że:

Shared Source, używając podobnie brzmiących terminów i oferując podobne możliwości, służy odwróceniu uwagi i rozmyciu przekazu ruchu open source>¹⁷⁸.

Tiemann uważa także, że Shared Source jest chwytem marketingowym, który może okazać się koniem trojańskim. Doskonałą ilustracją tego stwierdzenia jest fakt, iż twórcy wolnego oprogramowania, którzy oglądają kod udostępniony na licencji Microsoft Reference Source License mogą później zostać oskarżeni o bezprawne skopiowanie kodu objętego licencją Ms-RSL – jeśli ich kod źródłowy będzie wystarczająco podobny¹⁷⁹. Miguel de Icaza, programista projektów GNOME i Mono, ostrzega twórców wolnego oprogramowania, żeby nawet nie przeglądali kodu źródłowego objętego tą licencją¹⁸⁰.

Nie da się ukryć, że Shared Source wykorzystuje wymienioną w rozdziale Wolne oprogramowanie dwuznaczność terminu open source, który potocznie może być rozumiany tylko jako możliwość zobaczenia kodu źródłowego, bez prawa do modyfikacji. Doskonale ilustruje to licencja Ms-RSL, która przez osobę nieobeznaną w temacie może zostać błędnie uznana za licencję otwartego oprogramowania. Chociaż Shared Source obejmuje 2 licencje wolnego oprogramowania (Microsoft Public License i Microsoft Reciprocal License), to całą inicjatywę należy zaliczyć do zamkniętego oprogramowania, bo większość jej licencji nie spełnia kryteriów definicji wg FSF i OSI (opisanych w rozdziale Wolne oprogramowanie).

Przypisy:

130. Chociaż już wcześniejsze wersje BSD były licencjonowane na takich warunkach, to wymagały licencji od AT&T, gdyż zawierały także kod Uniksa. Zob. rozdz. Unix i BSD – akademickie podejście
131. Treść licencji jest dostępna na stronie projektu FreeBSD: http://www.freebsd.org/copyright/license.html
132. Tłumaczenie własne.
133. http://www.gnu.org/philosophy/bsd.pl.html
134. Ibidem.
135. ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
136. http://www.opensource.org/licenses/bsd-license.php
137. http://www.netbsd.org/about/redistribution.html#default
138. http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/distrib/notes/common/legal.common?rev=1.47
139. http://www.gnu.org/licenses/info/BSD_2Clause.html
140. http://www.opensource.org/licenses/mit-license.php
141. Licencja stworzona przez Internet Systems Consortium.
142. http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/share/misc/license.template
143. http://www.gnu.org/philosophy/bsd.pl.html
144. http://www.fsf.org/licensing/licenses/#X11License
145. Tłumaczenie własne.
146. Ibidem.
147. L. Rosen, op. cit., s. 73-102.
148. http://www.apache.org/licenses/
149. http://www.fsf.org/licensing/licenses/#apache2
150. http://dev.perl.org/licenses/
151. http://www.mozilla.org/MPL/
152. http://www.mysql.com/products/which-edition.html
153. http://trolltech.com/company/model
154. Efekt sieciowy – pojęcie w teorii ekonomii opisujące sytuację, w której wartość danego dobra jest bezpośrednio związana z liczbą jego użytkowników. Przykładem takiego dobra jest telefon – jego wartość dla nowych użytkowników jest większa, jeśli mogą za jego pomocą komunikować się z większą liczbą osób.
155. Zob. rozdz. Shareware, freeware, adware
156. http://www.mysql.com/products/enterprise/features.html
157. http://www.virtualbox.org/wiki/Editions
158. http://www.artifex.com/downloads/doc/Public.htm
159. L. Rosen, op. cit., s. 264-267.
160. http://ghostscript.com/awki/News
161. M. V&#228;lim&#228;ki, „The Rise of Open Source Licensing. A Challenge to the Use of Intellectual Property in the Software Industry”, wyd. Turre Publishing, Helsinki 2005, rozdz. 7.3, „Case Study 2: Dual Licensing and Embedded Software”, s. 206-216. Książka dostępna w Internecie: http://pub.turre.com/openbook_valimaki.pdf
162. http://www.microsoft.com/resources/sharedsource/default.mspx
163. http://www.microsoft.com/resources/sharedsource/productsourceprogram.mspx
164. http://www.microsoft.com/opensource/licenses.mspx
165. http://opensource.org/node/207
166. http://www.fsf.org/licensing/licenses/
167. Zob. rozdz. Licencje bez klauzuli copyleft
168. http://www.fsf.org/licensing/licenses/#ms-pl
169. Zob. rozdz. Licencje z klauzulą copyleft
170. http://microsoft.com/resources/sharedsource/licensingbasics/limitedpubliclicense.mspx
171. http://microsoft.com/resources/sharedsource/licensingbasics/limitedreciprocallicense.mspx
172. http://microsoft.com/resources/sharedsource/referencesourcelicense.mspx
173. http://microsoft.com/resources/sharedsource/licensing/developer.mspx
174. http://msdn.microsoft.com/MSDN-FILES/027/002/097/ShSourceCLILicense.htm
175. http://msdn.microsoft.com/en-us/embedded/bb190212.aspx
176. Tłumaczenie własne. Źródło: http://news.zdnet.co.uk/itmanagement/0,1000000308,2109446,00.htm
177. Tłumaczenie własne. Źródło: http://www.perens.com/Articles/StandTogether.html
178. Tłumaczenie własne. Źródło: http://opensource.org/node/225
179. http://news.cnet.com/8301-13505_3-9790795-16.html
180. http://tirania.org/blog/archive/2007/Oct-03.html

Autor: Przemysław Kulczycki
Skład: Swamper

Autor: Todd R. Weiss. Tekst oryginalny: IDC: Open Source Revenues to Almost Triple by 2013. Tłumaczenie: Maciej Meller.

Według opracowanego przez instytucję International Data Corporation z Bostonu raportu pt. “Prognoza ws. światowego oprogramowania open source na lata 2009-2013″ podczas gdy nastąpiło pogłębienie recesji i pogorszenie globalnej gospodarki, dochody z oprogramowania o otwartym kodzie znacząco wzrosły. Wygląda na to, że tendencja ta utrzyma się. Jak duży może być to wzrost? Studium IDC wskazuje, że w roku 2008 dochody w sektorze otwartego oprogramowania wyniosły 2,9 miliarda dolarów i jak się oczekuje, wzrosną o 34% w roku 2009, do poziomu 3,9 miliarda USD. Do roku 2013, spodziewany globalny wzrost tych dochodów ma sięgnąć 8,1 miliarda dolarów.

“Rynek oprogramowania o otwartym kodzie źródłowym został solidnie wzmocniony przez obecny kryzys gospodarczy.” – mówi Michael Fauscette, analityk w dziale oprogramowania biznesowego IDC, który jest autorem raportu. “Oprogramowanie open source coraz częściej stanowi część strategii korporacyjnej wśród największych firm i można zauważyć wysokie tempo wdrożeń w głównym nurcie przedsiębiorstw.”

Jednak rzeczywistość weryfikuje te liczby – wspomniane wyniki wciąż wypadają blado w porównaniu do światowych dochodów ze sprzedaży oprogramowania własnościowego. Zgodnie z danymi IDC, w roku 2008 dochody ze sprzedaży zamkniętego oprogramowania przyćmiły wyniki open source – 137,3 miliarda dolarów w porównaniu do 2,9 miliarda USD. Prognozowane dochody na rok 2009 to odpowiednio 138,8 miliarda i 3,9 miliarda dolarów. Do roku 2013 utrzyma się znaczna dysproporcja na korzyść produktów własnościowych – 169,5 miliarda do 8,1 miliarda dolarów.

Jak twierdzi Fauscette, za dobrą wiadomość należy jednak uznać fakt, że gwałtowny wzrost dochodów w sektorze oprogramowania o otwartym źródle nastąpił w dobrym czasie i przynosi nadzieję na przyszłość. “To duży procent przy małych wartościach”, mówi. “To dopiero początek, jest mnóstwo miejsca na rozwój.”

Jednak dochody open source w najbliższej przyszłości nie dogonią reszty rynku oprogramowania. “Póki co nie widzę sporego zagrożenia dla końcowych wyników finansowych dużych producentów oprogramowania, ale z czasem ten wzrost będzie kontynuowany. Myślę że czasy ignorowania tego faktu należą do przeszłości. Dziś to już główny nurt. To koniec Dzikiego Zachodu, wdrożenie open source nie wiąże się z ryzykiem. Firmy zdają sobie z tego sprawę.” mówi Fauscette.

Oprócz globalnej recesji napędzającej dochody producentów otwartego oprogramowania, kolejnym kluczowym czynnikiem jest fakt, że oprogramowanie o otwartym źródle jest dziś postrzegane jako o wiele bardziej dopuszczalna i interesująca alternatywa niż kiedykolwiek indziej w ciągu swej krótkiej historii. Jako alternatywa, która w szczególności prowadzi do oszczędności w zubożałych korporacjach. Ta nowa fala akceptacji jest kluczem do niedawnego wzrostu w branży open source.

“Firmy (open source) zdobywają nowych klientów. To już nie tylko systemy operacyjne, nie tylko Linux. Open source wciąż pnie się w górę, na szczebel oprogramowania pośredniczącego i aplikacji.”

Fauscette przyznaje jednak, że wzrost nie jest powszechny. “Na polu komputerów stacjonarnych otwarte oprogramowanie nie zdołało poczynić postępów. Ubuntu rośnie w siłę, ale to wciąż nie jest olbrzym. W zeszłym roku zanotowaliśmy ogromny wzrost w dziedzinie oprogramowania pośredniczącego.”

Czy zwyżkowa tendencja w dochodach z open source to niespodzianka?

“Nie nazwałbym tego zaskoczeniem”, twierdzi Fauscette, “To normalna kolej rzeczy w fazie akceptacji produktu. Kilka lat temu, dwa lub trzy, na takie pytanie dyrektor naczelny lub ds. technicznych odpowiedziałby, że nie zezwolił na open source w ważnych systemach firmy. Dziś prawdopodobniej można usłyszeć, że firma pracuje nad strategią open source albo że już takowa istnieje. Słaba kondycja gospodarki wzmogła ten proces.”

Na stopień wdrażania i użycia otwartych aplikacji wpływ ma także wyłaniająca się technologia cloud computing oraz outsourcing procesów biznesowych (BPO). Oba działają jak dźwignia rozwoju otwartego oprogramowania. Usługa przetwarzania w chmurze pozwala użytkownikom korporacyjnym na zakup i korzystanie z mocy obliczeniowej i usług jedynie w takim wymiarze, na jaki aktualnie istnieje zapotrzebowanie, bez konieczności ogromnych wstępnych inwestycji. BPO to oszczędności dla użytkowników dzięki ekonomii skali i zastosowania otwartego oprogramowania w wielu procesach. “Ta nisza przyciągnie sporo dostawców open source”, uważa Fauscette.

Użytkownicy kupujący taki rozproszony outsourcing nie mają nic przeciwko otwartym aplikacjom. “Czy klienta, który za swoje pieniądze chce otrzymać miejsce na swoją aplikację i używać jej w chmurze, to w ogóle obchodzi? Czy ma znaczenie, że to otwarta aplikacja?”, pyta Fauscette, “Oczywiście, że nie. Klient dba jedynie o to czy produkt w uzgodnionej cenie spełnia oczekiwany poziom usługi.”

Godne uwagi jest także to, że mnóstwo otwartych aplikacji wydają dziś jedni z największych w branży IT, wliczając w to IBM, Novell, Oracle i innych. “Open source to dziś znaczny element we wszystkich tych firmach, które mogą sprzedawać usługi i wsparcie”, mówi Fauscette, “To stanie się normą. Produkty własnościowe wciąż będą obecne, a tam gdzie to możliwe udział open source będzie powiększany. To racjonalne uzupełnienie tych przedsiębiorstw.”

Simon Phipps dyrektor generalny ds. open source z Sun był jednym z trzech prelegentów na ostatniej australijskiej, linuksowej konferencji. Po prelekcji udzielił wywiadu wortalowi iTwire.com.

Poniższy tekst jest tłumaczeniem “Open source: how Sun sees it” dostępnego na wortalu www.itwire.com autora Sama Varghese.

iTWire: Czy myślisz, że Sun popełnił mały błąd opóźniając przejście Javy na Open Source?

Simon Phipps:

Osobiście wolałbym, aby to stało się wcześniej, ale były spore trudności i dlatego trwało to tak długo. Obecnie jestem bardzo zadowolony z rezultatów, które osiągnęliśmy. Java jest dostępna we wszystkich najważniejszych dystrybucjach Linuksa. Jest przygotowana w odpowiednich paczkach na te platformy, jak np. ma to miejsce w Ubuntu czy w Fedorze. Myślę, że pomimo roku opóźnienia obecnie osiągnęliśmy naprawdę dobre rezultaty.

iTWire: Czy twoim zdaniem to opóźnienie coś kosztowało Javę w porównaniu do platformy .NET?

Simon Phipps:

Nie, platforma .NET pomimo sporych wysiłków wielu ludzi nie jest w rzeczywistości rozwojowa w kontekście Linuksa .

iTWire: Pytam raczej o wielkość społeczności?

Simon Phipps:

Nie, Java i open source nie mają związku z obszarem, gdzie konkuruje ona z .NET.

iTWire: Innym produktem Open Source Suna rozwijającym się w ostatnich latach jest OpenSolaris. Jak to wygląda obecnie?

Simon Phipps:

OpenSolaris faktycznie ma się dość dobrze. OpenSolaris jest wynikiem przejścia od klasycznego centrum danych Solaris na Solaris Web 2.0. Większość z nas myślała, że proces przejściowy może zająć pięć lat. Powiedziałbym, że jest całkiem nieźle. Zawsze są rzeczy, z których można być bardziej dumnym i rzeczy których się żałuje jeśli chodzi o aktywność społeczności. Jednakże jesteśmy na dobrej drodze.

iTWire: Czy OpenSolaris jest głównie dla deweloperów, chcących mieć graficzne środowisko czy również dla zwykłych użytkowników?

Simon Phipps:

Powiedziałbym, że OpenSolaris jest skierowany do deweloperów, którzy chcą graficznego środowiska. Ci deweloperzy będą w przyszłości tworzyć następnej generacji klienckie i serwerowe oprogramowanie. To nie znaczy, że OpenSolaris będzie taki sam za trzy lata. Na dzień dzisiejszy mogę definitywnie stwierdzić, że jest on dla web deweloperów i następnej generacji uniksowych deweloperów.

iTWire: Czyli zasadniczo dla tech-doświadczonych ludzi (przyp.tłum. chodzi tu o angielskie tech-savvy czyli osoby sprawnie posługujące się technologią, z braku lepszego tłumaczenie wymyśliliśmy ten neologizm)?

Simon Phipps:

Dla tech-doświadczonych ludzi – o których mówiłem między innymi w swojej prelekcji. Dla przykładu mam nowego laptopa kupionego któregoś pięknego dnia i bardzo chciałbym mieć na nim OpenSolarisa, ale nie chcę, żeby był on tylko do zabawy. Chcę aby był to “komputer”. A nawet tech-doświadczeni ludzie chcą mieć “komputery” a nie zabawki.

iTWire: Ustalmy jakąś grupę odbiorców – zamierzamy mieć OpenSolarisa, który będzie używany przez kogoś, kto używa komputerów od wielu lat, ale którego właściwie nie można nazwać tech-doświadczonym?

Simon Phipps:

Nie możemy rozważać tego w tych kategoriach. Jeśli spojrzysz na wydanie OpenSolaris 2008-11, to jest on zadziwiająco przystępny. Możesz skorzystać z płyty LiveCD i uruchomić go natychmiast na swoim PC. Choć nie jesteś osobą tech-doświadczoną, będzie działał wspaniale. Z płyty LiveCD możesz zainstalować go bez najmniejszego zawracania sobie tym głowy.
Ważnym pytaniem jest, czy repozytoria będą wypełnione programami, których będziesz potrzebował. Więc nie chodzi dokładnie o to, czy ktoś jest “tech-doświadczony”, chodzi o aplikacje. Dla wersji 2008-11 repozytoria są dobrze wyposażone, ale wciąż muszą być rozwijane. Dzięki społeczności w następnym nadchodzącym wydaniu 2009-04 repozytoria będą lepiej wyposażone.

iTWire: Jaki wpływ będzie miała obecna redukcja zatrudnienia w Sun na strategię związaną z Open Source?

Simon Phipps:

Open Source w Sun jest uzupełnieniem strategii produktowej. Restrukturyzacja, która teraz się odbywa niewątpliwie wpłynie na kilka projektów związanych z open source. Jestem tego pewny. To, co się dzieje w tej chwili – nie jest klasyczną redukcją zatrudnienia. Jest to restrukturyzacja firmy w szerokim zakresie.Niektóre części z restrukturyzowanej firmy aktualnie mają wakaty i zatrudniają nowych ludzi. Część zwolnionych pracowników znajdzie w nich miejsca pracy.

iTWire: Czy z powodu sytuacji ekonomicznej zostało coś na tobie wymuszone?

Simon Phipps:

Było to koniecznym krokiem w dalszym rozwoju firmy. Zostało to również przyspieszone przez obecne warunki ekonomiczne. Obecnie w Sun wykonuje się pracę zapowiedzianą końcem zeszłego roku i która jest częścią procesu rozpoczętego wcześniej. Oczywiście dzieje się to w warunkach ekonomicznych, które teraz mamy, ale jest to część restrukturyzacji.

iTWire: Pojawiły się głosy od osób związanych ściśle z Linuksem, włączając w to deweloperów jądra, że rzeczą która powstrzymuje przyjęcie OpenSolarisa przez większą ilość osób – który posiada kilka bardzo dobrych cech – jest licencja. Czy Sun ma jakieś plany w związku ze zmianą licencji (CDDL)?

Simon Phipps:

Nie zgadzam się z tym. Wśród wszystkich rzeczy jakie są w OpenSolarisie najistotniejsze jest to, że społeczność OpenSolaris jest społecznością OpenSolarisa. Nie jest ona gorsza od społeczności Linuksa. Społeczność OpenSolaris nie jest definiowana przez inną społeczność. Jest to wspólnota. Aktualnie jest ona bardzo mocno przywiązana do licencji CDDL. Jeżeli w przyszłości byłyby jakiekolwiek zmiany w licencji, miałyby one na celu połączenie społeczności z inną społecznością, a nie tylko zadowolenie kilku odmieńców. Społeczność zgromadzona wokół OpenSolaris w ciągu ostatniego roku znacznie się powiększyła. Na świecie jest około 100 grup użytkowników. Rejestrujemy pokaźną liczbę pingów od komputerów, które używają OpenSolarisa, sprawdzając repozytoria w poszukiwaniu nowych uaktualnień. Powiedziałbym, że wszystko działa bardzo dobrze i to w żaden sposób nie jest utrudnione przez CDDL.
Co jest natomiast utrudnione przez CDDL – to związek tej społeczności ze społecznością używającą GPL. Kiedy nadejdzie odpowiedni czas dla społeczności zgromadzonej wokół OpenSolarisa aby nawiązać nowy rodzaj związku ze społecznością GPL, to prawdopodobnie będzie ona wynikiem zmian w licencji. Ale na to jeszcze nie czas.

iTWire: Sądzisz więc, że jest możliwość na pojawianie się nowych użytkowników, którzy cenią siłę OpenSolaris, bez migracji ich ze społeczności Linuksa?

Simon Phipps:

Całkowicie się z tym zgadzam. Jest niewielki przepływ osób pomiędzy OpenSolarisem i innymi systemami operacyjnymi. Społeczność OpenSolarisa ma bardzo wielu studentów i mnóstwo deweloperów klasy “enterprise”, którzy co prawda bardziej badają, niż rozwijają. Sądzę również, że to, co chcemy osiągnąć, to wzrost społeczności open source, a nie migracje użytkowników pomiędzy różnymi systemami open source.

iTWire: Jakie są plany Suna względem open source? Jakie inne projekty są w przygotowaniu?

Simon Phipps:

Projektów open source mamy całkiem dużo w naszym portfolio oraz jeden czy dwa projekty, które nie są open source, takich jak “Java Caps”. Z powodów licencyjnych jest mało prawdopodobnie, że przejdą one na open source. Skupimy się na rozwoju społeczności i umocnieniu strategi produktu. W bliskiej przyszłości nie przewiduję, aby pojawiły się nowe projekty open source od Suna.

iTWire: Początkowo były narzekania ze strony członków społeczności, którzy próbowali współpracować przy kodzie OpenSolaris – mówili że było za dużo biurokracji. Jakie kroki zostały podjęte aby to ułatwić?

Simon Phipps:

Problemy były z wydaniem 2008-05. Kiedy Solaris był rozwijany przez pracowników Sun, to kod był zarządzany przez własnościowy system kontroli wersji. Aby ułatwić współpracę musieliśmy przenieść cały kod na otwarty system kontroli wersji. Aktualnie jest on zarządzany przez system Mercurial. Przeniesienie pokaźnej ilości kodu do nowego systemu było dużym wyzwaniem. Więc teraz kiedy kod jest publicznie dostępny, deweloperzy, którzy chcą współpracować ściągają go i zgłaszają commity. Jest jeszcze trochę pracy do zrobienia, ale główny obszar kodu którym społeczność jest zainteresowana jest dostępny.

iTWire: Jak wygląda praca nad OpenSolarisem. Czy idzie zgodnie z planem?

Simon Phipps:

Jestem wystarczająco blisko projektu aby znaleźć mnóstwo rzeczy, które mnie nie zadowalają.

iTWire: Jakie są to rzeczy?

Simon Phipps:

Są to rzeczy, które naprawdę nie mają znaczenia, jeśli tylko nie patrzysz na nie z bardzo bliska. OpenSolaris idzie w kierunku, w jakim ja również chciałbym żeby wciąż szedł. Nadchodzące wydanie 2009-04 wygląda naprawdę nieźle – z dobrym repozytorium oraz z wczesnym (alpha) wsparciem procesorów SPARC. Mogę powiedzieć, że trzymamy się planu.

iTWire: Zadaję wszystkie te pytania, ponieważ kiedyś mieliście system nazywany JDS (Java Desktop System). Wokół niego było tak samo dużo entuzjazmu. Jednak nagle ten projekt zniknął …

Simon Phipps:

JDS stał się desktopem GNOME w OpenSolaris. Więc nie przepadł, ale to co się stało było wynikiem założenia, że jądrem systemu nie jest kernel Linuksa ale Solaris.

iTWire: Wiem, co się z tym stało ale…

Simon Phipps:

OpenSolaris jest projektem należącym do społeczności. Dla przykładu w zakresie działalności biznesowej w Sun musisz rozmawiać z osobami odpowiedzialnymi za biznes a nie ze mną.

iTWire: Kiedy rozmawiam z ludźmi, którzy zajmują się nowymi technologiami i posiadającymi już spore doświadczenie, mówili że nie jest ważne, co sprzedajesz teraz, lecz jeśli jest to własnościowe, to musisz to przystosować. Musisz przejść na open source przynajmniej do pewnego stopnia, albo zginiesz. Czy zgadzasz się z tym?

Simon Phipps:

Obecnie, możesz oddać swój kod ludziom, aby go przystosowali i wykorzystali na stacjach produkcyjnych. Korzyści z otrzymania różnorodnych źródeł usług i wsparcia od open source, spowodują znaczne trudności w skutecznej konkurencji rozwiązań własnościowych za około 4-5 lat. Ludzie zobaczą, że oprogramowanie własnościowe jest źródłem dużych kosztów. Mnóstwo firm przekona się, że open source jest drogą do uzyskania skalowalnych narzędzi. Oprogramowanie własnościowe i open source będą współistniały obok siebie jeszcze przez długi czas. Wybory firm również będą zmieniały się w nadchodzących latach. Z mojego punktu widzenia ważnym jest rozważenie przez firmy strategii open source w swoich produktach. Ale rynek jest bardzo zróżnicowany i będzie korzystał z wielu rozwiązań w nadchodzących latach.

Tłumaczenie: Marcin Witowski (mars3n)
Korekta: Iwo Hencz
Skład: Sławek Kabat

Zapraszamy do kolejnego odcinka sagi o licencjonowaniu oprogramowania. Dziś kontynuacja tekstu Wartość modeli ze względu na wybrane kryteria.

Jakość oprogramowania

Jakość oprogramowania nie jest łatwa do zmierzenia, bo zależy od wielu czynników. To co na pierwszy rzut oka wygląda na błąd używanego programu może w rzeczywistości być błędem innego programu z nim współdziałającego, systemu operacyjnego, albo nawet sprzętu. Pod pojęciem jakości oprogramowania należy rozumieć przede wszystkim liczbę błędów występujących w danym programie, a w szczególności liczbę luk bezpieczeństwa. W obszarze takiego właśnie znaczenia dokonano dalszej analizy porównawczej.

Otwartość a jakość

Wolne oprogramowanie ma zawsze jawny kod źródłowy. Ów kod jest dostępny dla każdego na takich samych warunkach, bez żadnych ograniczeń, zarówno do użytku prywatnego jak i komercyjnego. Skoro każdy ma dostęp do kodu źródłowego, to każdy może go przeanalizować i zgłosić błędy lub wysłać poprawki twórcom danego programu. Teoretycznie daje to też większe możliwości działania potencjalnym włamywaczom, bo mogą oni wykorzystać znalezione w kodzie dziury. W praktyce dostępność kodu źródłowego nie ma bezpośredniego wpływu na ilość znajdywanych błędów, bo takie poszukiwania najczęściej są przeprowadzane na skompilowanej wersji programu. Programy skompilowane do kodu maszynowego są funkcjonalnie identyczne z ich kodem źródłowym, a łatwiej jest znaleźć błąd sprawdzając jak program działa, niż czytając jego kod źródłowy.

Z otwartością kodu źródłowego wiąże się także błędne przekonanie, że skoro kod jest otwarty, to każdy może do niego wprowadzić złośliwą funkcjonalność (wirusy, konie trojańskie, tylne drzwi). Jest to niemożliwe, ponieważ każdy nowy kod jest sprawdzany przez innych programistów danego otwartego programu. Każdy może kod źródłowy przeczytać, każdy może go zmodyfikować na swoje potrzeby, ale nie każdy może dokonywać zmian w oficjalnej wersji programu. Dzięki otwartemu procesowi rozwoju, który zwykle towarzyszy otwartemu oprogramowaniu, jego autorzy częściej dostają zgłoszenia błędów od swoich użytkowników. Często dostają także poprawki błędów od niezależnych programistów (patrz Prawo Linusa²⁰¹). Tacy programiści z czasem mogą dołączyć do projektu i stać się jego współautorami. Obserwując te zachowania programistów i użytkowników²⁰² Eric Raymond napisał swój esej „Katedra i bazar²⁰³”. Stwierdził w nim, że bazarowy styl rozwoju Linuksa, w którym wszyscy mają głos i spośród ich propozycji wybierane są najlepsze, jest zadziwiająco efektywny. Pozornie chaotyczny, zdecentralizowany rozwój Linuksa, w którym nowe wersje są wypuszczane wcześnie i często, jest wg Raymonda lepszy od konwencjonalnego hierarchicznego modelu rozwoju komercyjnego oprogramowania.

Twórcy wolnego oprogramowania często porównują swoje działania do praktyk kryptologów. Sformułowana w XIX wieku przez holenderskiego kryptologa Augusta Kerckhoffsa zasada mówi, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy wszystkie szczegóły jego działania (oprócz klucza) są znane. Jej przeciwieństwem jest tzw. „security through obscurity” (bezpieczeństwo dzięki niejawności) – nieujawnianie zasad działania systemu w celu zapewnienia jego bezpieczeństwa. Idea ta jest promowana przez większość twórców zamkniętego oprogramowania, w tym Microsoft. W praktyce daje ona tylko złudne poczucie bezpieczeństwa, gdyż to, że dane luki w oprogramowaniu nie są publicznie znane nie oznacza, iż nie są one masowo wykorzystywane przez wybrane osoby, które o tych lukach wiedzą, ale nie dzielą się swoją wiedzą z innymi. W przypadku publicznego ujawnienia informacji o lukach bezpieczeństwa w danym programie, osoby go używające mogą przedsięwziąć odpowiednie środki zapobiegające wykorzystaniu danej luki, które w konsekwencji mogą pomóc w uchronieniu się przed zagrożeniem.

Statystyczna ilość błędów w kodzie

Jedną z najczęściej stosowanych miar oceny jakości oprogramowania jest ilość wykrytych błędów podzielona przez ilość linii kodu danego programu. Nie jest to miara doskonała, bo ten sam kod źródłowy może być rozciągnięty na wiele krótkich linii lub zmieszczony w jednej, za to bardzo długiej. Wg badań naukowców z Uniwersytetu Carnegie Mellon, typowe oprogramowanie komercyjne posiada 20-30 błędów na 1000 linii kodu²⁰⁴. Andrew Tanenbaum, powołując się na publikację Ostranda i Weyukera²⁰⁵, twierdzi, że oprogramowanie zawiera od 2 do 75 błędów na 1000 linii kodu²⁰⁶. Firma Coverity od 2006 roku prowadzi regularne badania jakości kodu programów będących wolnym oprogramowaniem na zlecenie Departamentu Bezpieczeństwa Krajowego Stanów Zjednoczonych²⁰⁷. Coverity oferuje za darmo projektom open source swoje usługi oparte na oprogramowaniu do automatycznej analizy kodu źródłowego. Obecnie w usłudze Scan zarejestrowanych jest ponad 180 projektów. Firma oferuje także swoje usługi komercyjnie wszystkim producentom zamkniętego oprogramowania²⁰⁸.

Przed założeniem firmy Coverity, jej założyciele przeprowadzili analizę kodu Linuksa w ramach pracy na Uniwersytecie Stanforda. Podczas 4-letniego badania trwającego od 2000 roku²⁰⁹, w 5,7 mln linii kodu źródłowego znaleziono 985 błędów, co daje 5,787 błędu na 1000 linii kodu. Obecnie strona scan.coverity.com podaje, że w Linuksie jest 0,127 błędu na 1000 linii kodu²¹⁰. Inne znane otwarte programy również plasują się poniżej w/w średniej ilości błędów. Dla serwera HTTP Apache średnia ilość błędów znalezionych przez usługę Scan wynosi 0,14 błędu na 1000 linii kodu. Dla przeglądarki WWW Mozilla Firefox wartość współczynnika ilości błędów do ilości linii kodu źródłowego wynosi 0,162. Zaś dla bazy danych PostgreSQL współczynnik ten wynosi 0,041. Oczywiście nie oznacza to, że w/w programy nie zawierają więcej błędów. Z biegiem czasu kolejne błędy są znajdowane, a wraz z rozszerzaniem funkcjonalności nieświadomie mogą być wprowadzane nowe błędy. Owe współczynniki powinny stanowić tylko punkt orientacyjny przy ewentualnych ocenach i porównaniach.

Chociaż firma Coverity prowadzi podobne badania na zamkniętym oprogramowaniu, to nie ujawnia ich wyników. Ben Chelf, współzałożyciel firmy Coverity, w wywiadzie dla tygodnika BusinessWeek podaje, że otwarte oprogramowanie przeciętnie jest wyższej jakości niż zamknięte oprogramowanie²¹¹. Jednocześnie Ben Chelf twierdzi, że spośród ponad 150 programów przeanalizowanych przez jego firmę, najwyższą jakość wykazało 15 programów, z których aż 11 to programy o zamkniętym kodzie źródłowym. Wg niego, najlepsze zamknięte programy można znaleźć w zastosowaniach krytycznych, takich jak lotnictwo, medycyna, telekomunikacja, czy też przemysł kosmiczny.

Warto zauważyć w tej argumentacji, że Chelf pomija bardzo istotny fakt, iż są to zastosowania szczególnego przeznaczenia, w których ilość sprzętu, na którym ma działać oprogramowanie jest ściśle ograniczona, tak samo jak funkcjonalność całego urządzenia. Porównywane przez niego otwarte programy mają zastosowanie ogólne, i dlatego muszą obsługiwać więcej sprzętu, a ich funkcjonalność jest ciągle rozwijana. Dlatego też w programach ogólnego przeznaczenia można znaleźć więcej błędów. Większość otwartego oprogramowania stanowią właśnie programy przeznaczone dla ogółu, gdyż dzięki swojej ogólności znajdują więcej użytkowników, a przez to także więcej osób chętnych je rozwijać. Szczególnie wyspecjalizowanym programom trudno jest znaleźć nowych użytkowników i współtwórców, dlatego w ich przypadku lepiej się sprawdza model zamkniętego oprogramowania.

Czas potrzebny do załatania błędów

Inną miarą jakości oprogramowania jest czas jaki upłynął od momentu odkrycia błędów do ich załatania. Również nie jest to miara doskonała bo zależy od poziomu zagrożenia jakie te błędy niosą. Praktyka pokazuje, że twórcy otwartego oprogramowania reagują znacznie szybciej na zgłoszone błędy niż twórcy zamkniętego oprogramowania. Microsoft publikuje swoje biuletyny bezpieczeństwa w drugi wtorek każdego miesiąca. Kiedy pojawią się jakieś krytyczne dziury w oprogramowaniu, na wydanie poprawek trzeba w najgorszym wypadku czekać co najmniej 30 dni. Twórcy wolnego oprogramowania publikują łaty na krytyczne błędy jak tylko zostaną ukończone, bez czekania do jakiejś z góry wyznaczonej daty. Raport 4 badaczy uniwersytetu Carnegie Mellon podaje, że twórcy otwartego oprogramowania są o 71% szybsi w łataniu znanych błędów niż twórcy zamkniętego oprogramowania²¹².

Ostateczna ocena jakości oprogramowania zależy od interpretacji wszystkich dostępnych wskaźników. Na w/w przykładach widać, że wolne oprogramowanie może wykazywać porównywalną, jak i wyższą jakość od zamkniętego oprogramowania. Jednakże, nie ma tutaj reguły – każdy przypadek należy porównywać osobno.

Organizacja produkcji i rozwoju oprogramowania

Specyficznym elementem odróżniającym zamknięty i otwarty model licencjonowania oprogramowania są towarzyszące im modele rozwoju oprogramowania. Tradycyjnie pojmowane oprogramowanie komercyjne jest tworzone przez firmę w zamkniętym procesie. Cały rozwój typowego zamkniętego oprogramowania odbywa się za zamkniętymi drzwiami: projektowanie, pisanie kodu, testowanie. Program jest udostępniany klientom dopiero po ukończeniu jego procesu produkcji. Ów model produkcji bywa także stosowany dla otwartego oprogramowania, jednak większość projektów będących wolnym oprogramowaniem jest oparta na otwartym modelu rozwoju. Model ten, zapoczątkowany przez Linusa Torvaldsa przy tworzeniu Linuksa, został opisany przez Erica Raymonda w eseju „Katedra i bazar²¹³”.

Raymond, obserwując rozwój Linuksa stwierdził, że przypomina on wielki, hałaśliwy bazar, pełen różnych poglądów i planów. Było to zupełnym przeciwieństwem klasycznego stylu tworzenia oprogramowania, który porównał do budowania katedry. Przed poznaniem Linuksa Eric Raymond uważał, że po przekroczeniu pewnego poziomu złożoności programu należy zastosować bardziej scentralizowane podejście do tworzenia oprogramowania. Wg jego ówczesnych poglądów, najważniejsze programy powinny powstawać jak katedry, budowane przez dostojnych architektów pracujących w pełnym odosobnieniu, bez udostępniania wersji testowych przed czasem. Linus Torvalds zaś wypuszczał nowe wersje Linuksa wcześnie i często, i był bardzo otwarty na wszelkie sugestie. Raymondowi wtedy wydawało się, że z tak chaotycznego procesu rozwoju nie może wyjść nic spójnego i stabilnego. Później z zaskoczeniem odkrył, że ten styl działa, i to działa bardzo dobrze. Dzięki częstemu wydawaniu nowych wersji Linux był szybciej testowany, a wykryte w nim błędy szybciej naprawiane. Zaś dzięki otwartej postawie Torvaldsa rozwój Linuksa nabrał niesamowitego tempa. Z całego świata napływały do niego kolejne fragmenty kodu dodające nową funkcjonalność lub naprawiające znalezione błędy. Niebagatelny wpływ na to miała rosnąca popularność sieci Internet, dzięki której taka luźna współpraca wielu osób z różnych krajów była możliwa.

Na otwarty model rozwoju oprogramowania składają się trzy podstawowe, publicznie dostępne komponenty: system śledzenia błędów²¹⁴, system kontroli wersji²¹⁵, oraz dowolne narzędzie komunikacyjne (lista dyskusyjna, forum, wiki²¹⁶, kanał IRC²¹⁷, itd.). Dostęp do każdego z nich jest otwarty: każdy może zgłaszać błędy, każdy może sprawdzić status prac nad zgłoszonymi błędami, każdy może śledzić rozwój programu w systemie kontroli wersji, każdy może zgłaszać swoje sugestie autorom programu. Jest to całkowite przeciwieństwo w stosunku do zamkniętego oprogramowania, gdzie przeciętny użytkownik nie ma żadnej możliwości aby wpłynąć na jego rozwój. Producenci zamkniętego oprogramowania nie oferują użytkownikom żadnej możliwości obserwowania rozwoju kodu źródłowego ich programów, ani żadnej możliwości sprawdzenia stanu zgłoszonych błędów. Zaś możliwości zgłaszania błędów i sugestii są ograniczone. Np. Microsoft umożliwia swoim użytkownikom zgłaszanie błędów tylko przez telefon²¹⁸, Corel nie oferuje żadnej możliwości zgłaszania błędów²¹⁹, Adobe zaś udostępnia formularz do zgłaszania błędów i sugestii²²⁰, jednakże po wysłaniu zgłoszenia nie można nigdzie śledzić jego statusu, ani sprawdzić cudzych zgłoszeń. Przyczyną takiego stanu rzeczy jest założenie, iż wszystkie błędy zostaną wykryte na etapie produkcji. Praktyka pokazuje, że nie ma oprogramowania bez błędów, i że zawsze będą znajdywane nowe błędy. Otwarty model tworzenia oprogramowania zaś zakłada, że programy są w ciągłym rozwoju, i dlatego tak dużą rolę odgrywają w nim publiczne systemy śledzenia błędów i kontroli wersji.

Bardzo częstym problemem w rozproszonych projektach będących wolnym oprogramowaniem jest zarządzanie prawami autorskimi do kodu źródłowego. Przy dużej liczbie niezależnych twórców brak prowadzenia ścisłej kontroli nad własnością kodu źródłowego może przynieść spore problemy. Bez dokładnego sprawdzania autorstwa kodu dany projekt może się narazić na proces, podobny do tego jaki spotkał system BSD²²¹. Brak informacji o autorstwie danych fragmentów kodu może być też problematyczny przy próbie zmiany licencji całego programu. Kod nieznanego pochodzenia w takim przypadku musiałby zostać napisany od nowa, gdyż nieznanego (lub nieżyjącego już) autora nie da się spytać o zgodę na zmianę licencji. Wiele projektów będących wolnym oprogramowaniem radzi sobie z tym problemem stosując tzw. CLA – ang. Contributor License Agreement – umowę licencyjną współtwórcy. Każdy programista biorący udział w takim projekcie musi podpisać taką umowę, poprzez którą przekazuje swoje prawa autorskie na rzecz fundacji bądź firmy zarządzającej projektem. Dzięki takim umowom dany rozproszony projekt uzyskuje 1 przedstawiciela, który może w razie potrzeby podjąć decyzję o uaktualnieniu lub zmianie licencji, i który będzie odpowiadał za ewentualne naruszenia cudzych praw autorskich lub patentów, zaś programiści udostępniający projektowi swój kod zyskują ochronę przed ewentualnymi roszczeniami prawnymi. Przykładami projektów używających takich licencji są: Apache²²², MySQL²²³, OpenOffice.org²²⁴, Fedora i Projekt GNU. Kontrprzykładem jest Linux, którego autorzy nie stosują takich umów.

Jednym z najpowszechniejszych mitów dotyczących rozwoju wolnego oprogramowania jest stwierdzenie, że jest ono rozwijane niekomercyjnie, głównie przez anonimowych, niezależnych twórców. Na przykładzie Linuksa można łatwo sprawdzić kto odpowiada za rozwój wolnego oprogramowania. Raport opublikowany przez Linux Foundation podaje, że ponad 70% pracy w rozwijaniu Linuksa wykonują pracownicy różnych firm²²⁵. W ciągu ostatnich 3 lat 13,9% zmian w kodzie Linuksa zostało dokonanych przez niezależnych programistów. 12,9% zmian wykonali programiści, co do których nie można było ustalić czy ich praca była opłacana przez jakąś firmę. 11,2% zmian dokonali pracownicy firmy Red Hat; 8,9% – pracownicy firmy Novell; 8,3% – IBM; 4,1% – Intel; 2,6% – Linux Foundation; 2,5% – Consultant; 2,0% – SGI; 1,6% – MIPS Technologies; 1,3% - Oracle; 1,2% – MontaVista; 1,1% – Google; 1% – Linuxtronix; 0,9% – HP. Pozostałe niecałe 27% zmian dokonanych zostało przez inne firmy, których poszczególny udział w zmianach nie przekroczył 1%. Nawet przy założeniu, że wszyscy programiści, których pracodawcy nie udało się ustalić pracowali za darmo, z czysto altruistycznych pobudek, wyraźnie widać, że bezwzględna większość rozwoju Linuksa jest dziełem różnych firm, wśród których można znaleźć wielu znaczących przedstawicieli rynku IT.

Przypisy:

201. „Przy wystarczającej liczbie oczu wszystkie błędy są proste” – zob. rozdz. Projekt GNU i ruch wolnego oprogramowania
202. Zachowania organizacyjne twórców wolnego oprogramowania szerzej opisuje rozdz. Organizacja produkcji i rozwoju oprogramowania
203. E. S. Raymond, op. cit.
204. Cyt. za Coverity’s kernel code quality study, LWN.net, 2004, http://lwn.net/Articles/115530/
205. T. J. Ostrand, E. J. Weyuker, The distribution of faults in a large industrial software system, Proc. Int&rsquo;l Symp. on Software Testing and Analysis, ACM, 2002, s. 55-64.
206. A. S. Tanenbaum, J. N. Herder, H. Bos, Can We Make Operating Systems Reliable and Secure?, IEEE Computer, vol. 39, s. 44-51, V 2006, http://www.cs.vu.nl/~ast/publications/computer-2006a.pdf
207. http://scan.coverity.com/
208. http://www.coverity.com/
209. Coverity’s kernel code quality study, LWN.net, 2004, http://lwn.net/Articles/115530/
210. http://scan.coverity.com/rung1.html
211. http://www.businessweek.com/technology/content/oct2006/tc20061006_394140.htm
212. A. Arora, R. Krishnan, R. Telang, Y. Yang, An Empirical Analysis of Software Vendors&rsquo; Patching Behavior: Impact of Vulnerability Disclosure, 2006, http://www.heinz.cmu.edu/~rtelang/disclosure_jan_06.pdf
213. E. S. Raymond, op. cit.
214. System śledzenia błędów – oprogramowanie służące do zgłaszania błędów i śledzenia ich stanu. Przykład: system śledzenia błędów w Ubuntu (dystrybucji Linuksa) – https://bugs.launchpad.net/ubuntu/
215. System kontroli wersji – oprogramowanie służące do śledzenia i łączenia zmian w kodzie źródłowym dokonywanych przez wiele osób w różnych momentach. Przykład: system kontroli wersji jądra Linux – http://git.kernel.org/
216. Wiki – oprogramowanie umożliwiające wspólną pracę wielu użytkowników przy tworzeniu treści stron internetowych, zob. hasło w Wikipedii
217. IRC – usługa umożliwiająca jednoczesną rozmowę wielu osób w czasie rzeczywistym, zob. hasło w Wikipedii
218. http://support.microsoft.com/gp/contactbug/
219. http://www.corel.com/servlet/Satellite/us/en/Content/1152796555474
220. http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform
221. Zob. rozdz. Unix i BSD – akademickie podejście
222. http://www.apache.org/licenses/icla.txt
223. http://forge.mysql.com/contribute/cla.php
224. http://www.openoffice.org/licenses/sca.pdf
225. https://www.linux-foundation.org/publications/linuxkerneldevelopment.php

Autor: Przemysław Kulczycki
Skład: Swamper