Rodney Clark zaznaczył, że Microsoft „zawsze postrzegał w ten sposób umowy roczne”, dodając: „Niekoniecznie jednak egzekwowaliśmy miesięczną interpretację tych umów. Patrząc więc na dzisiejszy model biznesowy, nie widać praktycznie żadnej różnicy od poprzedniego. Partner musi ocenić wiarygodność kredytową każdego klienta. Jeśli uzna, że jest ona niewystarczająca, może wybrać plan miesięczny”.

Komentarze Clarka to odpowiedź na skargi dostawców usług zarządzanych i innych rozwiązań, którzy obawiają się, że ich klienci będą musieli płacić więcej za miesięczną subskrypcję, gdy zmiany wejdą w życie, co nastąpi już w marcu br. Dopłata za subskrypcję miesięczną nakłada się na ogłoszone wcześniej ogólne podwyżki cen Microsoft 365, planowane na 1 marca br.

Wśród niezadowolonych partnerów Microsoftu znalazł się Axiom z Jacksonville na Florydzie. Zeszłej jesieni integrator ten uruchomił petycję online, domagając się rezygnacji z wyżej wspomnianej 20-procentowej podwyżki za miesięczną subskrypcję Microsoft 365. Do tej pory pod petycją podpisało się ponad 1909 osób.

Zmiany w modelu licencjonowania Microsoft 365 zbiegły się w czasie z wprowadzeniem przez software’owego potentata nowej, ujednoliconej platformy do sprzedaży licencji pod nazwą New Commerce Experience (NCE). Platforma NCE ma zapewnić partnerom Microsoftu „większy wybór i elastyczność”, niezależnie od tego, czy zaproponują swoim klientom subskrypcję Microsoft 365 z rozliczeniem miesięcznym czy rocznym. Zdaniem Rodneya Clarka zarówno klienci, jak i partnerzy wiele zyskają, wybierając umowę roczną.

– Cena jest atrakcyjna, a partner może samodzielnie zdecydować, komu zaoferować wydłużoną subskrypcję roczną. W zależności od sytuacji może pobrać całą płatność z góry albo wystawiać klientowi miesięczne faktury na własnych warunkach. Takie rozwiązanie jest bardziej elastyczne i pomaga oferować wsparcie klientom, niekoniecznie jednak zmienia profil ryzyka, który zawsze był obecny – mówi przedstawiciel Microsoftu.

Aby ułatwić partnerom i klientom migrację na platformę NCE, Microsoft wprowadził zniżkę, dzięki której do czerwca unikną 20-procentowej podwyżki za subskrypcję miesięczną. Oprócz tego Microsoft oferuje 5-procentową zniżkę na subskrypcje roczne. Promocja ma obowiązywać w marcu, ale Microsoft rozważa przedłużenie jej do czerwca. Obie zniżki dotyczą licencji seat-based (dowolna liczba urządzeń jednego użytkownika) dla maksymalnie 2400 użytkowników na subskrypcję. Nie obejmują natomiast subskrypcji Windows 365.

Nowa epoka

Clark uważa, że platforma NCE, która ogranicza liczbę obecnych na rynku modeli licencjonowania z dwudziestu do zaledwie trzech, wyznacza nową epokę prostszego licencjonowania oprogramowania dla klientów i partnerów Microsoft. Platforma NCE, ogólnodostępna od 10 stycznia, miała zostać wprowadzona już w październiku zeszłego roku. Jej uruchomienie zostało jednak przełożone, aby dać partnerom więcej czasu na przystosowanie się do zmian.

– W tym okresie wspieraliśmy naszych partnerów, oferując im dodatkowe zasoby, w tym zasoby techniczne oraz modelowanie w oparciu o ich model biznesowy, aby przygotować się na ten moment – podkreśla Rodney Clark.

Platforma NCE przedstawia drastyczną zmianę w złożonym modelu sprzedaży licencji oprogramowania „go-to-market” Microsoftu i zarazem największy zwrot modelu chmurowego odkąd firma wprowadziła program Cloud Solution Provider w 2015 r.

Trzy nowe modele wprowadzania rozwiązań na rynek to kolejno: kanał szerokiego zasięgu obejmujący partnerów CSP, kanał enterprise oraz kanał samoobsługowy. Clark tłumaczy, że taka zmiana ułatwia nabycie licencji klientom, którzy do tej pory dysponowali ponad dwudziestoma różnymi sposobami zakupu, w tym przez programy CSP, Open License i Select Plus czy bezpośrednio online.

Microsoft ogłosił, że po 10 marca wszystkie subskrypcje CSP muszą zostać przeniesione na platformę NCE. Od 1 lipca br. posiadane subskrypcje będzie można odnawiać tylko przez NCE, a w lipcu 2023 r. wszystkie subskrypcje nadal działające w starym modelu CSP trzeba będzie przenieść do NCE.

Clark nazwał platformę NCE „rzadkim połączeniem” zmian w modelu biznesowym, polityce biznesowej i technologii. W jego opinii NCE oznacza zmiany między innymi w zakresie technicznym, back-endu, integracji API czy polityki biznesowej. Wyjaśnia przy tym, że motywacją do wdrożenia platformy NCE było ograniczenie liczby sposobów, na które klienci mogą kupować oprogramowanie Microsoftu. Celem były elastyczność, prostota i efektywność, którą – zdaniem Clarka – klienci wysoko sobie cenią.

– Nie ma znaczenia, gdzie znajduje się klient: czy nabywa licencje przez kanał enterprise czy w inny sposób, wszyscy korzystają z jednej, wspólnej platformy. O to właśnie proszą klienci. Chodzi o efektywność zarówno dla naszych klientów, jak i partnerów – deklaruje szef kanału partnerskiego Microsoftu.

Platforma NCE wprowadza spore zmiany dla partnerów, upraszczając licencjonowanie za pomocą pulpitu, który pozwala zaplanować liczenie licencji i rejestrować automatyczne odnawianie subskrypcji.

– Dzięki nowemu pulpitowi nasi partnerzy mogą działać dużo wydajniej, na przykład planując liczenie licencji, robiąc konwersję jednostek SKU, a także automatycznie zarządzając subskrypcjami i przypisując licencje do użytkowników – wyjaśnia Rodney Clark.

Jego zdaniem platforma NCE potwierdza zasadność modelu sprzedaży CSP: „Zapewniwszy elastyczność dzięki New Commerce, jako partnerzy chcemy rozwijać się przez kanał CSP”.

Artykuł Microsoft broni nowego modelu licencyjnego pochodzi z serwisu CRN.

Otóż nie i nie. To jedna z pułapek ideologicznego myślenia o open source. Twórcy tych licencji dbają o to, aby twórca opracowania (czyli nasz programista ze spółki A, czy raczej sama spółka) nie „zamknęły” kodu takich opracowań. Ale nie oznacza to, że zmuszają, aby kod zawsze pokazać publicznie, nie oznacza, że świat „zewnętrzny” ma zawsze roszczenia. Open source działa w relacji licencjodawca – licencjobiorca. Jeżeli udzielana jest licencja, licencjobiorca (i tylko on) może żądać dostarczenia kodu źródłowego. Jeżeli żadna ze stron takiej umowy nie jest zainteresowana udostępnieniem kodu źródłowego innym osobom, nie mają takiego obowiązku. Dopiero gdy spółka B rozpowszechni oprogramowanie, które nabyła, będzie musiała udostępnić kod źródłowy każdemu z użytkowników tego oprogramowania.

Mechanizm ten ma szczególną wagę w grupach kapitałowych. Jeżeli jedna ze spółek ma charakter tzw. CUW/Centrum IT i opracowuje rozwiązania dla całej grupy – choćby i tysiąca spółek – to każda z tych spółek ma prawo do otrzymania kodu, ale nie mają obowiązku jego pokazywania na zewnątrz. Mimo objęcia kodu licencją GPL można więc cały czas kontrolować know-how i tajemnice przedsiębiorstwa, jeżeli są zawarte w kodzie.

A teraz druga zagadka: ten sam programista (spółka A) mówi „hola, hola, ale tam jest pełno mojego kodu – udostępnię na licencji GPL tylko to, co jest pierwotnie na GPL, a to co opracowałem, na własnościowej, komercyjnej licencji”. Czy taki „hybrydowy” mechanizm ma szansę zadziałać?

