Skip to main content
Version: 7.x

Licencja | Open Source

Pisząc licencję YetiForce naszym priorytetem było stworzenie licencji, która nie tylko jest przejrzysta i łatwa do zrozumienia, bez zawiłych zapisów i niejasności, ale również takiej, która nie będzie tworzyła niepotrzebnych ograniczeń w firmach, które zdecydowały się na wybór YetiForce.

Treść Licencji oraz wszystkie dotychczasowe wersje Licencji znajdziesz:

Co to jest licencja?​

Licencja jest to upoważnienie do korzystania z czyjegoś dobra niematerialnego [np. oprogramowania]. Niezależnie od rodzaju licencji, należy pamiętać, że licencja zawiera istotne informacje o naszych prawach i obowiązkach.

Zawsze czytaj licencje!​

Od strony biznesowej, każda licencja to rodzaj umowy, na którą się zgadzamy, co oznacza w praktyce, że nienależyte wykonanie umowy, wiąże się z odpowiedzialnością cywilną a w niektórych przypadkach również odpowiedzialnością karną. Dlatego zawsze czytajmy licencję, a w przypadku wątpliwości skonsultujmy je z prawnikiem.

Mniej znaczy lepiej!​

W praktyce im krótsza licencja tym lepsza [zasada sprawdza się w 99% przypadków i dotyczy strony, która korzysta z licencji], wynika to z faktu, że licencja zawsze służy ograniczaniu praw i narzucania określonych zasad. Jeżeli masz przed sobą długą licencję, której nie rozumiesz, to najczęściej jest to działanie celowe, w którym właściciel praw chce "ukryć" pewne zapisy korzystne dla siebie.Bardzo dobrym przykładem licencji są licencje MIT oraz BSD (3-Clause).

Wyjątek od tej reguły stanowi brak licencji lub licencja, która niejasno opisuje przyznanie praw lub zrzeczenia się gwarancji [np. WTFPL]. Takie licencje odradzamy [pomimo, że są bardzo krótkie], ponieważ stanowią spore ryzyko na tle prawnym.

Co to jest open source?​

Otwarte oprogramowanie jest to licencja na mocy której właściciel praw autorskich przyznaje użytkownikom prawa do badania, zmiany i rozpowszechniania oprogramowania w ramach licencji wolnego oprogramowania.

Open source w praktyce​

W internecie występuje wiele definicji otwartego oprogramowania [open source], a do najbardziej powszechnych można zaliczyć tą opublikowaną przez OSI https://opensource.org/osd. Od strony biznesowej, otwarte oprogramowanie daje z reguły znacznie większe możliwości rozbudowy i rozwoju niż oprogramowanie zamknięte.

Główną ideą towarzyszącą otwartemu oprogramowaniu jest możliwość używania, modyfikowania i rozpowszechniania oprogramowania co oznacza większą swobodę biznesową dla użytkowników. Chociaż licencji otwartych jest bardzo dużo i niektóre licencję są dyskusyjne od strony biznesowej, to najczęściej stanowią lepszą alternatywę niż oprogramowanie zamknięte.

Czy każda licencja open source jest dobra dla mojego biznesu?​

Należy pamiętać, że przed podjęciem wyboru oprogramowania należy szczegółowo zapoznać się z jego licencją. To, że oprogramowanie jest przez kogoś opisane jako open source, nie oznacza, że jest najlepszym wyborem dla danej organizacji.

Z perspektywy producenta oprogramowania​

Jeżeli tworzysz oprogramowanie i chcesz korzystać z dobrodziejstw open source, wówczas najlepszym wyborem mogą być licencje liberalne, które nie narzucają zasad copyleft [np. MIT, BSD 3] a jednocześnie mogą być łączone z innymi licencjami w bardzo obszernym zakresie. A jeżeli chcesz, swoje oprogramowanie mocno chronić biznesowo [np. stosując zasadę copyleft], wówczas lepszym rozwiązaniem może być licencja GPL v3 [General Public License v 3].

Z perspektywy użytkownika oprogramowania​

Dla użytkownika końcowego, prawie zawsze najlepszym wyborem będą licencje liberalne tj. MIT, BSD, Apache License, LGPL. Licencje liberalne oznaczają dużą wolność i swobodę w działaniu, której warto sobie nie ograniczać i nie narażać się na ryzyku "złamania" warunków licencji.

Co to jest kod źródłowy?​

