Dozwolony użytek programów komputerowych czyli o interfejsach

Wstęp

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…)

Continue ReadingDozwolony użytek programów komputerowych czyli o interfejsach

Diagram aktywności UML – kiedy

Wprowadzenie

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).

Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).

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…)

Continue ReadingDiagram aktywności UML – kiedy

SPEM czyli Software & Systems Process Engineering

Tym razem artykuł adresowany do zaawansowanych analityków.

Ta specyfikacja (SPEM) jest datowana na 2008 rok. Stanowi sobą tło dla MDA oraz uzasadnia wzorce projektowane oparte na przypadkach użycia (mikroserwisy, Use Case 2.0, inne podobne). Podstawowa różnica między specyfikacją SPEM a specyfikacją UML polega na tym, że UML to profile MOF stanowiące opisy notacji i systemów pojęciowych. SPEM to metamodel procesu wytwórczego oprogramowania czyli generalne zasady budowania procesów wytwarzania i dostarczania oprogramowania.

(more…)

Continue ReadingSPEM czyli Software & Systems Process Engineering