Ma, ale rzadko. Wszystko zależy od tego, co i jak połączył programista. Nie każde użycie kodu open source, nawet na GPL, zaraża. To wyzwanie zarówno od strony prawnej, jak i architektury systemu, ale bywa i tak, że możemy zaprojektować rozwiązanie w ten sposób, by ryzyka zarażenia uniknąć (IP by design). Jednak GPL ma tę cechę, że w zarażaniu jest bardzo skuteczny. Żeby wytłumaczyć, jak ten mechanizm zarażania działa, potrzeba trochę teorii.

Interfejs między prawem autorskim a klauzulą copyleft

Ochrona praw autorskich do utworów nie ogranicza się do ich dosłownej treści. Nie miałaby ona sensu, gdyby po dokonaniu prostych modyfikacji można było korzystać z utworu bez zgody autora. Dlatego też prawo autorskie pozwala autorowi kontrolować również wykorzystanie utworów zależnych (adaptacji, tłumaczeń, aranżacji i innych zmian, określanych łącznie mianem opracowań). Na poziomie międzynarodowym zostało to uregulowane w art. 8 i 12 Konwencji Berneńskiej, a w UE w odniesieniu do programów komputerowych w art. 4 (1) (b) dyrektywy 2009/24/WE. Na poziomie krajowym jest ono traktowane albo jako odrębne prawo (najczęściej określane jako „prawo do adaptacji”) [1], albo jako część szerszego prawa do zwielokrotniania [2]. W każdym przypadku, gdy mamy do czynienia z utworem zależnym (opracowaniem), korzystanie z niego wymaga zgody nie tylko autora utworu zależnego (opracowania), ale także autora utworu pierwotnego (oryginału).

Prawo autorskie nie definiuje, czym jest opracowanie. Najogólniej rzecz ujmując, jego istotą jest „twórcza ingerencja” w dzieło twórcy pierwotnego. Każde opracowanie, w tym opracowanie programu komputerowego, jest więc wynikiem twórczości intelektualnej, w której występują obok siebie elementy twórcze zaczerpnięte z utworu oryginalnego, a także elementy twórcze dodane przez twórcę utworu zależnego. W świecie innym niż rynek oprogramowania to na przykład tłumaczenie „Harry’ego Pottera” czy adaptacja filmowa książek J.K. Rowling. Niby coś innego, literka w literkę nie ma sensu porównywać, ale gdyby nie oryginał, opracowania by też nie było.

Możliwość kontrolowania korzystania z utworów w postaci opracowania zapewnia klauzula copyleft. Z prawnego punktu widzenia, klauzula copyleft to zezwolenie na korzystanie z opracowania programu pierwotnego (oryginału), udzielone przez pierwotnego autora (autorów) pod warunkiem, że opracowanie zostanie również udostępnione na tych samych warunkach. Klasyczny przykład takiej klauzuli znajdziemy w GNU GPL 2.0, która stanowi w paragrafie 2 (b), że: „Musisz spowodować, że jakakolwiek praca, którą rozpowszechniasz lub publikujesz, która w całości lub w części zawiera lub jest pochodną Programu lub jego części, będzie licencjonowana jako całość bez opłat dla wszystkich stron trzecich zgodnie z warunkami niniejszej Licencji”. Na pierwszy rzut oka proste. Jednak trudność tkwi w udzieleniu odpowiedzi na pytanie, kiedy w przypadku software’u dochodzi do powstania opracowania. Spróbujmy przejść przez kilka scenariuszy.

Artykuł Open source: trochę dłuższa analiza (cz. II) pochodzi z serwisu CRN.

Jeden z podstawowych nurtów to fundacja Free Software Foundation, której celem, jak i celem stojącego na jej czele guru R. Stallmana, jest tworzenie i rozpowszechnianie „wolnego” oprogramowania („free software”),  a także prawne zabezpieczanie jego dalszej „wolności”, przy czym angielskie słowo „free” oznacza tu właśnie „wolność”, a nie „darmowość”. Zgodnie z Free Software Definition licencje na „wolne” („wolnodostępne”) oprogramowanie powinny zapewniać każdemu wolność: wykorzystania oprogramowania w dowolnym celu (również „komercyjnym”), badania oprogramowania i dostosowywania go do własnych potrzeb, rozpowszechniania oprogramowania w dowolny sposób, w tym również rozpowszechniania w zmodyfikowanej (dostosowanej, udoskonalonej) postaci. Jednocześnie w ramach FSF silnie akcentuje się ideologiczny sprzeciw środowiska programistów przeciw nadmiernie restrykcyjnym regulacjom prawa autorskiego i dotychczasowym „własnościowym” regułom udostępniania oprogramowania, którym towarzyszy zamiar izolowania poszczególnych użytkowników, ich podporządkowania i uzależnienia od dostawcy.

Jak podkreśla preambuła najbardziej znanej licencji stworzonej przez FSF: „większość licencji na oprogramowanie pomyślana jest po to, aby odebrać użytkownikowi możliwość swobodnego udostępniania innym i zmieniania danego oprogramowania. Natomiast w wypadku GNU General Public License (GNU GPL), celem jest zagwarantowanie użytkownikowi swobody udostępniania i zmieniania tego wolnego oprogramowania, a więc danie pewności, że oprogramowanie jest wolnodostępne dla wszystkich użytkowników”. Celem GNU GPL jest więc przełamanie przywilejów wynikających z praw własności intelektualnej, jakie przyznawane są twórcy w zamian za jego pracę, i zapewnienie swobody przepływu informacji dla dobra publicznego.

W najbardziej radykalnych wypowiedziach R. M. Stallmana i Free Software Foundation spotkać można opinię, że korzyści materialne nie powinny być jedynym czy głównym czynnikiem motywującym programistę do pracy twórczej. Wystarczającą motywacją powinna być sama radość tworzenia, możliwość samorealizacji czy zdobycia uznania. Ponieważ chodzi tu w pewnym sensie o odwrotność „copyright”, używa się tu terminu „copyleft”, a „wolne” oprogramowanie udostępniane na licencjach GNU GPL i zbliżonych, tj. gwarantujących jego „wolność” również w przyszłych wersjach, nazywa się „copylefted software”.

Idealizm Free Software Foundation, ironicznie określany mianem „informatycznego komunizmu”, nie jest podzielany przez wszystkich aktywistów open source. Przeciwnicy podejścia FSF podkreślają, że ruch open source ma znaczenie przede wszystkim jako alternatywa i uzupełnienie komercyjnych produktów informatycznych. Może on sprzyjać wzrostowi konkurencji na rynku, przełamaniu dominacji dużych producentów i promowaniu niezależnych standardów technicznych, w oparciu o które zarówno indywidualni programiści, jak i mali i średni producenci oprogramowania, mogą oferować własne produkty i usługi. Innymi słowy celem ruchu powinna być nie tyle „wolność”, co „otwartość” oprogramowania. Tak też cele open source postrzegane są przez Open Source Initiative (OSI) i drugą z czołowych postaci ruchu – E. S. Raymonda.

Zgodnie z opracowaną przez OSI definicją Open Source Definition program należy do kategorii open source, jeżeli licencja zapewnia: swobodną redystrybucję programu (zwielokrotnianie w celu udostępnienia osobom trzecim i rozpowszechnianie oprogramowania); dostęp do kodu źródłowego; swobodę modyfikowania i dokonywania opracowań; swobodę rozpowszechniania modyfikacji i opracowań programu; brak dyskryminacji jakichkolwiek osób lub grup osób; brak ograniczeń co do sposobu wykorzystania oprogramowania; objęcie licencją open source całości rozpowszechnianego programu, a nie tylko wydzielonej części; zakaz uzależniania udzielenia zezwolenia na korzystanie z programu od uzyskania licencji dotyczącej innego produktu; zakaz wpływania na sposób udostępniania i korzystania z innego oprogramowania (np. poprzez postanowienia umowne, że wszystkie programy rozpowszechniane na jednym nośniku muszą należeć do kategorii open source).