Najważniejszą zaletą oprogramowania otwartego jest dostęp do kodu źródłowego aplikacji, co w praktyce oznacza, że mamy dostęp do kodu, który jest wynikiem pracy programisty.

Co nam daje dostęp do kodu źródłowego i jego modyfikacja?​

Dostęp do kodu źródłowego w połączeniu z jego dowolną modyfikacją, daje organizacji nieograniczone możliwości dostosowania aplikacji do procesów. Jednocześnie wszystkie środki i czas zainwestowany w oprogramowanie zostaną w firmie i zmiana dostawcy rozwiązania czy też wewnętrznego zespołu wdrożeniowego nie wpłynie na wartość dodaną, którą dostarcza oprogramowanie.

Mając dostęp do kodu źródłowego, możemy automatyzować bezpieczeństwo [wykonując analizę statyczną kodu] czy też wykonywać pełen audyt bezpieczeństwa zgodnie z OWASP ASVS, który nie byłby możliwy, gdybyśmy nie mogli przeglądać kodu aplikacji.

Open source według YetiForce​

Stworzyliśmy niesamowity produkt rozpowszechniany jako otwarte oprogramowanie, które daje nieograniczone możliwości dla biznesu. Poznaj zalety licencji YetiForce Public License 5.0 i wykorzystaj ją w organizacji.

Dlaczego YetiForce stworzył własną licencję?​

Spośród wszystkich licencji open source, nie znaleźliśmy żadnej, która spełni dwa najważniejsze założenia:

  1. Da nieograniczone możliwości użytkownikowi końcowemu.
  2. Będzie chronić i popularyzować YetiForce.

Pomimo, że są licencje, które w pełni realizują punkt 1, to jest niewiele licencji, które właściwie spełniają punkt drugi naszych założeń. W szczególności, że licencja ma chronić YetiForce w taki sposób, aby bardziej opłacało się rozbudowywać oprogramowanie z nami, niż tworzyć kolejne fork-i oprogramowania. Pisząc "chronić" mamy na myśli niepotrzebne fork-owanie projektu i dzielenie społeczności.

Aby lepiej zrozumieć problem opiszemy to na przykładzie najpopularniejszych licencji:

  • MIT & BSD - są to bardzo dobre licencje liberalne, ale w żaden sposób nie chronią produktu i marki tzn. w każdej chwili inny producent może wykorzystać całą pracę włożoną w YetiForce i udostępniać ją pod inną marką bez żadnych korzyści dla społeczności i produktu YetiForce.
  • GPL & LGPL - są to bardzo dobre licencje, które w sposób prawidłowy chronią produkt pod kątem rozpowszechniania i tworzenia rozwidleń, ale wprowadzają zasadę "copyleft", która nie jest mile widziana w wielu organizacjach. Jednocześnie licencje te, zbyt słabo chronią markę YetiForce.
  • AGPL - jest to licencja bardzo problematyczna prawnie, oprócz wad i zalet opisanych w sekcji GPL & LGPL dochodzi problem z momentem w których dochodzi do "rozpowszechnienia" oprogramowania, dlatego wiele dużych organizacji całkowicie zakazuje używania oprogramowania na tej licencji.
  • OSL - tak jak w przypadku licencji GPL & LGPL mamy tutaj niewystarczającą ochronę marki YetiForce a dodatkowo problem z dotrzymywaniem zasad zapisanych w licencji, powoduje, że licencja ta jest wysokiego ryzyka i nie powinna być używane przez producentów oprogramowania [w/w ryzyka nie dotyczą użytkowników, którzy korzystają z oprogramowania na tej licencji].

Licencja YetiForce YFPL​

Poniżej znajduje się treść licencji, którą stworzyliśmy aby dostarczać otwarte oprogramowanie klasy enterprise dla najbardziej wymagających organizacji:

https://github.com/YetiForceCompany/YetiForceCRM/blob/developer/licenses/LicenseEN.txt

Różnica pomiędzy YFPL a licencją MIT​

