Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy.

Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się “opisem przedmiotu zamówienia”.

Czytaj dalej Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Prawo dotyczy każdego obywatela, autorskie też

… zanim ktoś na prawdę zacznie krytykować prawo autorskie, nie zastanowi się zanim zacznie uogólniać. To prawo chroni dzieła Mickiewicza (autorskie prawa osobiste) jak i prace naukowców, architektów, projektantów i wielu innych profesjonalistów. Chroni dorobek żyjących artystów. Owszem, ten rynek żywi wielu pasożytów, ale “atakujmy” pasożytów a nie wylewajmy dziecka z kąpielą, zrównując wielkie dzieła kultury nieżyjących autorów, z tak chętnie kradzionymi utworami muzycznymi współczesnych muzyków popkultury czy dziełami twórców gier komputerowych.

Czytaj dalej Prawo dotyczy każdego obywatela, autorskie też

Prawa autorskie w architekturze … oprogramowania

Pojęcie nadzoru autorskiego budzi wiele emocji, w branży IT jest to chyba temat tabu, głównie z powodu nadużyć twórców i dostawców oprogramowania, a także dlatego, że tu (branża IT) prawo…

Czytaj dalej Prawa autorskie w architekturze … oprogramowania

Prawa autorskie w ARCHITEKTURZE

Niedawno pisałem (Instrukcja dla prawników...) o tym, że prawnicy to nie inżynierowie. Nie był to przytyk, a zwykłe wskazanie na fakt, że to po prostu  rożne kompetencje. Problem prawa autorskiego…

Czytaj dalej Prawa autorskie w ARCHITEKTURZE

Jawność ofert – zawsze mów prawdę

Na prawdę uważam, że ukrywanie treści ofert to sygnał: “jestem kanciarzem” (podobnie jak niepodpisywanie ich imieniem i nazwiskiem autora). Nie widzę nawet jednego powodu by np. cena była “know-how” firmy… jeżeli ktoś tak uważa to … współczuję. Prawdziwe know-how spokojnie chroni prawo autorskie czy patentowe, tajemnica firmy – a np. szczegóły organizacyjne firmy (tajemnica), to raczej nie jest przedmiot oferty ani zapytania.

Czytaj dalej Jawność ofert – zawsze mów prawdę

Rzeczpospolita wprowadzi opłaty online – a nie mówiłem

Tak więc rynek jest nieubłagany, skoro reklamy nie zarabiają na utrzymanie merytorycznych serwisów, trzeba będzie płacić za ich treść.

Cóż? prawa rynku są nieubłagane, coraz więcej gazet i autorów blokuje bezpłatny dostęp do swoich archiwów zaś bieżące informacje są coraz częściej, nie tylko publikowane, są po prostu sprzedawane poszczególnym publikatorom (Prawo autorskie czyli model biznesowy sprzedaży wartości niematerialnych i usług).

To, Rzeczpospolita, kolejny tytuł, który zaczyna pobierać opłaty za treść.

Czytaj dalej Rzeczpospolita wprowadzi opłaty online – a nie mówiłem

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że “nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi “projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.

Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: “wiedza organizacji” tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalej Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!