Bardziej pragmatyczne podejście Open Source Initiative jest źródłem rozbieżności pomiędzy FSF a OSI. Z praktycznego punktu widzenia różnice pomiędzy Free Software Definition a Open Source Definition są jednak nie aż tak wielkie. Istnieją licencje spełniające przesłanki Open Source Definition, które z punktu widzenia FSF są zbyt restrykcyjne, jak również takie, które wprawdzie spełniają przesłanki Free Software Definition, jednak nie mogą być uznane za Open Source. Przypadki takie są wprawdzie stosunkowo rzadkie, jednak ideologiczne spory pomiędzy poszczególnymi odłamami ruchu powodują, że w ostatnich latach popularność zdobywa „politycznie poprawny” termin Free, Libre, Open Source Software (FLOSS), obejmujący wszystkie odmiany „niewłasnościowego” oprogramowania. My stosujemy dalej pojęcie „open source”, mając na myśli jak najszerszą kategorię (czyli FLOSS).

Przełamanie przywilejów

Celem licencji open source jest więc przełamanie przywilejów twórcy wynikających z praw własności intelektualnej oraz zapewnienie swobodnego przepływu informacji z korzyścią dla społeczeństwa. Innymi słowy, podstawowym celem licencjonowania open source jest odmówienie komukolwiek prawa do wyłącznego korzystania z utworu. Oprogramowanie komputerowe jest przede wszystkim chronione prawem autorskim (niestety). Dodatkowo, w wielu jurysdykcjach, pewne innowacyjne elementy funkcjonalne oprogramowania mogą być chronione patentami jako tak zwane wynalazki realizowane za pomocą komputera. Przedmiotem patentu może być zarówno produkt (np. standardowy komputer z zainstalowanym innowacyjnym oprogramowaniem wykonującym pewne funkcje), jak i proces (np. pewien przebieg czynności wykonywanej za pomocą programu komputerowego). Ponadto, oprogramowanie może zawierać inne elementy chronione jako własność intelektualna. W szczególności nazwa oprogramowania lub organizacji, która zarządza jego rozwojem może być zarejestrowana jako znak towarowy.

Wszystkie licencje open source uwzględniają wykorzystanie oprogramowania objętego licencją jako przedmiotu prawa autorskiego. Ponadto, niektóre licencje open source zawierają postanowienia zapewniające, że jeśli jakiekolwiek elementy oprogramowania byłyby chronione patentami, zezwolenie zawarte w licencji obejmuje również zezwolenie na korzystanie z wynalazku chronionego tym patentem. Jest to szczególnie prawdziwe w przypadku licencji takich, jak: Academic Free License 3.0, GPL 3.0, AGPL 3.0, Apache 2.0, Eclipse Public License 2.0, Mozilla Public License 2.0.

Inaczej wygląda sytuacja w przypadku znaków towarowych. Wiele licencji zawiera wyraźne ograniczenia dotyczące korzystania z niektórych znaków towarowych. Na przykład licencja Apache 2.0 nie zawiera prawa do używania znaku towarowego licencjodawcy, z wyjątkiem uzasadnionego i zwyczajowego użycia w opisie pochodzenia oprogramowania. Podobne postanowienia można znaleźć w licencjach BSD-3-clause,PHP-3.0 i GNU GPL 3.0. Ze względu na „otwartość” oprogramowania open source, jego elementy nie mogą być także chronione jako nieujawnione know-how lub tajemnica handlowa.

Objęcie oprogramowania licencją open source nie powinno być rozumiane jako zrzeczenie się praw własności intelektualnej lub przekazanie go do domeny publicznej (to bardzo ważne, ponieważ często, a błędnie, właśnie tak podchodzi się do OS). Oprogramowanie open source nadal jest chronione prawem autorskim, a korzystanie z niego wymaga przestrzegania warunków licencji. Nawet najprostsze licencje, takie jak MIT czy BSD-2-clause, nakładają na użytkownika pewne zobowiązania, takie jak obowiązek dostarczenia informacji o używanym oprogramowaniu. Inne często spotykane postanowienia to obowiązek informowania o dokonanych zmianach, udostępniania kodu źródłowego oprogramowania open source w związku z jego rozpowszechnianiem oraz udostępniania kodu źródłowego wszelkich modyfikacji dokonanych w rozpowszechnianej kopii oprogramowania. Licencje GPL to już zestaw bardzo daleko idących wymagań.

Charakter prawny licencji OS

Charakter prawny licencji OS nie jest w pełni jasny. W większości jurysdykcji licencje te są interpretowane jako umowy (np. w Belgii, Chorwacji, Czechach, Francji, Hiszpanii, Holandii, Niemczech, Portugalii, Rumunii, Turcji, na Węgrzech). W niektórych krajach (np. w Grecji) rozważa się również ich kwalifikację jako jednostronnej zgody uprawnionego. Z drugiej strony, w kilku krajach, m.in. ze względu na brak orzecznictwa, sytuacja pozostaje niejasna. Przykładowo w Polsce, w odniesieniu do licencji GNU GPL, rozważano zakwalifikowanie jej częściowo jako umowy (w zakresie zezwolenia na rozpowszechnianie objętego nią oprogramowania), częściowo jako jednostronnej zgody na korzystanie z utworu (w zakresie eksploatacji programu open source przez użytkownika).

Co ważne, w wielu krajach Unii Europejskiej orzeczenia sądów potwierdziły skuteczność licencji open source, w tym charakterystycznych dla licencji GNU GPL klauzul copyleft (o których poniżej). Na przykład we Francji sąd zezwolił nabywcy programu na licencji GPL na wniesienie pozwu przeciwko dystrybutorowi programu na licencji GPL o ujawnienie kodu źródłowego. Podobnie w Niemczech sąd wydał wstępny nakaz przeciwko pozwanemu, który włączył oprogramowanie GPL do swojego oprogramowania własnościowego.

Podsumowując – niezależnie od sporów w literaturze prawniczej dotyczących kwalifikacji licencji open source, warunki określone w tych licencjach należy traktować jako wiążące. Wykorzystanie oprogramowania open source może więc nastąpić tylko na warunkach określonych w tych licencjach.

Open source i Creative Commons

Creative Commons to zbiór licencji opublikowanych po raz pierwszy w 2002 r. przez Creative Commons, amerykańską organizację non-profit założoną w 2001 r. Istnieje kilka rodzajów licencji Creative Commons. Różne wersje licencji narzucają różne prawa. Wszystkie licencje Creative Commons wymagają przypisania autorstwa do twórcy (opisanego elementem „BY”). Twórca może ponadto zastrzec, że licencjobiorcy mogą: (po pierwsze) rozpowszechniać utwory pochodne tylko na licencji identycznej („nie bardziej restrykcyjnej niż”) z licencją, która obowiązuje w stosunku do oryginalnego utworu (SA, Share-Alike element); (po drugie) kopiować, rozpowszechniać, wyświetlać i wykonywać utwór oraz tworzyć na jego podstawie utwory zależne wyłącznie w celach niekomercyjnych (NC, element niekomercyjny); (po trzecie) kopiować, rozpowszechniać, wyświetlać i wykonywać jedynie dosłowne kopie utworu, ale nie utworów pochodnych na nim opartych (ND, No Derivative Works element).

W związku z tym twórca, korzystając z licencji Creative Commons, zawsze zachowuje prawa autorskie, zezwalając jednocześnie innym na kopiowanie i rozpowszechnianie, a także może określić, czy korzystanie z utworu może odbywać się wyłącznie na warunkach niekomercyjnych, czy też ograniczyć tworzenie utworów zależnych. Licencje CC zawsze przyznają „prawa podstawowe”, takie jak prawo do rozpowszechniania utworu chronionego prawem autorskim na całym świecie w celach niekomercyjnych i bez modyfikacji.

Poza licencjami dotyczącymi praw autorskich, Creative Commons oferuje także CC0, czyli narzędzie pozwalające na umieszczanie materiałów w domenie publicznej. CC0 jest narzędziem prawnym, które pozwala twórcom zrzec się jak największej liczby praw. Narzędzie to powstało w związku z pojawiającymi się w wielu systemach prawnych wątpliwościami dotyczącymi zrzekania się praw autorskich przed upływem czasu ochrony.

Licencje Creative Commons oparte są na podobnej koncepcji co open source, ale nie są identyczne. Po pierwsze, są bardziej restrykcyjne w niektórych kombinacjach. Licencje zastrzegające użycie niekomercyjne (NC) i udostępnianie utworów zależnych (ND) nie są zgodne z definicjami wolnego oprogramowania i open source. Po drugie, są one generalnie przeznaczone do dzielenia się utworami innymi niż oprogramowanie i ich użycie w odniesieniu do oprogramowania nie jest zalecane. Ponieważ jednak programy komputerowe są utworami podlegającymi ochronie prawa autorskiego, objęcie ich licencją Creative Commons nie jest niemożliwe. Licencja CC BY-SA 4.0 jest kompatybilna z licencją GPL 3.0.