Licencja MIT jest uznawana za jedną z najbardziej liberalnych licencji na świecie, akceptowana i wdrażana w dowolnej wielkości organizacji. Dlatego naszą licencję YFPL oparliśmy właśnie na licencji MIT dodając w niej dwa dodatkowe punkty, które pozwolą lepiej chronić markę YetiForce i popularyzować produkt na całym świecie.

  1. W naszej licencji dodaliśmy zapis, wymuszający zarejestrowanie produktu [dzięki temu, wiemy kto korzysta z oprogramowania i w którym kierunku powinniśmy je rozwijać]. W samej rejestracji podajemy tylko dane publiczne [np. w przypadku firm jest to nazwa firmy, adres, kraj, wielkość organizacji], a dane te mogą być opublikowane na stronie WWW producenta [np. lista firm używających YetiForce].
  2. Nie można usunąć stopki, w której zawarte są informacje o producencie oprogramowania i stanowią w pewnym sensie promocję marki tzn. pracownicy firm, którzy korzystają z oprogramowania widzą informacje kto jest producentem.

YetiForce dopuszcza możliwość zmiany licencji [usunięcia lub dodania zapisów licencji lub zmiany na inną licencję], ale każdorazowo wymaga to podpisania porozumienia pomiędzy stronami.

Korzystanie z licencji w praktyce​

Dwa ograniczenia, które dodaliśmy nie wpływają na otwartość rozwiązania dla biznesu. Możesz dowolnie zmieniać system bez żadnych ograniczeń [musisz zachować tylko stopkę w niezmienionej formie, ale możesz ją dostosować kolorystycznie lub możesz ją wyłączyć odpłatnie z perspektywy aplikacji w Marketplace].

Ograniczenia, które dodaliśmy przede wszystkim chronią nasz produkt i markę przed niekorzystnym dla społeczności rozwidlaniem projektu na mniejsze. Chcemy wspólnie z innymi tworzyć jeden system, aby móc konkurować z dużymi projektami, które nie są rozwiązaniami otwartymi.

Czy YetiForce może być rozpowszechniany na innej licencji?​

Tak, ale każdorazowo wymagane jest podpisanie z firmą YetiForce oddzielnej umowy określającej nowe warunki licencyjne dla oprogramowania. Zmiana zapisów licencji lub zmiana na inną licencję np. MIT musi być podyktowana korzyścią biznesową dla społeczności YetiForce lub dla marki YetiForce.

Kod źródłowy systemu YetiForce​

Aktualnie wszystkie produkty rozpowszechniane przez YetiForce są na licencjach otwartych, czyli dają dostęp do kodu źródłowego, który można przeglądać, kopiować, modyfikować i rozpowszechniać.

Kod źródłowy systemu YetiForce​

Oprogramowanie YetiForce, które jest rozpowszechniane na licencji YetiForce Public License 5.0 pozwala na dowolne przeglądanie, kopiowanie, modyfikowanie i rozpowszechnianie kodu źródłowego [ograniczenie stanowi modyfikacja stopki, co zostało opisane w licencji i w artykule "Open source według YetiForce"].

W praktyce możesz zmieniać i dopasowywać system YetiForce, łączyć z innymi systemami, usuwać z niego niepotrzebne funkcjonalności czy też dopisywać dowolne nowe funkcjonalności i nie potrzebujesz na to zgody. Licencja YetiForce jest bardzo liberalna i można ją porównać do innych liberalnych licencji tj. MIT, BSD, MPL 1.1.

Kod źródłowy bibliotek zależnych​

Należy pamiętać, że oprogramowanie YetiForce tak samo jak każde inne oprogramowanie na świecie wykorzystuje biblioteki zależne. Bardzo starannie uporządkowaliśmy i wybraliśmy biblioteki, które pozwalają na dostęp do kodu źródłowego oraz umożliwiają zbliżoną swobodę w przeglądaniu, kopiowaniu, modyfikowaniu i rozpowszechnianiu kodu źródłowego. Każda istniejąca biblioteka użyta w projekcie nazywa się biblioteką zależną. Od strony praktycznej, każda biblioteka zależna również może wymagać innych bibliotek i wówczas zależności te mogą rodzić konflikty. Należy jednak pamiętać, że każda biblioteka ma własną licencję i zawsze należy się z nią zapoznać. Poniżej zebraliśmy licencje bibliotek zewnętrznych, które użyliśmy w systemie YetiForce.

  • Apache-2.0 - 11 bibliotek
  • BSD 2 i 3 - 20 bibliotek
  • CC-BY-4.0 - zestaw dźwięków
  • ISC - 5 bibliotek
  • MIT - 148 bibliotek
  • MPL 1.1 - 1 biblioteka
  • SPL 1.1.2 - kilkanaście plików - biblioteka tożsama z MPL 1.1.
  • VPL 1.1 - kilkaset plików - biblioteka tożsama z MPL 1.1.

