Istotą klauzuli „copyleft” jest prawne zobowiązanie, aby programy pozostające w określonym związku z programem objętym tą klauzulą (np. modyfikacje, patches, upgrades) były przez ich twórców udostępniane na tych samych warunkach, o ile tylko dochodzi do ich rozpowszechniania. I tak, gdy licencja GPL przyznaje cztery wolności użytkownikom oryginału programu to zawarty w niej mechanizm „copyleft” powinien gwarantować zachowanie tych wolności w stosunku do opracowań tego oryginału. Stallman mówi nawet o „niezbywalności praw” zabezpieczonych „copyleft”. Z bardziej pragmatycznego punktu widzenia, „copyleft” powinien zapewniać stały dopływ nowego kodu do wolnego projektu od wszystkich jego aktywnych użytkowników, niezależnie od ich pozaprawnej motywacji do uczestniczenia w społeczności tego projektu.

Tyle teorii. W praktyce okazuje się jednak, że istnieją projekty nieobjęte klauzulą „copyleft”, które nie narzekają na brak uczestników wnoszących w nie swój twórczy wkład. Z drugiej strony okazuje się, że prawny obowiązek klauzuli „copyleft” nie wystarcza, aby kod udostępniany w wykonaniu tego obowiązku mógł być istotnie wykorzystany w projekcie. To pierwsze nie ulega wątpliwości biorąc pod uwagę chociażby istnienie projektów *BSD. To drugie stwierdzenie wynika natomiast na przykład z niedawnej wypowiedzi Haralda Welte. Otóż doprowadził on podobno do usunięcia naruszeń licencji GPL w ponad 100 przypadkach. W wyniku tego poszczególni naruszyciele udostępniali lub nawet publikowali swój kod źródłowy objęty klauzulą „copyleft”.

Jednak zdaniem Welte, w żadnym przypadku nie było możliwe ponowne wykorzystanie uwolnionego kodu. Po pierwsze, kod ten okazywał się bardzo niskiej jakości, nie trzymał podstawowych standardów stylu, API, przenośności itd. Po drugie, był on często dopisany do przestarzałych wersji wolnych projektów, wobec czego zupełnie nie przystawał do nowoczesnych rozwiązań stosowanych w chwili jego uwolnienia. Po trzecie wreszcie, elementy kodu istotnie wartościowe i przydatne, i tak pozostawały utajnione dzięki wykorzystaniu praktyk obchodzenia GPL takich jak binarne moduły jądra.

Taki stan rzeczy zmusza do zastanowienia nad praktycznym znaczeniem klauzuli „copyleft” dla ochrony czterech wolności użytkowników. Innymi słowy, co komu po najszerszej nawet swobodzie wykorzystania całkowicie nieprzydatnego kodu? Co z tego, że „copyleft” chroni wolność korzystania, przystosowywania, rozpowszechniania i ulepszania takiego „śmieciowego” kodu? Niestety, w najlepszym przypadku jest to wolność jedynie formalna. Wydaje się wobec tego, że prawna norma „copyleft” nie jest ani koniecznym, ani wystarczającym warunkiem rozwoju wolnego oprogramowania. Innymi słowy, może ono rozwijać się bez gwarancji prawnych nienaruszalności wolności użytkowników, a wszelkie takie gwarancje pełnią jedynie rolę subsydiarną w stosunku do pozaprawnych mechanizmów istotnie zapewniających faktyczne istnienie wolności. Co ciekawe, wnioski takie można wyciągnąć nie tylko na podstawie wypowiedzi Welte, ale również i z innych źródeł, jak na przykład K.R. Lakhani, B.Wolf, J. Bates i C. DiBona, The Boston Consulting Group Hacker Survey lub Greg R. Vetter, „Infectious” Open Source Software: Spreading Incentives or Promoting Resistance?, 36 Rutgers Law Journal 53 (2004).

Proponuję wyróżnić dwa przejawy działania „copyleft”, które roboczo nazwałbym: (1) defensywnym i (2) ofensywnym. Pierwszy przejaw to wykorzystanie mechanizmu prawa do obrony wolnego oprogramowania przed zawłaszczeniem. Obrona ta, jak wynika z wypowiedzi Welte jest skuteczna i sprawdziła się w ponad 100 przypadkach. Istotnie, jest to pewna różnica w stosunku do licencji „non-copyleft” (np. BSD), które na zawłaszczenie wyraźnie zezwalają. Tu też zaliczyłbym pozytywne oddziaływanie na konkurencję, o którym pisałem już w „Copyleft – wirus czy szczepionka?” Drugi przejaw działania „copyleft” to wykorzystanie prawa do aktywnego kształtowania działalności podmiotów trzecich. Tu, jak widać, trudno mówić o sukcesie, bo też i nikomu jeszcze nie udało się za pomocą normy prawnej zmusić ludzi, aby byli dobrzy, przyjaźni, uczciwi i pisali dobre oprogramowanie. Podsumowując, norma „copyleft”, bez dodatkowej motywacji do uczestniczenia w projekcie wolnego oprogramowania jest w stanie jedynie uchronić ten projekt przed gapowiczami, którzy chcieliby niskim kosztem wykorzystać pracę członków społeczności. Nie jest ona natomiast w stanie zbudować lub rozwijać tej społeczności – do tego potrzeba czegoś więcej.

Jeżeli tak jest w istocie, to pojawia się pytanie, czy angażowanie systemu prawa oraz czasu twórców wolnego oprogramowania w egzekwowanie klauzuli „copyleft” jest w ogóle warte zachodu. Jest tak dlatego, że dobry, wartościowy kod i tak wpływa do projektów dzięki uczestnikom społeczności powodowanych w większości pozaprawną motywacją. Prawo natomiast jest w stanie jedynie dostarczyć społeczności kodu wątpliwej jakości, a i to za cenę nakładów jakimi są koszty wezwania do usunięcia naruszenia, ewentualnego procesu sądowego i związanych z tym kosztów obsługi prawnej. Jeżeli wierzyć Welte, to kod ten nadaje się jedynie do wyrobienia sobie negatywnej opinii o profesjonalizmie jego dostawcy. Zakładając, że doświadczony nabywca i tak dokonałby audytu kodu źródłowego, to ze wspomnianych wyżej nakładów korzyść odniosą jedynie ci użytkownicy, którzy nie byliby w stanie wynegocjować od dostawcy takiego audytu, lub też tacy, dla których jakość nabywanego oprogramowania nie ma istotnego znaczenia. Innymi słowy, „copyleft” pełni tu rolę Urzędu Ochrony Konkurencji i Konsumentów.

Wobec tego, twórca rozpowszechniający swój program z klauzulą „copyleft” nie generuje przez to istotnej wartości dodanej dla siebie, ani nawet dla społeczności tworzącej się wokół tego programu. Większość tej wartości będzie bowiem zaabsorbowana przez zwykłych użytkowników programu, a i to w ograniczonym zakresie – poprzez fakt, że będą mogli ewentualnie lepiej ocenić jakość nabywanego produktu. Ironiczne jest to, że tę możliwość uzyskują podmioty, dla których nie tylko cztery wolności Stallmana, ale i nawet jakość oprogramowania nie stanowią istotnej istotnej cechy podlegającej ocenie.