Standaryzacja open source

Jedną z zalet licencji open source (podobnie jak Creative Commons) jest de facto ich standaryzacja. W przypadku oprogramowania własnościowego istnieje duża różnorodność licencji, zarówno pod względem zakresu udzielanych praw, ograniczeń i warunków stosowanych przy korzystaniu z oprogramowania (tzw. metryk licencyjnych), jak i postanowień dodatkowych (np. zobowiązań dotyczących audytów licencyjnych czy odpowiedzialności). Oznacza to, że licencjobiorca przed podpisaniem umowy musi (a przynajmniej powinien) zapoznać się z bardzo obszernym i skomplikowanym dokumentem prawnym, często podlegającym nieznanemu mu prawu właściwemu (to często kilkaset stron tekstu, jeżeli uwzględnimy warunki kontraktowe publikowane w internecie). Zwiększa to koszty transakcyjne związane z udostępnianiem oprogramowania oraz niepewność prawną. W praktyce to wielkie wyzwanie dla organizacji, połączone z ryzykiem audytu i odszkodowań, ale to temat na inny tekst.

Z kolei w przypadku oprogramowania open source najczęściej stosowane są licencje opracowane przez organizacje popularyzujące ten model dystrybucji oprogramowania (takie jak wspomniana FSF) oraz fundacje zarządzające rozwojem dużych projektów open source (Apache, Mozilla, Eclipse). Dodatkowo, organizacje takie jak FSF czy Open Source Initiative regularnie dokonują przeglądu i oceny zgodności licencji z opracowanymi przez siebie definicjami wolnego i otwartego oprogramowania. W konsekwencji, licencje open source cieszą się dużym zaufaniem deweloperów i użytkowników. Przy czym w przypadku popularnych licencji (takich jak GNU czy Mozilla Public License) korzystanie z oprogramowania powinno być łatwiejsze w ocenie prawnej niż w przypadku licencji „zamkniętych”. Jak się okaże, nie zawsze.

Omawiane korzyści standaryzacji są częściowo ograniczane przez rosnącą liczbę licencji open source. The Open Source Initiative wymienia obecnie ponad 100 licencji spełniających definicję open source. Liczbę kombinacji zwiększają „wyjątki” dodawane przez niektórych deweloperów do danej licencji (np. wyjątek GCC Runtime Library, wyjątek Qt GPL). Wskazuje się, że zjawisko to, ogólnie znane jako „proliferacja” open source, ma kilka negatywnych konsekwencji. Po pierwsze niekompatybilność: przy większej liczbie licencji prawdopodobieństwo połączenia jednego produktu software’owego z innym, udostępnionym na niekompatybilnych warunkach licencyjnych, wzrasta wykładniczo. Po drugie niepewność: im więcej licencji open source jest wykorzystywanych w praktyce, tym mniej prawdopodobne jest, że będą one poddane kontroli sądowej i ocenie ekspertów prawnych. Analizie podlegają tylko popularne, szeroko stosowane licencje. Po trzecie zamieszanie i zwiększone koszty transakcyjne: im więcej licencji dotyczy danego projektu, tym trudniej jest ocenić, czy projekt spełnia warunki każdej z nich lub przewidzieć, jaki będzie prawny rezultat połączenia różnych programów.

Podsumowując, wykorzystanie komponentów na tzw. „permisywnych” licencjach open source (MIT, BSD, Apache) wiąże się najczęściej tylko z podaniem w dokumentacji odpowiedniej informacji o zastosowanym oprogramowaniu i licencji, która je obejmuje. Więcej uwagi należy poświęcić wykorzystaniu oprogramowania open source na licencjach typu copyleft. W tym przypadku istotny staje się sposób połączenia takiego oprogramowania z innymi elementami produktu, opisany poniżej. Ryzykowne może okazać się stosowanie komponentów na „egzotycznych” (rzadko spotykanych) licencjach, zwłaszcza jeśli nie zostały one poddane ocenie przez organizacje takie jak Free Software Foundation czy Open Source Initiative.

Rodzaje licencji OS – copyleft vs non-copyleft

Jednym z najpowszechniej przyjętych kryteriów klasyfikacji licencji open source jest rozróżnienie między licencjami typu copyleft i non-copyleft. Rozróżnienie to odnosi się do kwestii, czy wyniki dalszego rozwoju i modyfikacji programu muszą być udostępniane na tej samej lub „kompatybilnej” licencji, co oryginalny program. Ogólnie rzecz biorąc, licencje typu copyleft wymagają, aby wyniki dalszego rozwoju i modyfikacji programu były udostępniane na tych samych warunkach, co program oryginalny. Decydując się na wykorzystanie kodu objętego copyleft, korzystający (programista) „zaraża” swoje rozwiązanie (swój kod) tą licencją. Jego program, do którego użył komponentów copyleft, powinien być objęty warunkami pierwotnej licencji copyleft. Ten szczególny efekt (tzw. „wirus copyleft”) ma na celu zabezpieczenie „otwartości” danego programu i zapobieżenie jego „uprzywilejowaniu”, nawet jeśli jest on używany w dziełach pochodnych.

Powyższa konsekwencja ma duże znaczenie praktyczne. W wielu środowiskach open source traktowany jest jako darmowa „baza kodu” do swobodnego wykorzystania. Twórcy copyleft wprowadzili jednak przebiegły i bardzo skuteczny mechanizm – możesz z naszego rozwiązania skorzystać, ale wtedy twoje rozwiązanie będzie dalej dystrybuowane na naszych licencyjnych warunkach. O konsekwencjach opowiemy w dalszych częściach, ale to oznacza, że jak użyjemy copyleft, to nie będziemy mogli żądać opłat licencyjnych za nasze rozwiązanie czy też będziemy zobowiązani do ujawnienia kodu źródłowego całości rozwiązania (w tym naszej, autorskiej części).

Rozróżnia się dwa rodzaje klauzul typu copyleft. Pierwszą jest tzw. silny copyleft. W tym przypadku warunki licencji muszą być zachowane dla każdej pracy pochodnej. Jakbyśmy nie używali oprogramowania, „wirus” działa. Najbardziej znanymi przykładami są wszystkie wersje GNU GPL i GNU AGPL. Drugi typ to tzw. słaby copyleft. W tym przypadku warunki licencji muszą być zachowane dla określonych dzieł pochodnych. Czyli może okazać się, że mimo użycia oprogramowania copyleft, do „zarażenia” nie doszło. Licencje takie są najczęściej stosowane w przypadku bibliotek oprogramowania. Dzięki temu biblioteki te mogą być używane – pod pewnymi dodatkowymi warunkami – w produktach wydanych na innych licencjach i samo ich użycie nie prowadzi do „efektu wirusa”. Licencje, które wykorzystują „słabą” klauzulę copyleft to m. in. GNU Lesser General Public License (LGPL) oraz Mozilla Public License. W praktyce (czytaj: upraszczając) oznacza to, że korzystając z kodu z „silną” licencją prawie na pewno „zarazimy” nasz kod warunkami takiej licencji. W przypadku „słabej” licencji standardowe zastosowanie danego komponentu (np. odwołania do biblioteki na LGPL) nie stwarza takiego ryzyka.

Żeby było jeszcze trudniej – w niektórych przypadkach spotyka się także tak zwane „częściowe” klauzule copyleft. Częściowe licencje typu copyleft mają podobny skutek jak słabe klauzule copyleft. Częściowy copyleft zwalnia niektóre części utworu z copyleft, zezwala na rozpowszechnianie niektórych części utworu lub jego modyfikacji na warunkach innych niż licencja copyleft lub w inny sposób nie nakłada warunków copyleft na cały utwór. Przykładem częściowego copyleftu jest wyjątek GPL dotyczący linkowania, który zwalnia z copyleftu pliki nagłówkowe bibliotek oprogramowania i pozwala na dynamiczne linkowanie oprogramowania komercyjnego (np. wyjątek GCC Runtime Library). Skutek podobny do LGPL, ale diabeł tkwi, oczywiście, w szczegółach.

