Postanowiłem sprawdzić, ile zajęłoby przystępne wyjaśnienie warunków LGPL przeciętnemu użytkownikowi, szczególnie nastawionemu na działalność komercyjną. Dodałem do roboczej wersji dokumentacji odpowiedni dodatek i zacząłem pisanie. Wynikiem była rozciągająca się na dwa ekrany lista z objaśnieniami, dlaczego i jak twórcy serwisów WWW na zamówienie mogą z niej korzystać, kiedy trzeba udostępnić kod źródłowy i tak dalej. Oczywiście jest to nie do zaakceptowania - sam nie lubię zbytnio zbyt skomplikowanych ograniczeń i nie mam zamiaru zmuszać w ten sposób bez wyraźnego powodu innych.
Powodem, dla którego wybrałem licencję GPL, była paradoksalnie chęć ochrony bibliotek przed zamianą w oprogramowanie własnościowe. Taki los spotkał kiedyś projekt Wine, rozpowszechniany początkowo na licencji MIT. Po pewnym czasie powstały zamknięte, komercyjne wersje dostępne bez kodu źródłowego. Co prawda jedna 150-kilobajtowa biblioteka specjalnej wartości handlowej nie ma, ale wolę spać spokojnie, tym bardziej, że mają pojawić się inne. Niestety nie ma żadnej licencji, która od razu pasowałaby do potrzeb:
- Dawała pełne prawa do łączenia zarówno z kodem open-source, jak i własnościowym pod warunkiem zachowania informacji o autorach, a w przypadku kodu źródłowego zachowania w stosunku do niego warunków licencji.
- Nakazywałaby rozpowszechnianie samej biblioteki (przeznaczonej do łączenia z innymi programami) także w postaci kodu źródłowego, co automatycznie implikowałoby zachowanie licencji.
Myślę, że takie ujęcie oprogramowania open-source najlepiej chroni prawa końcowego użytkownika. Zabraniając samodzielnej redystrybucji jedynie w postaci binarnej i ze zmienioną licencją, ma on pewność, że jeśli znajdzie jakąś paczkę OPT, będzie mógł z niej skorzystać na takich samych warunkach, jak z oryginału. Jeśli zaś trafi na zamkniętą wersję, oznacza to, że może być ona przystosowana, a na pewno jest przeznaczona do pracy z jednym, konkretnym skryptem.
Najpewniejszym kandydatem na licencję jest jakaś zmodyfikowana wersja licencji BSD bez klauzuli ogłoszeniowej. Niestety trzeba się pobawić w dodanie do niej rzeczonego warunku w języku angielskim. Dobór właściwego słownictwa trochę potrwa i zapewne nie obejdzie się bez jakiejś pomocy bądź porady kogoś z zachodu. Dlatego wersje rozwojowe w dalszym ciągu będą dostępne na GNU LGPLv3, natomiast wersję finalną przygotuję już na nowej, znacznie łatwiejszej w użyciu licencji.
Oprócz tego, chciałbym udostępnić także wersje płatne bibliotek, niezależnie od tego, że sam kod rozpowszechniany będzie niezwykle liberalnie. Nie byłyby one drogie - myślę, że cena wahałaby się w granicach 20-40 złotych tak, żeby mógł sobie na nią pozwolić niemal każdy zainteresowany. Dochód byłby przeznaczony głównie na utrzymanie domen, serwerów i cele promocyjne, gdyż utrzymanie tego wszystkiego trochę pieniędzy kosztuje. O ile pod względem kodu wersja taka nie różniłaby się od darmowej, nabywca dostawałby kilka bonusów. Aktualnie mam pomysły na następujące:
- Dodatkowe materiały informacyjne.
- Prawo do włączenia materiałów informacyjnych do dokumentacji końcowej użytkownika.
- Przykładowe projekty wraz z kodem źródłowym i szeregiem komentarzy.
- Wcześniejszy dostęp do nowych wersji (np. tydzień)
- Dodatkowe wydania pojawiające się np. w przypadku znalezienia jakiegoś nie-krytycznego błędu, zawierające stosowną poprawkę.
- Możliwość umieszczenia szerszych informacji o projekcie wykorzystującym biblioteki na stronie grupy.
Co o czymś takim sądzicie? Myślę, że na czymś takim zyskają wszyscy: my, bo nie będziemy musieli opłacać serwerów z własnej kieszeni; nabywcy, bo dostaną dodatkowe materiały i bonusy, a w dalszej konsekwencji wszyscy użytkownicy, jako że w celu ich przyciągnięcia powstawać będzie więcej tutoriali, artykułów itd.