Wszystkie powyższe biblioteki są bardzo liberalne i pozwalają na nieograniczone możliwości w przeglądaniu, kopiowaniu, modyfikacji i rozpowszechnianiu kodu. Oprócz bibliotek powyżej, system YetiForce wykorzystuje 7 bibliotek na licencjach LGPL i są to odpowiednio:

  • ckeditor/ckeditor
  • ezyang/htmlpurifier
  • globalcitizen/php-iban
  • milon/barcode
  • phenx/php-font-lib
  • phpmailer/phpmailer
  • smarty/smarty

i chociaż w/w biblioteki są na licencji LGPL, które w pewnych sytuacjach mogą narzucać copyleft, to zostały tak użyte, aby nie było żadnych wątpliwości co do konieczności zastosowania copyleft w projekcie a więc nie wpływają one negatywnie [czyli nie ma zastosowania copyleft] na cały projekt.

Jak wyeliminować konflikty zależności?​

Na wczesnym etapie projektu, gdy cały kod odziedziczyliśmy po wykonaniu rozwidlenia projektu napotkaliśmy problem zależności [tzn. istniało wiele tych samych bibliotek w różnych wersjach], przez co trudno było określić ile bibliotek znajduje się w systemie i ile z nich wymaga aktualizacji. Pierwszym krokiem było stworzenie miejsca, w którym każda biblioteka jest wpisana [ze względu na różne technologie wykorzystywane w systemie, mamy 3 główne pliki]:

  • yarn.lock - zawiera spis wszystkich używanych bibliotek JS.
  • composer.lock - zawiera spis wszystkich używanych bibliotek PHP
  • package.json - domyślne repozytorium bibliotek PHP

Gdy wszystkie biblioteki zostały uporządkowane należało uaktualnić je do najnowszej stabilnej wersji i poprawić kod, który był kompatybilny tylko ze starszymi wersjami bibliotek. Jeżeli jakaś biblioteka została porzucona przez producenta, wówczas została zastąpiona inną rozwijaną biblioteką o podobnej funkcjonalności.

Weryfikacja bibliotek pod kątem licencji​

Gdy wszystkie biblioteki zostały uaktualnione i uporządkowane wykonaliśmy przegląd ich zgodności ze standardami narzuconymi w projekcie. W ten sposób zostały wyeliminowane wszystkie niezgodne biblioteki ze względu na:

  • brak informacji o właścicielu praw majątkowych
  • brak informacji o licencji
  • licencja nie była już rozwijana
  • licencja wymuszała "copyleft" na projekcie lub nie była kompatybilna z innymi licencjami np. biblioteki na licencji gpl/agpl/osl.

Zmiana biblioteki zależnej na inną​

Jeżeli z jakiegoś powodu organizacja nie chce korzystać z konkretnej biblioteki, wówczas można tą bibliotekę zastąpić dowolną inną biblioteką lub zespół programistyczny może napisać własne rozwiązanie na dowolnej licencji, które zastąpi usuniętą bibliotekę. W naszej opinii wszystkie biblioteki zostały dopasowane bardzo optymalnie pod kątem biznesowym, aby nie narzucać żadnych dodatkowych restrykcji na organizację, które chce dowolnie rozwijać system YetiForce.

Lista bibliotek zależnych​

Aktualnie w systemie YetiForce jest około 200 różnych bibliotek zależnych. Aby lepiej kontrolować biblioteki używane w aplikacji, w panelu konfiguracyjnym zostało przygotowane zestawienie wszystkich użytych bibliotek z informacją o:

  • nazwa biblioteki
  • wersja biblioteki
  • nazwa licencji
  • treść licencji

Licencje można sprawdzić również na wersji publicznej dostępnej tutaj: https://gitdeveloper.yetiforce.com/ (jest to wersja developerskie i co jakiś czas może nie być dostępna) w zakładce: Konfiguracja systemu → O aplikacji → Licencje jak również bezpośrednio pod linkiem https://gitdeveloper.yetiforce.com/index.php?module=Vtiger&view=Credits&parent=Settings dostępnym po zalogowaniu [aby się zalogować, nie trzeba znać danych do logowania, są uzupełniane automatycznie].

Przekazanie autorskich praw majątkowych​