Zazwyczaj klauzula copyleft jest połączona ze zobowiązaniem do udostępnienia kodu źródłowego oprogramowania objętego licencją copyleft. Dzieje się tak dlatego, że licencja ta ma zapewnić użytkownikom możliwość czytania kodu, poprawiania go i dzielenia się swoimi zmianami. Skuteczne korzystanie z tych praw wymaga dostępu do kodu źródłowego.

Licencje „non-copyleft” (znane również jako „permisywne”) nie mają podobnych ograniczeń. Z reguły nie ma więc przeciwwskazań do łączenia rozwiązań „własnościowych” i „otwartych”, w tym udostępniania rozwoju „otwartego” programu na licencji „zamkniętej”. Najpopularniejsze przykłady to MIT, BSD (wszystkie wersje) oraz Apache. Licencje te nie nakładają obowiązku udostępniania kodu źródłowego. Oznacza to, że program objęty taką licencją może być udostępniony zarówno w postaci binarnej, jak i źródłowej, niezależnie od tego, czy został zmodyfikowany, czy nie.

Autorzy są Partnerami w kancelarii Maruta Wachta.

Artykuł Open source: trochę dłuższa analiza (cz. I) pochodzi z serwisu CRN.

Firmy, zatrzymanych przez CBA osób, dostarczyły sprzęt komputerowy do 16 instytucji i samorządów m.in. do Kancelarii Sejmu RP, Uniwersytetu Warmińsko-Mazurskiego w Olsztynie, Pomorskiego Uniwersytetu Medycznego w Szczecinie, do Urzędu Marszałkowskiego Województwa Warmińsko-Mazurskiego w Olsztynie oraz Urzędu Miasta Poznania, Urzędu Miasta Tychy, Urzędu Miasta Radomia, czy Urzędu Miasta Krakowa. Dostawy były realizowane w ten sposób w latach 2012-2016.

Funkcjonariusze Delegatury CBA w Białymstoku w śledztwie prowadzonym pod nadzorem Prokuratury Okręgowej w Olsztynie, ustalili, iż zatrzymani biznesmeni zgłaszając się do postępowań przetargowych na zakup sprzętu komputerowego prowadzonych przez instytucje państwowe i samorządowe oferowali zestawy komputerowe oraz komputery przenośne wraz z systemem operacyjnym oraz oprogramowaniem biurowym znanej marki, które nie pochodziły z legalnej dystrybucji. Ustalenia CBA dokonane przy współpracy z wytwórcą oprogramowania wskazują, że certyfikaty autentyczności były podrobione, a klucze nielegalnie generowane.

Zatrzymani przez CBA zostaną przewiezieni do prokuratury, gdzie usłyszą zarzuty dotyczące m.in. oszustw w celu wyłudzenia zamówień publicznych. Sprawa nie jest zakończona, niewykluczone kolejne zatrzymania i zarzuty.

Źródło: CBA

Artykuł Oszukiwali i wygrali milionowe przetargi pochodzi z serwisu CRN.

Analitycy Gartnera wyliczają, że firmy mogłyby ograniczyć koszty związane z zakupem oprogramowania nawet o 30 proc, gdyby zoptymalizowały procesy związane z konfiguracją aplikacji i ich licencjonowaniem oraz wdrożyły rozwiązania Software Asset Management, przeznaczone do zarządzania zasobami oprogramowania. Do podobnych wniosków dochodzą eksperci z Deloitte. Ich zdaniem koszty software’u pochłaniają znaczną część budżetów IT, co nie zmienia faktu, że gros przedsiębiorstw bagatelizuje znaczenie umów licencyjnych. Tymczasem odpowiednie zarządzanie aplikacjami umożliwia, w skrajnych przypadkach, zredukowanie wydatków nawet o kilka milionów złotych rocznie.

– W branży IT występuje wiele problemów, ale jedną z kluczowych kwestii jest zarządzanie licencjami, które mają znaczny wpływ na cash flow firmy. Szczególnie dotyczy to przedsiębiorstw dysponujących rozbudowaną infrastrukturą teleinformatyczną. W ich przypadku odnawianie licencji wiąże się z dużymi kosztami, dlatego warto znać ich wartość nawet w skali miesiąca, zaś posiadanie systemu SAM daje taką wiedzę – dodaje Bogdan Lontkowski, dyrektor regionalny Ivanti na Polskę.

Wszystko wskazuje na to, że w nadchodzących latach przedsiębiorcy zmierzą się z mnóstwem wyzwań związanych z inwentaryzacją aplikacji. Przyrastająca w niespotykanym tempie liczba programów, praca w różnych środowiskach (lokalnym, chmurze publicznej czy maszynach wirtualnych), a także nowe modele sprzedaży – komplikują proces zarządzania. Innym niebezpiecznym zjawiskiem są zakupy zasobów informatycznych bez powiadamiania i angażowania komórek IT. Decyzje o instalowaniu nieautoryzowanych aplikacji podejmują zarówno pojedynczy pracownicy, jak i całe działy.

Czas na audyt

Najwięksi producenci oprogramowania, dyktujący warunki na globalnym rynku, dążą do maksymalizacji przychodów, posługując się metodą kija i marchewki. Z jednej strony zachęcają potencjalnych nabywców do zakupu, opowiadając o oszczędnościach wynikających z wdrożenia aplikacji, zaś z drugiej komplikują przepisy licencyjne, aby wydrenować kieszenie klientów.

Największym straszakiem na użytkowników oprogramowania są audyty legalności software’u. Z badań przeprowadzonych przez Gartnera wynika, że 68 proc. przedsiębiorstw spodziewa się w ciągu najbliższych 12 miesięcy kontroli. Procedura trwa przeciętnie 7 miesięcy i zabiera średnio 194 godziny pracy działu IT. Niemniej zdarzają się też dłuższe wizytacje, które w przypadku dużych firm, używających produktów znanych koncernów, mogą się ciągnąć nawet przez półtora roku. To wiąże się z niemałymi kosztami, bowiem trzeba oddelegować pracownika do współpracy z audytorem. Ale dużo bardziej dotkliwe bywają skutki kontroli. Producenci nakładają drakońskie kary zarówno za kradzież aplikacji, jak i niezamierzone błędy, będące następstwem nieprawidłowej konfiguracji lub omyłkowego pozostawienia nieużywanego programu w systemie.

Powszechnie znany jest przypadek firmy ze wschodniej Polski, która zapłaciła milion dolarów kary za korzystanie z oprogramowania bez licencji. Audytorzy na jej komputerach znaleźli ponad 200 nielegalnych aplikacji naruszających prawa autorskie. Nie mniej interesujący jest przykład klienta zza naszej wschodniej granicy.

– Przedsiębiorca wdrożył profesjonalne oprogramowanie SAM po audycie przeprowadzonym przez znanego producenta. Pierwotna kara za używanie nielicencjonowanych aplikacji miała wynieść 3 mln dol., aczkolwiek po długich negocjacjach została zmniejszona do 1,5 mln dol. Nie musieliśmy ich namawiać, aby wdrożyli SAM… – mówi rozmówca CRN Polska, proszący o zachowanie anonimowości.

Wysokie kary finansowe to tylko część kosztów ponoszonych przez firmy. Czasami bardziej bolesna bywa utrata wizerunku, a zła opinia może ciągnąć się za przedsiębiorstwem przez długie lata.

Kto najbardziej powinien obawiać się kontroli? Audytorzy działają podobnie do urzędu skarbowego, szukając nieprawidłowości w średnich oraz dużych firmach dysponujących rozbudowaną infrastrukturą IT. Kontrola tej grupy podmiotów przynosi zazwyczaj obfite żniwa.

– Najwięksi producenci oprogramowania najczęściej biorą na cel duże firmy. W nich łatwiej znaleźć uchybienia ze względu na rozbudowaną infrastrukturą oraz liczbę urządzeń końcowych. Nawet największych gigantów nie stać, aby skrupulatnie sprawdzać firmy, które korzystają z mniej niż 100 komputerów – twierdzi Bogdan Lontkowski.

Chmura przykryje problemy?

W ostatnich latach coraz więcej przedsiębiorstw wybiera oprogramowanie z chmury zamiast tradycyjnego pudełka. Według danych Synergy Research w ostatnim kwartale 2016 r. globalne przychody ze sprzedaży SaaS wzrosły o 32 proc. Analitycy spodziewają się, że najbliższych trzech latach wartość tego segmentu rynku zwiększy się dwukrotnie. Nie brakuje opinii, że SaaS uprości licencjonowanie i ograniczy zastosowanie SAM. Dlaczego? W wielu firmach panuje rozgardiasz i często zapomina się o przedłużeniu licencji.

