Wprowadzenie Niedawno miała miejsce kolejna moja dyskusja na LinkedIn, która pokazała że prawo własności intelektualnej jest bardzo trudne do przyswojenia, głównie dlatego że – z uwagi na swoją „niematerialność” – wymyka się…
prawie 10 lat temu pisałem:
Często spotykam się z różnymi metodami uwzględniania prawa w dokumentacji wymagań. Jakim wymaganiem jest zgodność z obowiązującym prawem? I trudniejsze pytanie: czy zmiana prawa to zmiana wymagań? Inny aspekt problemu to analiza i definicja (opis) tej zgodności z prawem. Spotkać można się z metodą polegającą na traktowaniu każdego (mającego wpływ na system) paragrafu np. ustawy jako wymagania. Problem zgodności oprogramowania z prawem ma dwa aspekty. Zgodność oprogramowania z prawem polega na tym, że ??oprogramowanie nie może ograniczać stosowania prawa to jest nie może wymuszać swoimi ograniczeniami działań niezgodnych z prawem?. Ja osobiście rekomenduję rozciągnięcie tej definicji na ??ani nie powinno pozwalać na łamanie prawa?. Tu jednak wielu uważa, że ??zamawiam narzędzie i używam jak chcę, na swoja odpowiedzialność?. Coś w tym jest, warto jednak zostawić ??włącznik?. (źr.: Prawo a wymagania … )
Dzisiaj czytam:
To administrator odpowiada za zabezpieczenia systemów, a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)
Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z tych obowiązków jest egzekwowanie ustalonych zasad. Dzisiaj o tym, że zbieranie “podpisów pod oświadczeniami” to nie jest bezpieczeństwo.
(more…)
Jarosław Żeliński Date. (2021). Metody kastomizacji oprogramowania standardowego – aspekty ekonomiczne: Recenzja. https://doi.org/10.13140/RG.2.2.22292.01927
Publikacja Jędrzeja Wieczorkowskiego (dalej: recenzowane opracowanie) o poniższym tytule ukazała się w 2015 roku:
Jędrzej Wieczorkowski
Instytut Informatyki i Gospodarki Cyfrowej
Szkoła Główna Handlowa w Warszawie
Metody kastomizacji oprogramowania standardowego: aspekty ekonomiczne.
Autor recenzowanego tekstu odnosi sie do skutków ekonomicznych, pomija jednak całkowicie skutki prawne kastomizacji kodu oprogramowania, które mają wpływ na koszty i ochronę wartości intelektualnych. Autor pisze we wstępie:
Celem niniejszego opracowania jest analiza możliwych metod kastomizacji systemów informatycznych zarządzania przeprowadzona z ekonomicznego punktu widzenia, w tym w szczególności opłacalności stosowania oprogramowania standardowego i wykorzystania poszczególnych metod jego adaptacji. […] Kastomizację systemu informatycznego ogólnie należy rozumieć jako jego adaptację do potrzeb konkretnego podmiotu. M. Flasiński określił kastomizację, jako ?konfigurację systemu, osadzenie w systemie za pomocą prac programistycznych dodatkowych funkcjonalności oraz modyfikację istniejących funkcjonalności systemu?
Dostarczanie oprogramowania i jego wdrażanie, wiąże się jego ewentualnym dostosowaniem do potrzeb użytkownika. Autor powyższego opracowania, stosując nieprecyzyjne definicje pojęć, wprowadza czytelnika w błąd, opisując przyczyny i konsekwencje związane z szeroko pojętym dostosowaniem oprogramowania do potrzeb użytkownika.
Niestety z tego dokumentu korzysta wielu prawników, nazywając go nie raz nawet “wykładnią”.
(more…)
Dzisiejszy wpis to efekt lektury artykułu Pani Mec. Marty Pasztaleniec na stronie IP Procesowo. Kluczowe dla dzisiejszego wpisu jego fragmenty to:
Programy komputerowe w świetle krajowego prawa autorskiego korzystają ze szczególnej ochrony. Z uwagi na ich specyfikę wyłączono stosowanie niektórych regulacji z ogólnej części prawa autorskiego, w szczególności przepisów dotyczących dozwolonego użytku, który umożliwia w ściśle określonych okolicznościach korzystanie z utworów bez zgody twórcy, a nawet wbrew takiej zgodzie. Co do zasady zatem jakiekolwiek zwielokrotnienie programu komputerowego wymaga zgody twórcy. […]
Spór ma swą genezę w 2005 r. kiedy to Google nabył startup Android Inc i rozpoczął starania by wejść na rynek smartfonów, tworząc platformę do budowy systemów dla urządzeń mobilnych. Platforma w swym założeniu miała być nieodpłatna po to by popularyzować środowisko Google. Jako że język programistyczny Java był wówczas jednym z najbardziej popularnych i powszechnych wśród programistów, Google podjął rozmowy z Sun Microsystems ? twórcą Java ? na temat licencjonowania całej platformy Java. Ostatecznie zdecydował się jednak na budowę własnej platformy. Aby jednak zapewnić jej powszechność i łatwość stosowania wśród programistów zastosowano w nim nazwy funkcji i formatów danych charakterystyczne dla języka Javy. Google de facto opracował własne odpowiedniki funkcji Javy i nadał im nazwy takie same jak w Javie. Oracle, po przejęciu spółki Sun Microsystems, pozwał w 2010 r. Google o naruszenie przysługujących Oracle praw autorskich i patentów. Zarzucono Google skopiowanie blisko 11 500 linii deklaracji API programu Java (co stanowiło 0,4 % deklaracji). […]
Sąd uznał, że działanie Google było ?zgodne z kreatywnym ?postępem?, który jest podstawowym konstytucyjnym celem samego prawa autorskiego?. Według sądu dozwolony użytek pełni więc istotną rolę w rozwoju oprogramowania, a prawo autorskie nie powinno hamować tego rozwoju. (żr.: Dozwolony użytek programów komputerowych ? jak Google pokonał Oracle w USA).
Powyższy tekst wskazuje na dwa ciekawe aspekty oprogramowania, o których dzisiaj napiszę. Pierwszy to tak zwany dozwolony użytek, bardzo często przywoływany w sporach o bezpłatne użycie oprogramowania i zakres tego użycia. Najczęściej dotyczy gier komputerowych ale nie tylko. Drugi to charakter oprogramowania, jakim jest kod źródłowy będący tekstem, oraz efekt ostateczny, jakim jest “komputer realizujący określony mechanizm”, gdzie komputer definiujemy jako “procesor, pamięć i program” . Warto tu zwrócić uwagę na pewien “drobiazg”: autorka (jak wielu innych prawników) traktuje treść programu jako “tekst” i nie raz stosuje analogię do typowych utworów pisanych takich jak proza czy poezja, co jest poważnym błędem. Fragmenty tekstów (esej, praca doktorska, powieść, itp.) bardzo często mają wartość, czego o nie można powiedzieć o oprogramowaniu (nie działa w kawałkach). Owszem, można potraktować fragmenty kodu “literaturowo”, jako przykłady jego struktry i składni (np. literatura na temat wzorców projektowych w inżynierii oprogramowania), jednak nie można mówić o fragmencie kodu, że to “oprogramowanie”, gdyż to z zasady “musi działać”, a jest to możliwe tylko wtedy gdy do komputera załadujemy kompletny program a nie “cytowany fragment”.
(more…)
Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).
Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 “przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).
Tak więc obecnie:
Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!
Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.
Nie ma czegoś takiego jak “proces systemowy”, oprogramowanie realizuje “procedury”.
Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.
(more…)