Licencja YetiForce nie ogranicza w żaden sposób przekazywania autorskich praw majątkowych dla zmian, które zostały wprowadzone przez osoby, firmy, producenta czy też partnerów.

Czym jest przekazanie autorskich praw majątkowych?​

Umowa o przeniesienie autorskich praw majątkowych jest trochę jak umowa na sprzedaż samochodu. Po jej podpisaniu jedyną osobą uprawnioną do korzystania z utworu staje się nabywca. Pierwotny uprawniony po jej podpisaniu traci wskazane w umowie prawa majątkowe i nie może z nich korzystać. W praktyce oznacza to, że autor wprowadzonych zmian, może samemu decydować co się dzieje z jego kodem, ponieważ licencja YetiForce w żaden sposób nie wymusza stosowania zasady "copyleft".

Zawsze należy pamiętać, że o ile mamy dowolność co do przekazywania praw dla swojego kodu o tyle szczególną uwagę należy zwrócić w przypadku modyfikacji niektórych bibliotek np. bibliotek na licencji LGPL/GPL/AGPL/OSL, ponieważ mogą one wymuszać dla zmian, które w tych bibliotekach zostały wprowadzone, pozostawienia licencji tej samej, na której jest biblioteka,

Dla jakich funkcjonalności warto przekazać autorskie prawa majątkowe?​

Wszystkie zmiany, które nie wydają się istotne z perspektywy ochrony praw własności klienta oraz nie naruszają jego know-how powinny pozostać na licencji producenta oprogramowania. W szczególności dotyczy to zmian, które rozbudowują istniejące funkcjonalności [dla przykładu: rozbudowanie wyszukiwarki wbudowanej w system]. Jeżeli zostaną przekazane prawa do rozbudowanej wyszukiwarki, wówczas nowe wersje systemu nie będą zawierały tej zmiany, co w praktyce będzie powodowało następujące problemy:

  • utrudniona aktualizacja podstawowych funkcjonalności systemu;
  • ponowne pisanie podobnego kodu razem z rozwojem funkcjonalności przez producenta a co za tym idzie, będzie dochodzić do konfliktów kodu pomiędzy tym co znajduje się w aplikacji, a tym co posiada klient;
  • kod, do którego praw nie ma producent najczęściej jest nierozwijany przez klienta, a więc szybciej powstaje dług technologiczny;
  • wyższe koszty utrzymania i rozwoju;

Przekazywanie autorskich praw majątkowych z perspektywy producenta​

Producent oprogramowania YetiForce może przekazać autorskie prawa majątkowe dla każdego nowego utworu, który jest realizowany na zamówienie klienta lub partnera o ile zostało to opisane w zamówieniu i zaakceptowane przez Strony.

Przekazywanie autorskich praw majątkowych z perspektywy partnera​

Partner YetiForce Integrator może przekazać autorskie prawa majątkowe dla każdego nowego kodu wytworzonego przez Producenta na rzecz Partnera, który jest realizowany na zamówienie klienta o ile zostało to opisane w zamówieniu i zaakceptowane przez Strony.

Zmiana licencji a współtwórcy​

Każda osoba współtworząca oprogramowanie YetiForce spoza naszej organizacji musi podpisać umowę CLA, która określa zasady na jakich współtworzony kod jest rozpowszechniany.

Co to jest umowa CLA​

Umowa CLA [Contributor License Agreement] czyli umowa licencyjna współautora określa szczegółowe zasady, na jakich współtwórca oprogramowania zgadza się na rozpowszechnianie swojego utworu. Licencja ta chroni nie tylko YetiForce przed odpowiedzialnością za kod współtwórcy, ale również samego współtwórce.

Zarys umowy CLA​