Czasami przedsiębiorcy znajdujący się w finansowym dołku nie przedłużają umowy i korzystają z nielegalnego oprogramowania. Zupełnie inaczej wygląda to w przypadku SaaS. Firma, która nie opłaca abonamentu, zostaje odcięta od dostępu do usługi. Ponadto odnowienie licencji nie stanowi dużego obciążenia dla firmy ze względu na stosunkowo niewielką opłatę miesięczną, oscylującą zazwyczaj wokół kilkudziesięciu złotych za użytkownika.

– Z informacji pochodzących z Microsoftu wynika, że zwiększenie zainteresowania Office’em 365 powinno przełożyć się na spadek korzystania z nielicencjonowanych produktów. Choć z drugiej strony dystrybucja nielegalnych kluczy licencyjnych w Internecie, zwłaszcza w portalach aukcyjnych, nadal stanowi poważny problem. Wprawdzie dostawcy SaaS zwracają uwagę na inne problemy, jednakże teza, że tego rodzaju rozwiązania sprzyjają zmniejszeniu skali korzystania z nielegalnego oprogramowania, wydaje się słuszna – wyjaśnia Bartłomiej Witucki, BSA Contracted Representative Polska.

Przedsiębiorstwa przenoszące aplikacje do chmury nie zawsze potrafią trafnie oszacować koszty. Niejednokrotnie zdarza się, że firmy przekraczają zaplanowane budżety przeznaczone na korzystanie z usług.

– Przyczyną takich sytuacji jest brak możliwości precyzyjnego oszacowania zapotrzebowania na oprogramowanie. Ale funkcje analityczne oraz optymalizacyjne oferowane przez niektóre systemy SAM umożliwiają przedsiębiorstwom szczegółową ocenę zapotrzebowania na rozwiązania chmurowe – mówi Mateusz Majewski, Sales Manager Poland w Snow Software.

Poza tym, choć SaaS zyskuje popularność, wciąż istnieje liczna grupa firm wiernych pudełkowym aplikacjom. W większości przypadków są to średnie i duże przedsiębiorstwa, dlatego w najbliższych latach klientów na SAM nie powinno zabraknąć.

Doradca klienta

Wielu resellerów oraz integratorów ma w swoim portfolio systemy CRM, ERP czy antywirusy, zaś zdecydowanie rzadziej oferują SAM. Taki stan rzeczy wynika z kilku przyczyn. Potencjalni klienci wykazują umiarkowane zainteresowanie oprogramowaniem do zarządzania zasobami IT, wychodząc z założenia, że posiadają ważne licencje, a drobne uchybienia nie wyjdą na światło dzienne. Jednak dane napływające z BSA przeczą obiegowym sądom. W 2016 r. do BSA wpłynęło 909 zgłoszeń dotyczących przypadków korzystania z nielegalnego oprogramowania – czyli prawie 100 proc. więcej niż rok wcześniej. Warto dodać, że w latach 2012–2016 łączna wysokość odszkodowań, które firmy i osoby prywatne zobowiązały się zapłacić na mocy ugód i wyroków sądowych, wyniosła 10 mln zł.

Powyższe dane muszą robić wrażenie również na integratorach. Część z nich staje przed dylematem: sprzedawać jak najwięcej licencji i tym samym maksymalizować zyski czy stać się doradcą, który dostarczy rozwiązania umożliwiające ograniczenie do minimum bezmyślnych inwestycji? Pierwsza z opcji jest bardziej kusząca i łatwiejsza do realizacji, tym bardziej że SAM nie jest produktem pierwszej potrzeby.

– Nie ukrywam, że przeszkodą w sprzedaży oprogramowania SAM jest budżet, który w przypadku IT jest zawsze za mały i trzeba mocno walczyć, żeby klient chciał przeznaczyć go właśnie na tego typu rozwiązanie. Dyrektor IT w kolejce ma bowiem dziesiątki innych, równie ważnych obszarów do optymalizacji – przyznaje Bartosz Bednarski, dyrektor zarządzający Axence.

Niemniej zmiany zachodzące na rynku powinny zachęcić integratorów do większego wysiłku. W dłuższej perspektywie większość klientów doceni korzyści wynikające z wdrożenia odpowiednich narzędzi. W rezultacie firmy IT nie tylko zarobią na sprzedaży SAM, ale zyskają szansę, żeby przywiązać do siebie klienta. Pozostaje pytanie: gdzie szukać odbiorców?

– Odpowiedź jest stosunkowo prosta: w przedsiębiorstwach posiadających dużą liczbę licencji, stacji roboczych czy rozbudowane serwerownie – podpowiada Bogdan Lontkowski.

Artykuł Licencyjny węzeł gordyjski pochodzi z serwisu CRN.

W dyskusję coraz częściej włączają się też dystrybutorzy, którzy – przynajmniej teoretycznie – powinni być najbardziej poszkodowani wskutek obecnej rewolucji. Pamiętajmy, że wielu usługodawców SaaS współpracuje bezpośrednio z resellerami i wynagradza ich prowizjami za aktywny udział w systemie rekomendacyjnym. Tymczasem dystrybutorzy podkreślają, że rynek usług chmurowych i jego biznesowe reguły dopiero się kształtują, więc na razie nie ma powodu do płaczu.

– Resellerzy są coraz bardziej zainteresowani oprogramowaniem w chmurze, ponieważ oczekują tego od nich klienci. Wiele przedsiębiorstw, z różnych powodów, nie może lub nie chce dokonywać zakupów bezpośrednio przez stronę internetową u usługodawcy. Chcą otrzymać tradycyjną fakturę, zapłacić przelewem i mieć wsparcie w osobie lokalnego dostawcy. Takie podejście charakteryzuje przede wszystkim placówki sektora publicznego – mówi Rafał Goszyk, dyrektor polskiego oddziału Prianto.

Przedstawiciele dystrybutorów wskazują też, że SaaS z pewnością nie wyprze tradycyjnych metod dystrybucji. Przede wszystkim nie dla każdego rodzaju oprogramowania ten model w ogóle ma sens. Ich zdaniem przez długi czas będziemy mieli do czynienia z dużym rozdrobnieniem oferty: równolegle będą proponowane niemalże te same pakiety do instalacji „on-premise”, jak też dostępne w chmurze. Dlatego coraz rzadziej spotykane będzie środowisko homogeniczne.

Według analiz dziś ponad połowa klientów już korzysta z jakiejś usługi chmurowej, ale jednocześnie bardzo niewiele jest firm, które całe swoje środowisko IT opierają wyłącznie na chmurze. Dlatego resellerzy nie muszą obawiać się nagłej zmiany swojej roli – w ich interesie jest, aby transformacja u klientów miała jak najbardziej ewolucyjny charakter.

Trzeba po prostu pogodzić się z faktem, że odbiorcy indywidualni, jeśli tylko zapewni się im taką możliwość, właściwie zawsze będą kupować usługi bezpośrednio od usługodawcy – jedynym kryterium decyzyjnym będzie tu cena. Odbiorcy biznesowi mają większe wymagania, które działają na korzyść resellerów.

Część z nich potrzebuje faktury wystawionej przez polski lub europejski podmiot, są też zainteresowani wsparciem bądź doradztwem ze strony swojego dotychczasowego, zaufanego sprzedawcy. Ratunkiem dla resellerów jest też to, że dzięki modelowi usługowemu praktycznie wyeliminowane jest zjawisko nielegalnego korzystania z oprogramowania – jeśli klient nie zapłaci za usługę, zostanie ona automatycznie zablokowana.

Na co jest popyt?

O tym, jak dostawcy oprogramowania usiłują dostosować się do oczekiwań odbiorców, najłatwiej przekonać się, analizując różne modele jego sprzedaży. Dziś właściwie w niebyt odchodzi zwykła sprzedaż pudełek z nośnikiem i wieczystą licencją – została zastąpiona sprzedażą internetową, z kodami rejestracyjnymi i licencją przesyłaną mailem. Co zatem stoi dzisiaj na sklepowych półkach? Najczęściej właśnie pudełko z jedną kartką papieru, zaś wersję instalacyjną oprogramowania użytkownik musi pobrać samodzielnie ze strony producenta.

