CLA, czyli zło konieczne
Poniższy tekst jest w pewnym sensie odpowiedzią na ataki Canonical, Mir i Ubuntu. Nie występuję tu jednak jako fan Ubuntu, a tym bardziej jako fan Canonical. Mam wiele do zarzucenia tej firmie. Co do systemu to inna sprawa, jest to (nadal) twór Open Source, jako więc fan "otwartości", powinienem zalety tego systemu promować, jeśli rozwijają Open Source, nawet pomimo tego że jestem fanem KDE.
Dla mnie to logiczne. Powinienem mieć świadomość, że inny użytkownik ma prawo wyboru tego, co według niego jest lepszym rozwiązaniem i powinienem uszanować tę decyzję. Jeśli więc jakieś oprogramowanie, pod pewnymi względami jest lepsze od KDE, ukrywanie przeze mnie tych wad jest na szkodę potencjalnego użytkownika. Oczywiście w takim przypadku wybór może oznaczać, albo KDE natychmiast dostarczy mi rozwiązanie, którego potrzebuję, albo wracam do Windowsa. Logiczne jest, że lepiej jest w takim przypadku zatrzymać tę osobę w środowisku, nawet kosztem miksowania bibliotek.
Pojawia się jednak od niedawna w środowisku Open Source pojecie syndromu NIH. Oznacza on niechęć do używania jakiejś rzeczy, ze względu na źródło pochodzenia, nawet pomijając oczywiste zalety tego rozwiązania. Oczywiście zwolennicy takiej teorii mają swoje racje, tylko często są ona mało związane z kodem programu i tym czym ten program jest w istocie. W przypadku dyskusji Mir vs Reszta Świata pada, na poparcie tej tezy, argument CLA.
Oczywiście CLA ma mały związek z praktycznym wykorzystaniem projektu. Po publikacji źródeł każdy może dokonać jego modyfikacji, dystrybucji itp. rzeczy, które gwarantuje nam licencja, w takim samym stopniu jak deweloperzy, którzy podpisali tę umowę. Umowa ta jednak gwarantuje udział Canonical, jako firmy, a nie osoby fizycznej, w rozwoju danego programu/biblioteki. Taki udział w przypadku firmy, musi być potwierdzony na piśmie i w zasadzie to wszystko.
Oczywiście wokół Canonical CLA narosło wiele legend, które jak wcześniej wspomniałem są argumentem za "not invented here", a wiele osób zarzuca Canonical nawet przywłaszczanie sobie praw autorskich do projektów. Niedawno pojawił się jednak artykuł Auréliena Gâteau, który rzuca inne światło na Canonical CLA. I jest to dość ważny głos, zważywszy na fakt, że Aurélien pracownikiem Canonical nie jest i pozostaje na garnuszku Bluesystems.
Aurélien podpisał umowę dwukrotnie, wcześniej jak był jeszcze pracownikiem Canonical, potem już jako wolny kontrybutor dla Ubuntu. CLA Canonical jest według niego podobna do CLA jakiego wymaga Digia za wkład do Projekt Qt. Z większych różnic wymienia tylko brak klauzuli wcześniejszego wypowiedzenia, ale jest to też częściowo na szkodę Canonical.
To co jednak wiele osób zarzuca Canonical to fakt, że po podpisaniu umowy sprzedajemy Canonical prawa autorskie do utworu. To bzdura. Punkt 2.1.(a) tej Licencji mówi:
You retain ownership of the Copyright in Your Contribution and have the same rights to use or license the Contribution which You would have had without entering into the Agreement.
Co oznacza miej więcej tyle, że zachowujemy prawo własności do swojego wkładu, takie same jak ci, którzy nie zawarli tej umowy. Koniec i kropka. Zrzeczenie się takich praw jest dobrowolne i zresztą praktyczne, jeśli weźmiemy pod uwagę wkład prawny Canonical w ochronę naszego projektu na rynku komercyjnym, gdzie raczej nie mamy dużych szans w starciu z innymi korporacjami, jako osoba fizyczna. Takie sugestie można usłyszeć także z obozu FSF, które także sugeruje zrzeczenie się praw autorskich na rzecz fundacji w celu ich ochrony. Nadal jednak zaznaczę - Nie ma takiego obowiązku!
Drugim zarzutem jest teoria, że Canonical gwarantuje sobie prawo do ewentualnej zmiany licencji naszego projektu. To także nieścisłe twierdzenie. Dotyczy ono dwóch zapisów 2.1.(b) i wyjaśniającego go 2.3, które brzmią:
2.1(b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with.
2.3. Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date.
Wracając jednak do zmiany licencji projektu to nie jest to wcale taki ewenement Canonical. Jak zauważa Auréliena Gâteau podobny zapis posiada także CLA Digii dla projektu Qt. Zapis ten został zresztą odziedziczony wraz z zakupem frameworka od Nokii, a zapewnia on KDE Free Qt Foundation przejęcie praw autorskich do Qt, po jego ewentualnym komercyjnym bankructwie, ale tylko na licecji BSD. Oznacza to oczywiście zmianę licencji wszystkich bibliotek Qt napisanych na licencji LGPL. Nie muszę przypominać, że stąd już niedaleka droga do komercyjnego wykorzystania naszego otwartego wkładu dla Qt Projekt.
To czy ewentualnie Canonical mogłoby skorzystać z nadanych jej przywilejów zależy więc tylko i wyłącznie od wkładu społeczności w ich projekty, który mógłby być zabezpieczeniem przed ewentualną zmianą licencji. To samo dotyczy Digii, która także miałaby szerszy zakres praw, gdyby nie wkład społeczności.
Dorzucą tu jeszcze jedną uwagę dotyczącą ewentualnego zamknięcia kodu, w urządzeniach o których mowa w Licencji GPLv3. Wiele osób zauważa, że Canonical miałby prawo do takiego samego nieujawniania kodu w przypadku tabletów, lub smartfonów. To oczywiście bzdura i nadinterpretacja tego przepisu. Wyraźnie on zaznacza, że urządzenia takie nie mogą mieć dostępu do modyfikacji ich kodu. Oznacza to, że tablety i smartfony się nie zaliczają do tej grupy, ponieważ zazwyczaj posiadają możliwości aktualizacji modyfikujących oprogramowanie, lub nawet instalację dodatkowych programów. Urządzenia, o których mowa to wyjątki posiadające możliwość wymiany kodu tylko wraz z chipem pamięci, czyli np. oprogramowanie w samolotach, którego modyfikacja jest zablokowana ze względów bezpieczeństwa. Canonical nad żadnym z takich urządzeń nie pracuje.
Chciałbym, aby dyskusja na temat różnic w oprogramowaniu Open Source odbywała się na poziomie wad technicznych i to najlepiej na właściwej Bugzilly, a nie forum publicznym. Niestety Canonical ma sobie wiele do zarzucenia w tej materii. Zapewne wielu użytkowników Ubuntu także. Druga strona jednak także nie pozostaje bez winy i z wielkim żalem czytam teksty Martina Gräßlina, czy Aarona Seigo, które pokazują że Canonical ma jednak rację skoro i oni postępują tak samo. Według mnie takie postępowanie tylko przyczynia się do szerzenia syndromu NIH, a nie z nim walczy. Smutne jest jednak to, że najbardziej na tym stracą użytkownicy, którym odbierana jest jest możliwość wyboru. Nie chciałbym, aby KDE poszła ta samą drogą co GNOME, którego dzieci zdają się być lepszą alternatywą niż oryginał.
Gdzieś powoli zatraca się wizja merytokratycznego rozwoju Open Source, czyli opartego na rządach ekspertów. Nie mam tu na myśli ekspertów z mianowania, mam tu na myśli każdego kto potrafi uzasadnić techniczną przewagę swojego projektu nad innymi. Coraz więcej jest za to sugerowania użytkownikom, że powinni wybrać daną opcję, bo jej lider używa świetnych perfum, albo innych tego typu cudactw. Osobiście nie miałby nic przeciwko Mirowi jeśli ten okazałby się lepszym rozwiązaniem od Waylanda, dopóki zachowana jest zasada otwartości tego projektu i życzę wszystkim użytkownikom właśnie takiego podejścia, a nie wikłania się w polityczne spory. To w końcu najlepsza droga o decydowaniu kierunku rozwoju Open Source.