To drm, or not to drm ?

Ostatnio na Warsztacie pojawił się wątek o drm. Autor [revo] pyta o porady w kwestii zbudowania jakiegoś prostego mechanizmu zabezpieczenia programu dystrybuowanego przez internet. Oprócz kilku sugestii rozwiązania, rozpoczęła się również dyskusja nad zasadnością stosowania takich mechanizmów.

Generalnie moją opinię [bez sensu] można poznać na forum. Chodzi mi jednak po głowie kilka pytań.

Jak daleko można posunąć się w walce z piractwem ? Autor ma niezaprzeczalne prawo do otrzymania wynagrodzenia za swoją pracę, a piraci to prawo teoretycznie łamią. Zwalczanie piractwa jest więc czymś naturalnym i moralnie uzasadnionym ;) Tylko czy śledzenie swoich klientów i traktowanie każdego z nich jak złodzieja jest etyczne ? Czy utrudnianie życia klientowi jest dopuszczalne ?

Zdarzyło mi się już zobaczyć komunikat informujący mnie, że odpalenie legalnie nabytej gry nie jest możliwe, bo jakieś zabezpieczenie uznało oryginalną płytę za nie oryginalną. Co ma zrobić użytkownik w takiej sytuacji, szukać crack'a, może czekać na rozwiązanie od wydawcy ? Ja usunąłem grę i nie zainstalowałem patch'a który ten błąd wywołał. Akurat się dało, ale nie zawsze musi.

Anonimowość w sieci nie istnieje. Zmuszanie klienta do zdradzenia nam swoich danych (ip, mac) poprzez różne formy rejestracji, aktywacji itp. również jest czymś z czym trudno mi się pogodzić. Jaką klient ma pewność, że serwer przechowujący te dane jest odpowiednio zabezpieczony i że nikt tych danych nie wykorzysta ? W stanach FBI ma władze absolutną, a ja nie chcę żeby mnie FBI śledziło, bo kupiłem sobie grę, którą jakiś gryzipiórek uzna za podejrzaną ! (nie mam manii prześladowczych, ot taki przesadzony przykład ;) )

Czemu piraci tylko teoretycznie naruszają prawo do wynagrodzenia ? Długo myślałem i nie wymyśliłem jak udowodnić, że pirat kupiłby dany program, gdyby nie mógł go ukraść. Z drugiej strony pojawia się również kwestia możliwego zakupu legalnej wersji po przetestowaniu pirackiej (może jakieś promile promila). Osobiście mam wrażenie, że ogromna większość piratów nie dokonałaby zakupu, zmniejszając tym samym popularność produktu.

Kłopoty i problemy

Witam wszystkich w nowym roku.
Wyjazd na narty sie udał. Niestety tydzień po powrocie dopadła mnie angina, która po czterech dniach zamieniła się zapalenie ślinianek. W efekcie przez prawie dwa tygodnie nie mogłem nic napisać :(
Tak naprawdę usiadłem przed kompem dopiero wczoraj. No i muszę powiedzieć, że były to całkiem ciekawe dwa dni ;) Tuż przed świętami zacząłem robić obsługę urządzeń wejściowych. Wybrałem bibliotekę OIS, bo przyjazna w użyciu i raczej nie ma co narzekać na możliwości. Oczywiście przed wyjazdem nie skończyłem tego i takie rozgrzebane przeleżało aż do wczoraj. Udało mi zapanować nad wszystkimi problemami i skompilować kod. Jednak linker zaczął płakać, że ma nie zdefiniowane symbole z biblioteki OIS ?! No przecież ją "instalowałem". Zajrzałem do ustawień projektu no i jest OIS_static dodane. Google podpowiedziało rozwiązanie. W projekcie C::B nie są włączone wszystkie pliki. Heh. Odpaliłem C::B, dodałem brakujący plik, rebuild, kopiowanie lib'ki do mingw. Eclipse wciąż marudził na nie zdefiniowane symbole. Okazało się, że trzeba jeszcze dołączyć bibliotekę DirectX Input, w postaci dwóch plików dx input 8, oraz dx guid. I na tym się dzień wczorajszy skończył.
Dziś postanowiłem dopisać kod, który będzie inicjalizował moduł wejścia. Zrobiłem sobie klasę Input::Manager, zbliżoną do Graphics::Manager. Oczywiście klasa wylądowała w plikach manager.hpp i cpp, podobnie jak jej siostra z modułu graficznego. No i rzecz jasna w obu plikach pojawił standardowy strażnik "#ifndef MANAGER_HPP ... " A ja przez pól dnia zastanawiałem się czemu do licha klasa Input::Manager jest undefined ;)