Model płatności abonamentowej wiele lat temu spopularyzowały antywirusy. Dzięki ich szybkiej dezaktualizacji użytkownicy zostali przyzwyczajeni do tego, że często obok samego kodu oprogramowania potrzebna jest też jakaś usługa – w tym przypadku jest to opracowanie szczepionki przeciwko nowym wirusom. Na bazie tego doświadczenia firmy próbują dziś pobierać abonamentową opłatę za możliwość korzystania z oprogramowania, które nadal zainstalowane jest na komputerze użytkownika – w tym modelu działają m.in. niektóre aplikacje pakietu Office 365 czy rozwiązanie Adobe Creative Cloud. Dzięki temu klienci nie muszą ponosić jednorazowej wysokiej opłaty związanej z zakupem danego pakietu – nabywają go niejako na kredyt.

Producenci takiego oprogramowania starają się, aby abonamentowe rozliczenie nie było jedyną cechą wspólną z aplikacjami dostępnymi jako usługa wyłącznie przez internetową przeglądarkę. Dlatego w pakiecie zapewniają użytkownikom dodatkową przestrzeń w chmurze, usługi wsparcia, dostęp do społeczności użytkowników, jak i gwarancję zawsze najbardziej aktualnej wersji (o czym za chwilę). Natomiast samo oprogramowanie nadal instalowane jest lokalnie, aby zapewnić możliwość korzystania z niego np. wtedy, gdy nie ma dostępu do Internetu.

Zapomnij o aktualizacjach

Zaletą oprogramowania oferowanego w modelu SaaS przez Internet okazuje się niemalże nieskończona skalowalność, z pewnością wykraczająca poza potrzeby polskich firm. Lepsza jest też komunikacja z dostawcami takich usług. Chętnie wdrażają oni nowe funkcje, często sugerowane przez klientów. Dzięki temu wspomniane oprogramowanie rozwijane jest znacznie szybciej, bo nie ma konieczności przygotowywania „paczki” z aktualizacją, jej dystrybucji i przekonywania użytkowników, żeby ją zainstalowali.

Szybki rozwój oprogramowania w modelu SaaS to ogromna zaleta w porównaniu z aplikacjami tworzonymi przez mniejsze firmy programistyczne. Nie zapewniają one bowiem wsparcia ani aktualizacji przez okres dłuższy niż 2–3 lata od wypuszczenia produktu na rynek albo wstrzymują wydawanie aktualizacji, nawet tych dotyczących bezpieczeństwa, po udostępnieniu nowej „dużej” wersji danego oprogramowania. Przedstawiciele Microsoftu, który w dziedzinie dostępności łatek stanowi przykład godny naśladowania, wielokrotnie podkreślali, że gwarancja ciągłości aktualizacji dla systemów operacyjnych lub oprogramowania mającego więcej niż pięć lat okupiona jest dużym wysiłkiem i wysokim kosztem. Natomiast w przypadku usług chmurowych usługodawca automatycznie bierze na siebie obowiązek ciągłego aktualizowania dostarczanego oprogramowania.

Ale dostęp do nieustannie rozbudowywanej funkcjonalności nie zawsze przekonuje klientów, czego doskonałym przykładem może być pakiet Office 365. Wiele osób korzysta ze starszej, licencjonowanej w tradycyjny sposób wersji Office’a i nowsza im niepotrzebna, jako że i tak nie wykorzystują więcej niż 5–10 proc. jego funkcji. Jedyne, co jest w stanie ich zmusić do zmiany, to wstrzymanie tworzenia łatek bezpieczeństwa. Do obsługi takich klientów trzeba przygotować się w specjalny sposób.

Jak zaprezentować korzyści?

Porównanie – wyłącznie z wykorzystaniem kryterium ceny – oferty oprogramowania licencjonowanego z dostępnym jako usługa prawie zawsze wyjdzie na niekorzyść tego drugiego. Szczególnie jeśli nie uwzględni się dodatkowych kosztów związanych z infrastrukturą potrzebną do funkcjonowania określonego oprogramowania. Usługi są droższe, bo usługodawcy ponoszą znacznie większe koszy niż twórcy zwykłego oprogramowania. Koszty te, siłą rzeczy, muszą zostać zrekompensowane. Dlatego równolegle dostawcy usług starają się zapewnić klientom dodatkowe korzyści, najczęściej niematerialne i trudne do wyceny – więc umiejętne ich zaprezentowanie odbiorcom staje się swego rodzaju sztuką, której arkana resellerzy powinni poznać.

Największą korzyścią dla klientów jest niemartwienie się o problemy z utrzymaniem środowiska IT – nie trzeba inwestować w dodatkowy sprzęt i oprogramowanie, ponosić kosztów energii elektrycznej ani zatrudniać informatyków. Ale jest to jednocześnie największa wada z punktu widzenia resellerów i integratorów, bo właśnie wdrażanie sprzętu i oprogramowania oraz świadczenie usług wsparcia stanowiło ich główne źródło zarobku. Na modelu chmurowym skorzystają głównie mniej doświadczeni sprzedawcy, którzy dzięki usługom mają możliwość kompleksowej obsługi klienta, bez konieczności angażowania (na zasadzie kooperacji) innych firm IT.

Drugą największą zaletą – dla użytkowników – okazuje się bardzo krótki okres od momentu podjęcia decyzji o danym wdrożeniu do uzyskania dostępu do usługi. W przypadku tradycyjnych rozwiązań procedury zakupowe trwają długo, a późniejsze wdrożenie nierzadko wiąże się z różnego typu kłopotami. Usługa chmurowa dostępna jest niemal natychmiast po jej zakupieniu, chociaż w niektórych przypadkach konieczne jest zintegrowanie jej z już posiadanymi przez firmę systemami.

Kolejną zaletą jest coś, co klienci zwykli wskazywać jako wadę: bezpieczeństwo danych. Każda przeprowadzona na chłodno analiza wykazuje, że dane u profesjonalnego dostawcy usług chmurowych będą lepiej chronione (fizycznie i logicznie) niż na serwerze „pod biurkiem prezesa”. W tym przypadku z bezpieczeństwem jest trochę tak jak z lotnictwem. Mimo że samolot jest najbezpieczniejszym środkiem transportu, wiele osób boi się wejść na pokład. Na szczęście w niemal wszystkich przypadkach niesłusznie.

Artykuł Kiedy licencja, kiedy usługa? pochodzi z serwisu CRN.

1. „IT cienia”
Pracownicy często bez wiedzy swoich przełożonych instalują rozmaite aplikacje. Jest ryzyko, że znajdą się wśród niech nielegalne kopie lub użytkownicy zapomną o przedłużeniu licencji. Zwłaszcza w dużej firmie trudno zapanować nad takimi praktykami. Coraz szersze jest zjawisko shadow IT, polegające na tym, że pracownicy firmy kupują usługi informatyczne i oprogramowanie bez wiedzy działu IT.

Rada Firma powinna wdrożyć narzędzia lub mechanizmy kontrolujące zakupy wszystkich działów i placówek terenowych.

2. Brak centralnego repozytorium i zły przepływ komunikacji
Bez centralnego systemu zarządzania licencjami trudno je kontrolować w całej firmie, nie ma do nich łatwego dostępu.

Rada Stworzyć repozytorium, w którym będą gromadzone informacje o licencjach oprogramowania. Umożliwią także ich monitoring, np. śledzenie daty instalacji użytkowania i odnawiania licencji. Centralne repozytorium pomaga też nadrobić brak komunikacji pomiędzy działami, ponieważ system zarządzania licencjami i oprogramowanie „widzi” stan aplikacji we wszystkich jednostkach organizacyjnych.

3. Nieznajomość zmieniających się reguł gry
Zasady licencjonowania ulegają częstym zmianom. Śledzenie na bieżąco przepisów i regulacji przerasta możliwości przeciętnych pracowników.

Rada Wdrożenie specjalistycznego oprogramowania, które pozwoli kontrolować problem. Wiąże się to z dodatkowymi nakładami finansowymi, ale biorąc pod uwagę ewentualne koszty związane z karami czy utratą reputacji, taka inwestycja ma uzasadnienie.

4. Licencjonowanie nie jest częścią zarządzania zasobami IT
Kwestie związane z licencjonowaniem oprogramowania często nie wchodzą w skład kompleksowej strategii zarządzania aktywami IT.