Poniżej znajduje się najważniejszy wycinek licencji pomiędzy YetiForce a współtwórcami oprogramowania.

  1. Udzielenie licencji prawa autorskiego

    Wszystko co tworzysz dla YetiForce S.A. jest na najnowszej licencji YetiForce Public License [licencja jest opublikowana na stronie https://yetiforce.com], która upoważnia do dalszego wykorzystywania i rozpowszechniania Twojego wkładu.

  2. Udzielenie licencji patentowej

    Poprzez każdy Twój wkład w tworzenie systemu YetiForce, udzielasz także licencji patentowej spółce YetiForce S.A., a także odbiorcom oprogramowania. Daje to możliwość dalszego rozwoju, użytkowania i przekazywania Twojego wkładu, a tym samym nie pociąga spółki YetiForce do odpowiedzialności, jeśli jakikolwiek podmiot wytoczy przeciwko Tobie proces sądowy dotyczący patentu.

  3. Oświadczasz, że masz prawo do udzielenia powyższej licencji.

    W przypadku jeśli Twój pracodawca ma jakiekolwiek prawo do Twojego wkładu, to powinieneś uzyskać jego zgodę na współtworzenie w jego imieniu, a on powinien zrezygnować z prawa do Twojego wkładu na rzecz YetiForce S.A. Podpisując niniejszą umowę oświadczasz, że uzyskałeś takową zgodę od swojego pracodawcy.

  4. Oświadczasz, że każdy Twój wkład jest Twojego autorstwa.

    Zaświadczasz, że Twój wkład jest wynikiem własnej twórczości i nie narusza praw autorskich innych osób. W przypadku chęci złożenia wkładu, który nie jest Twojego autorstwa, możesz przesłać go do YetiForce S.A. podając źródło, oraz wszelkie informacje dotyczące licencji.

  5. Nie jesteś zobowiązany do udzielania wsparcia dla Twojego wkładu, poza zakresem, w jakim chcesz takiego wsparcia udzielać.

    Twój wkład dostarczany jest na zasadzie „tak jak jest” co oznacza, że nie oferujesz dla niego żadnych gwarancji. Możesz natomiast udzielać dla niego wsparcia darmowego, odpłatnego, lub nie udzielać wsparcia wcale. Zobowiązujesz się powiadomić YetiForce S.A. o wszelkich faktach lub okolicznościach, przez które powyższe oświadczenia mogą stać się niedokładne w jakimkolwiek zakresie.

  6. YetiForce S.A. może zastrzec, że niektóre funkcjonalności nie będą publikowane na licencji YetiForce Public License i zostaną wydane na innej licencji i/lub przekazane zostaną firmie trzeciej, wówczas YetiForce poinformuje o tym fakcie współautora przed realizacją funkcjonalności i przekaże szczegółowe zasady związane z licencją i zasadami przekazywania kodu źródłowego funkcjonalności.

Zmiana licencji YetiForce​

Raz na jakiś czas modyfikujemy licencję, aby była jeszcze bardziej przyjazna biznesowi a w wyjątkowych sytuacjach podpisujemy z klientami umowy, które udostępniają system YetiForce na innej licencji. Umowy CLA, które podpisujemy ze wszystkimi współtwórcami pozwalają nam dopasowanie się do rzeczywistych potrzeb dużych przedsiębiorstw a jednocześnie są wyznacznikiem dojrzałości i świadomości w zakresie licencjonowania projektów otwartych.

Zalety otwartego oprogramowania​

Oprogramowanie open source jest idealnym wyborem dla organizacji, które oczekują czegoś więcej niż standardowe rozwiązania, sprawdź kluczowe zalety idealne dla każdego biznesu.

Rzeczywiste zalety otwartego oprogramowania​

Bardzo trudno jest znaleźć materiały, które w sposób rzetelny opisałby zalety i wady rozwiązań open source. Nie wiemy czy wynika to ze złego pojmowania tym czym jest otwarte oprogramowanie czy też mylenie open source z podejście producenta, które może być różne i zaprzeczać standardom. Poniżej opisaliśmy tylko rzeczywiste zalety otwartego oprogramowania i dodaliśmy nasz komentarz dlaczego tak uważamy.

1. Dostęp do kodu źródłowego​

Jest to jedyna zaleta co do której nikt nie ma wątpliwości, a zarazem jest też najważniejszą zaletą związaną z otwartym oprogramowaniem. Dostęp do kodu źródłowego otwiera wiele możliwości [które zostały opisane poniżej].

2. Możliwość weryfikacji poziomu bezpieczeństwa aplikacji​

Otwarte oprogramowanie samo w sobie nie sprawia, że aplikacja będzie bezpieczniejsza. To, że rozwiązanie jest używane przez tysiące firm na świecie nie oznacza, że ktokolwiek zweryfikował czy nie ma w aplikacji błędów i czy aplikacja jest bezpiecznie zaprojektowana [gdyby tak było, to projekty takie jak Wordpress, nie ujrzałyby światła dziennego]. Bezpieczeństwo jest procesem, a więc firma która rozwija dane oprogramowanie musi mieć w swoim DNA bezpieczeństwo ustawione na najwyższym priorytecie. Większość aplikacji [niezależnie czy mówimy o otwartym czy zamkniętym oprogramowaniu] zawiera wiele błędów, które nie są łatane przez producentów pomimo, że ich wykrycie jest bardzo proste i nie wymaga czasu.

To co jest rzeczywistą zaletą open source w zakresie bezpieczeństwa, to możliwość weryfikacji na ile producent stosuje się do standardów [jakość kodu, architektura aplikacji, aktualność bibliotek zależnych, czas reakcji].

Otwarte oprogramowanie a PZP​

Wdrażanie rozwiązań open source jest co raz bardziej popularne, ze względu na swobodę biznesową oraz oszczędności licencyjne, które można uzyskać w porównaniu do drogich rozwiązań własnościowych.

Co to jest PZP?​

Prawo zamówień publicznych to polska ustawa regulująca kwestie prawne związane z zamówieniami publicznymi. Podmioty zobowiązane do stosowania procedur zamówień publicznych zostały wymienione w art. 3 Ustawy Prawo Zamówień Publicznych a w dwóch kolejnych artykułach (art.4, art. 4b, 4d) określono wyłączenia i ograniczenia w stosowaniu tychże przepisów. Wszystko co warto wiedzieć o PZP można znaleźć m.in. na stronie https://www.biznes.gov.pl/.

Czy open source podlega PZP?​

Należy pamiętać, że PZP dotyczy tylko i wyłącznie sytuacji, w których zamawiający ma otrzymać oprogramowanie odpłatnie! Jeżeli wdrażane oprogramowanie nie wymaga żadnych opłat [jest bezpłatne] wówczas nie ma konieczności stosowania przepisów PZP. Dobrym przykładem biznesowym są przeglądarki www [Google Chrome, Microsoft Edge, Mozilla Firefox, Opera], gdzie korzystają z nich miliony firm i nikt nic nie płaci jak również nie są tworzone pod nie przetargi. To co jest tutaj kluczowe, to samodzielne wdrożenie oprogramowania [co najczęściej sprowadza się do pobrania i jego zainstalowania].

Jeżeli rozwiązanie open source wymaga opłat licencyjnych wówczas licencje na to oprogramowanie podlegają prawu PZP. Podobną sytuację mamy w przypadku zamawiania produktu, którego składową są licencje, wdrożenie, oprogramowanie - wówczas pomimo tego, że niektóre elementy mogą być bezpłatne to sam produkt [jego wdrożenie, dostosowanie] jako całość, jest już odpłatne i jako całość podlega pod PZP.

Jak wdrożyć konkretne oprogramowanie open source poza PZP​

Aby w organizacji używać konkretnego rozwiązania np. YetiForce, wówczas zainstalujcie go samodzielnie [co najczęściej trwa tylko chwilę]. Zainstalowane oprogramowanie można następnie rozbudowywać przy pomocy firm zewnętrznych, które mają odpowiednią wiedzę i kompetencję. W ten sposób możemy kierować technologiami wykorzystywanymi w organizacji bez konieczności skazywania się na rozwiązania oferowane przez dostawców w ramach PZP.

Oczywiście same usługi rozbudowy istniejącego rozwiązania w organizacji może podlegać pod PZP, ale wówczas mówimy o usłudze rozbudowy a nie zamówieniu i wdrożeniu oprogramowania danej klasy. Ciekawym przypadkiem może okazać się sprawa KIO/UZP 1244/10 w której omawiany jest przypadek narzucenia oprogramowania open source i zlecenia jego rozbudowy dla już wykorzystywanego rozwiązania w organizacji.

Czy w PZP mogę zawęzić rozwiązanie do open source?​

Zdarza się, że zamawiający zawęzi w zamówieniu użytą technologię do rozwiązania open source i jest to poprawne [Zagadnienie to było przedmiotem jednego z orzeczeń Krajowej Izby Odwoławczej (sprawa KIO/UZP 1853/09)] o ile zamawiający uzasadni swój wybór i nie wskaże konkretnego rozwiązania [np. prawidłowe jest podanie "oprogramowanie open source klasy CRM" natomiast nie można wskazać konkretnego rozwiązania [pomimo, że istnieją inne spełniające założenia], ponieważ nie jest to zgodne z PZP.