Hmm, mam mieszane uczucia co do udostępniania płatnej wersji bibliotek. Chciałbym podsunąć całkowicie inny pomysł - rozwijania projektu całą społecznością. Trac z ticketami, repozytorium SVN, itd. Myślę, że OPT to tak dobry projekt, że na pewno znajdą się osoby, które pomogą w tym; trzeba tylko dać możliwość.
Co do wydatków na serwery, itp. - nie wiem, ile by dała podstrona "Donate". Wg mnie, jeśli ktoś na gwałt potrzebuje jakiejś zmiany, poprawki, to wesprze projekt, a w tytule przelewu dopisze "z prośbą o dodanie opcji X".
Jedno drugiego nie wyklucza, tym bardziej że co do grupy mam dalsze plany. Zauważ, że PHP także jest rozwijany w ten sposób: każdy może się przyłączyć, a oprócz tego Zend sprzedaje sobie pakiet Zend Core. Bugtracker mamy, SVN będzie, przygotowania nad wiki rozpoczęte.
Jeśli chodzi o kod, jedyna różnica między "opłaconą", a darmową wersją będzie taka, że jeśli ukaże się jakaś łatka, normalnie będzie ona dostępna przez SVN, a nabywcy otrzymają gotową paczkę do ściągnięcia. A i to też nie zawsze, bo dla każdej głupoty nie będę przygotowywać paczki, zaś krytyczne błędy będą skutkować zupełnie nowym wydaniem, tak jak to miało miejsce w zeszłym roku z OPT 1.1.1 i zbyt wysokim zużyciem pamięci.
Brzmi całkiem dobrze. Jednak jeśli będziecie pobierać jakieś opłaty (np. te 20-40 zł), to osoby contributujące nie będą już tak chętne do pomocy. "Co będę pomagał tworzyć projekt, skoro oni mają z tego kasę?" Musicie dobrać złoty środek - jakiś kompromis między jednym, jak i drugim rozwiązaniem.
Trzeba wyjaśnić jedną rzecz: płacić tak naprawdę użytkownik będzie za te wszystkie tutoriale i dodatkowe prawa. Więc może lepiej będzie nazwać to inaczej: nie "płatna" wersja biblioteki, a płatne materiały i usługi dodatkowe. Oczywiście nie wszystkie tutoriale będą płatne, bo nauczony doświadczeniem z OPT 1.x wiem, jak to jest istotne.
Ponadto teraz nikt na tym nie zarabia, a jakoś nie widzę tłumów z poprawkami pod mymi drzwiami :). Nawet artykułu nikomu się napisać nie chce :). A jak będą pieniądze, można się pokusić o zorganizowanie konkursu programistycznego z niezłymi nagrodami. Inna sprawa: jeśli ktoś tak myśli, to hmmm... według mnie na programistę się nie nadaje ani trochę i z kimś takim na pewno nie chciałbym nigdy i nigdzie pracować. Paskudna krótkowzroczność - popatrz: komuś biblioteki się spodobają i poświęci swój czas na poznanie ich tajników. Zacznie nadsyłać poprawki, modyfikacje itd. Możliwe, że się nam one spodobają i gościa przyjmiemy do grupy. Jeśli nie, nikt mu nie broni opracować własnych materiałów i też ich sprzedawać. Dopóki udostępnia kod źródłowy, jest w porządku.