Rada Skuteczne narzędzia do kontroli licencjonowania powinny obejmować wszystkie aplikacje używane na dowolnym urządzeniu. To ułatwia pracę administratorom, którzy w ten sposób zyskują kompleksową wiedzą na temat sprzętu i oprogramowania pracującego w organizacji.

Artykuł 4 problemy z zarządzaniem licencjami pochodzi z serwisu CRN.

Zwłaszcza klienci, którzy korzystają obecnie z kilku licencji Standard na jednym serwerze, po wprowadzeniu nowych zasad mogą być skłonni do aktualizacji do edycji Datacenter. Obecnie wielu z nich używa kilku serwerów z wielordzeniowymi procesorami, co pozwala im ograniczyć koszty standardowej licencji. Oprócz ryzyka zwiększenia kosztów problemem dla klientów może być właściwe ustalenie liczby licencji potrzebnych w nowym modelu sprzedaży.

W ocenie ekspertów po wprowadzeniu wcześniej licencjonowania na rdzeń w SQL Server znacznie zwiększyły się koszty dla wielu klientów. Licencje na rdzeń zostaną wprowadzone także w System Center 2016.

Z kolei z punktu widzenia Microsoftu taki model pozwala lepiej zmonetyzować rosnące zapotrzebowanie na moc obliczeniową serwerów.

Wraz z wprowadzeniem Windows Server 2016 edycja Datacenter zyska nowe funkcje, obejmujące pracę w sieci, bezpieczeństwo i SDN. Obecnie główna różnica między wyższą a niższą wersją systemu polega na tym, że w Datacenter nie ma limitu wirtualnych instancji systemu.

Artykuł Microsoft zmieni licencje Windows Server pochodzi z serwisu CRN.

Licencje OSS/FS: modyfikowanie składników oprogramowania

Jeśli nowy program powstał na bazie oprogramowania na licencji OS/FSS, to w szczególnych przypadkach, gdy przeróbki są istotne, nieszablonowe i oryginalne, modyfikacja taka może być uznana za tzw. opracowanie. Innymi słowy byłby to utwór zależny w rozumieniu art. 2 ustawy o prawie autorskim i prawach pokrewnych, czyli wprawdzie odrębny od pierwowzoru, lecz niesamoistny program komputerowy.

Generalnie licencje OSS/FS gwarantują licencjobiorcy uzyskanie wszystkich praw, które są wymagane przez polskie prawo autorskie w zakresie dokonywania modyfikacji programów komputerowych i wykorzystywania zmodyfikowanego programu.

Dotyczy to po pierwsze zgody podmiotu uprawnionego – z tytułu majątkowych praw autorskich – na dokonywanie jakichkolwiek zmian w programie. Po drugie zaś w przypadku, gdy zmiany te mają charakter twórczy i prowadzą do powstania utworu zależnego, np. w postaci nowej aplikacji czy systemu, informatyk (bądź firma IT uprawniona z tytułu majątkowych praw autorskich) uzyskuje zezwolenie twórcy pierwotnego programu komputerowego na korzystanie z własnych praw autorskich do nowego opracowania. Warto przy tym podkreślić, że ponieważ z przyczyn technicznych dokonywanie jakiejkolwiek zmiany oprogramowania zawsze wiąże się z koniecznością jego zwielokrotnienia, choćby tylko tymczasowego (np. w pamięci operacyjnej), konieczne jest uzyskanie stosownych uprawnień także i na tym polu eksploatacji. Licencje OSS/FS zapewniają twórcy komfort również pod tym względem.

Uzyskanie takich uprawnień wiąże się jednak niekiedy z dodatkowymi ograniczeniami. Najistotniejszym z nich jest tzw. klauzula copyleft, która zobowiązuje licencjobiorcę do udostępniania zmodyfikowanego programu wyłącznie na tej samej licencji, na której rozpowszechniany jest utwór pierwotny (program wyjściowy). W praktyce oznacza to zatem, że wykonawca oferujący system, którego składniki stanowią twórczość zależną w stosunku do wolnego oprogramowania, nie jest władny przenieść na zamawiającego majątkowych praw autorskich do takiego składnika systemu lub też udzielić mu licencji innej aniżeli analogiczna licencja OSS/FS. W ten sposób kształtują uprawnienia licencjobiorców klasyczne licencje OSS/FS, np. GNU GPL lub GNU LGPL. Odmienne, zdecydowanie mniej restrykcyjne postanowienia obejmują licencje typu BSD, gdyż nie zawierają one klauzuli copyleft.

Natomiast w przypadku dokonania zmian programu niemających cech twórczych będziemy mieli do czynienia cały czas z tym samym programem, a zatem licencjobiorca nie nabędzie praw autorskich do takiej przeróbki i zakres jego uprawnień będzie w dalszym ciągu kształtowany wyłącznie przez treść licencji.

Integracja OSS/FS z innym oprogramowaniem

Oprócz wskazanego powyżej wykorzystywania składników oprogramowania rozpowszechnianego na licencjach typu OSS/FS w systemach informatycznych, w wersji zmodyfikowanej możemy mieć również do czynienia z wykorzystaniem go poprzez połączenie z innym softwarem, np. komercyjnym. Nowo powstały program najczęściej przejmuje całość lub istotne fragmenty pierwowzoru, samemu nosząc znamiona twórczości. Będzie więc stanowił w kategoriach prawa autorskiego tzw. opracowanie (utwór zależny). Jeżeli natomiast dodane fragmenty nie będą twórcze i jednocześnie będą miały marginalne znaczenie (tak ilościowe, jak i jakościowe, np. nie powstaną żadne nowe funkcjonalności), to nie dojdzie do stworzenia nowej kategorii utworu. Taki „rozwinięty” program należy traktować jako tożsamy z oryginałem.

Z technicznego punktu widzenia problem integrowania oprogramowania jest jednym z najważniejszych w odniesieniu do programów typu OSS/FS. Rygorystyczne postanowienia klauzuli copyleft nakazują bowiem udoskonalony program komputerowy traktować jako opracowanie, które może być udostępniane wyłącznie na tej samej licencji, na której rozpowszechniany jest utwór pierwotny.

Rekomendacje prezesa UZP

Tymczasem zdaniem prezesa Urzędu Zamówień Publicznych warunkiem konkurencyjności w przypadku projektów dotyczących systemów IT jest zapewnienie sobie przez zamawiających pełni uprawnień z tytułu majątkowych praw autorskich do oprogramowania wchodzącego w skład wdrażanego systemu informatycznego. Tak, aby jego ewentualnym rozwojem i/lub utrzymaniem mógł zajmować się także podmiot inny niż pierwotny wykonawca (rekomendacje prezesa UZP dotyczące udzielania zamówień publicznych na systemy informatyczne z 2009 r.).

A zatem dla osiągnięcia powyższych celów kluczowe jest uzyskanie przez zamawiającego prawa do modyfikacji oraz wykorzystywania modyfikacji (praw zależnych) programów komputerowych. Prawo to można uzyskać od wykonawcy zarówno w ramach procedury przeniesienia autorskich praw majątkowych, jak i uzyskania stosownej licencji. Jeżeli wykonawca posłuży się oprogramowaniem OSS/FS z klauzulą copyleft, to zamawiający będzie mógł wyłącznie liczyć na taką samą licencję jak ta, na podstawie której wykonawca uzyskał prawo do zmodyfikowania oprogramowania stanowiącego podstawę do stworzenia systemu IT na potrzeby zamawiającego. Trzeba sobie z tego zdawać sprawę i każdorazowo przeanalizować oferty wykonawców pod tym właśnie kątem.

Dr Piotr Wasilewski jest adwokatem, a Bartosz Jussak aplikantem radcowskim w Kancelarii Prawnej Traple Konarski Podrecki i Wspólnicy.

Artykuł Open source w zamówieniach publicznych pochodzi z serwisu CRN.

Microsoft dąży do współpracy z największymi graczami na rynku, co ma zapewnić większą dostępność jego produktów. W br. zrezygnował z procesowania się o patenty z Samsungiem, podpisując umowę obejmującą m.in. instalacje Office’a w urządzeniach tej marki. W ub. tygodniu zawarł natomiast patentową ugodę z Google’m.

Artykuł Microsoft i Asus zacieśnią współpracę pochodzi z serwisu CRN.