Open Source

Transkrypt

Open Source

Metodologia Open Source
dr inż. Tomasz Maria Boiński
Tomasz Boiński: 1
Współautorzy
dr inż. Mariusz Matuszek
dr inż. Michał Piotrowski
Tomasz Boiński: 2
Agenda
•
•
•
•
•
•
•
•
•
•
•
•
•
Wstęp
Czym jest Open Source?
Free Software Foundation a Open Source Initiative
Własność intelektualna
Licencje na oprogramowanie, prawo patentowe
Prawo patentowe w różnych krajach
Zarządzanie dużymi projektami typu Open Source
Zasady włączania oprogramowania do dystrybucji Linuksa
Cykl rozwojowy dystrybucji systemu Linux
Komercyjne aplikacje i systemy oparte o Open Source
Procedura standaryzacyjna formatów i protokołów
Pozytywne i negatywne aspekty zarówno Closed jak i Open Source
Przyszłość Open Source
Tomasz Boiński: 3
Open Source - Wstęp
Taken from http://xkcd.com
Tomasz Boiński: 4
Organizacja przedmiotu
•
•
•
•
15 godzin wykładu – do połowy semestru
15 godzin seminarium – od połowy semestru
Zaliczenie części wykładowej – 50 punktów
Każdy musi przedstawić jakieś zagadnienie w trakcie
seminarium – 50 punktów
• Rozkład zajęć:
– Szczegóły podam później
• Seminaria – zespoły do 3 osób, preferowane 2 osoby, 20
minut/osoba
Tomasz Boiński: 5
Open Source
• Open Source jest podejściem do projektowania,
wytwarzania oraz dystrybucji oprogramowania
• Pozwala na dostęp do kodu źródłowego i innych materiałów
związanych z oprogramowaniem/produktem
• Nie dotyczy tylko i wyłącznie oprogramowania, pryncypia
stojące za OS zostały wykorzystane dla wielu efektów
innych typów twórczej pracy człowieka
• Ruch OS został zapoczątkowany przez takie osoby jak:
Ritchard Stallman, Bruce Perens, Michael Tiemann, Eric
Raymond
Tomasz Boiński: 6
Open Source (2)
• Open Source nie oznacza za darmo!
• Powszechnie uznawane bariery, zazwyczaj zwiększające
ryzyko inwestycji, będące przeszkodą przed komercyjnym
wykorzystaniem OS:
–
–
–
–
wrażenie, że licencje zgodne z OS posiadają “cechy wirusów”,
brak formalnego wsparcia, szkoleń itp.,
częstotliwość zmian,
brak dalekosiężnych planów, map drogowych itp.
• Jednakże:
– również i wiele komercyjnych projektów ma niesprecyzowaną przyszłość,
– nie wszystkie licencje mają podobny poziom restrykcji,
– wiele poważnych projektów typu OS (np. systemy operacyjne, bazy danych)
zarabia na wsparciu, dokumentacji, szkoleniach itp. (Red Hat, Novell,
Cedega etc.)
Tomasz Boiński: 7
Open Source (3)
Tomasz Boiński: 8
Open Source (4)
• O ruchu OS decydują w praktyce dwie główne organizacje:
Free Software Foundation and Open Source Initiative
• Obie mają ten sam cel, różnią się metodą dążenia do niego,
filozofią, etyką
• Ruch Wolnego Oprogramowania (The Free Software
movement) ma na celu uwolnienia oprogramowania od
ciężaru, jakim jest własność intelektualna. Uważają, że ten
ciężar ogranicza rozwój technologiczny i są sprzeczne z
dobrem ogółu.
• Ruch Otwartego Oprogramowania (The Open Source
movement) ma podobne cele, jednak przyjmuje bardziej
pragmatyczne podejście. Członkowie tego ruchu skupiają
się na ekonomicznych i technicznych zyskach płynących z
otwartości oprogramowania, zamiast moralnych i
etycznych, napędzających Ruch Wolnego Oprogramowania.
Tomasz Boiński: 9
Free Software Foundation
• Założona przez Richarda Stallmana 4ego października 1985
by wspierać ruch wolnego oprogramowania, opartego o
zasadę copyleft, która ma na celu promocję wolności jakimi
są prawo do nieograniczonego rozpowszechniania I
modyfikowania oprogramowania.
• Od momentu założenia do połowy lat 90tych, fundusze FSF
były wykorzystywane głównie do zatrudniania
programistów piszących wolne oprogramowanie na
potrzeby projektu GNU.
• Od połowy lat 90tych, pracownicy oraz wolontariusze FSF
skupiali się głównie na kwestiach prawnych i strukturalnych
niezbędnych ruchowi oraz jego społeczności.
• http://www.fsf.org/
Tomasz Boiński: 10
Cztery wolności
• Prawo uruchamiania oprogramowania w dowolnym celu
(wolność 0).
• Prawo do analizy sposobu działania oprogramowania oraz
dostosowywania go do własnych potrzeb (wolność 1). Dostęp
do kodu źródłowego jest niezbędny do realizacji tego prawa.
• Prawo do redystrybucji oprogramowania by móc pomóc
sąsiadom (wolność 2).
• Prawo do ulepszania oprogramowania i możliwości
rozpowszechnienia poprawek tak by cała społeczność mogła
z nich skorzystać (wolność 3). Dostęp do kodu źródłowego
jest niezbędny do realizacji tego prawa.
Tomasz Boiński: 11
Działalność FSF
• Projekt GNU
– Oryginalnym celem FSF była promocja ideałów wolnego oprogramowania.
Wytworzony przez FSF system operacyjny GNU miał być przykładem
takiej działalności.
• Licencje GNU
– FSF jest autorem The GNU General Public License (GPL), popularnej
licencji używanej przez projekty tworzące wolne oprogramowania. Obecna,
trzecia wersja została wydana w czerwcu 2007 roku. FSF jest również
autorem The GNU Lesser General Public License (LGPL), The GNU Free
Documentation License (GFDL), oraz The GNU Affero General Public
License (AGPL).
• GNU Press
– Wydawnictwo FSF, odpowiedzialne za publikację „dostępnych książek
związanych z informatyką za pomocą wolnych licencji” ("publishing
affordable books on computer science using freely distributable licenses.")
Tomasz Boiński: 12
Działalność FSF (2)
• The Free Software Directory - http://directory.fsf.org/
– Jest to lista oprogramowania, które przeszło pozytywną weryfikację i
zostało uznane za wolne. Celem tego przedsięwzięcia jest dostarczenie
wyszukiwarki wolnego oprogramowania oraz możliwości weryfikacji czy
oprogramowanie opisywane jako wolne rzeczywiście takim jest. Ten projekt
w drobnym stopniu był współfinansowany przez UNESCO.
• Utrzymywanie Definicji Wolnego Oprogramowania
– FSF utrzymuje wiele dokumentów definiujących ruch wolnego
oprogramowania.
• Hosting projektów
– FSF udostępnia projektom miejsce na swoich serwerach w ramach witryny
Savannah (http://savannah.gnu.org/ oraz http://savannah.nongnu.org/).
Tomasz Boiński: 13
Działalność FSF (3)
• Kampanie polityczne
– FSF sponsoruje kampanie przeciwko wszystkiemu co postrzega jako
zagrożenie dla wolności oprogramowania, np.: patenty na oprogramowanie,
digital rights management (które FSF określa poprzez "digital restrictions
management", jako jeden z środków na podkreślenie, że takie technologie
stworzono po to, by "odebrać i ograniczyć Twoje prawa"), prawa autorskie
do interfejsów użytkownika.
– Wadliwe z Definicji (Defective by Design) – zainicjowana przez FSF
kampania przeciwko DRM.
– BadVista jest kampanią przeciwko systemowi Microsoft Windows Vista i
mającą na celu promocję wolnych alternatyw.
– Kampania promująca Ogg+Vorbis.
– FSF również sponsoruje niektóre projekty o „wysokim priorytecie”.
• Coroczne nagrody
– "Award for the Advancement of Free Software"
– "Free Software Award for Projects of Social Benefit"
Tomasz Boiński: 14
Działalność prawna
• FSF jest właścicielem praw autorskich do kluczowych
elementów systemu GNU, jak np. GNU Compiler Collection
• Do roku 2004 była jedyną organizacją, która pilnowała
przestrzegania zasad licencji GPL. Później Harald Welte
uruchomił serwis gpl-violations.org I również rozpoczął
podobną działalność
• Od 1991 do 2001, wymuszanie przestrzegania zasad licencji
GPL było realizowane nieformalnymi metodami, zazwyczaj
przez samego Stallmana. Zazwyczaj była to krótka wymiana
e-maili
• Pod koniec 2001, Bradley M. Kuhn, przy współpracy
Moglena, Davida Turnera i Petera T. Browna,
sformalizowali te działania tworząc GPL Compliance Labs.
Od tego czasu coraz powszechniejsze stały się formalne
działania prawne takie jak przeciwko Linksys czy OpenTV
Tomasz Boiński: 15
Działalność prawna (2)
• Od 2003 do 2005, FSF prowadziła seminaria prawnicze
mające na celu wyjaśnienie czym jest I z czym wiąże się
GPL. Seminaria te dawały punkty CLE (Continuing Legal
Education) I były pierwszą prubą formalnej edukacji na
temat GPL
• Podczas słynnego pozwu SCO przeciwko IBM, FSF, w
trakcie 2003 i 2004 roku, zaangażowała znaczące środki
prawnicze by zminimalizować jego negatywny aspekt na
postrzeganie I akceptację wolnego oprogramowania
• W grudniu 2008, FSF pozwała Cisco za wykorzystywanie
niezgodnie z licencją GPL elementów oprogramowania w
routerach Linksys. Cisco wiedziało o sprawie już od 2003
roku, jednak unikało przestrzegania zasad licencji GPL
Tomasz Boiński: 16
Open Source Initiative
• Założona w lutym 1998 przez Bruce'a Perensa i Erica S.
Raymonda
• Powstanie ma związek z upublicznieniem kodu Netscape
Communicatora przez Netscape Communications
Corporation
• Neguje
konfrontacyjne
podejście
ruchu
wolnego
oprogramowania, preferuje zachęcanie do otwartości
poprzez wykazanie korzyści z tego płynących. Celem jest
zachęcenie biznesu do korzystania z otwartego
oprogramowania
• Raymond określił swoje podejście słowami: "If you want to
change the world, you have to co-opt the people who write
the big checks."
• http://www.opensource.org/
Tomasz Boiński: 17
Definicja Open Source
• Na jej podstawie Open Source Initiative określa czy dane
oprogramowanie może być traktowane jako otwarte
• Została oparta od Wskazówki dla Wolnego
Oprogramowania Debiana (Debian Free Software
Guidelines), napisana głównie przez Brucea Perensa
• Open source nie oznacza tylko dostępu do kodu źródłowego
• Aby oprogramowanie mogło zostać uznane za otwarte musi
spełniać następujące warunki:
Tomasz Boiński: 18
Definicja Open Source (2)
1. Wolność redystrybucji
– Licencja nie może ograniczać jakiegokolwiek podmiotu przed sprzedażą lub
oddaniem oprogramowania będącego składnikiem większej całości
zawierającej oprogramowanie z różnych źródeł. Licencja nie może narzucać
jakiejkolwiek rekompensaty za taką redystrybucję.
2. Kod źródłowy
– Oprogramowanie musi być dostarczane wraz z kodem źródłowym oraz musi
umożliwiać dystrybucję zarówno postaci źródłowej jak i binarnej. Jeżeli
oprogramowanie nie jest rozpowszechniane wraz z kodem źródłowym
powinna istnieć dobrze opisana metoda jego pozyskania po kosztach nie
większych niż koszt nośnika lub bezpłatnego pobrania z Internetu. Kod
źródłowy musi być podstawową formą modyfikowalną oprogramowania.
Celowe zaciemnianie kodu jest zabronione. Postacie pośrednie takie jak
wynik działania preprocesora lub translatora są niedozwolone.
Tomasz Boiński: 19
3. Dzieła pochodne
– Licencja powinna zezwalać na modyfikacje i tworzenie dzieł pochodnych.
Musi też umożliwiać redystrybucję efektów tych prac na tej samej licencji
co oryginalne dzieło.
4. Integralność kodu źródłowego oryginalnego autora
– Licencja może zabronić redystrybucji zmodyfikowanego kodu tylko w
przypadku, gdy umożliwia dystrybucję "patchy" wprowadzających
określone modyfikacje w kodzie. Licencja musi jednoznacznie zezwalać na
dystrybucję oprogramowania zmodyfikowanego poprzez patche. Licencja
może narzucić wymóg zmiany nazwy lub wersji nowo powstałego
oprogramowania.
5. Brak dyskryminacji osób i grup
– Licencja nie może dyskryminować żadnej osoby lub grupy osób.
Tomasz Boiński: 20
6. Brak dyskryminacji przeciw zastosowaniu czy polu
działania
– Licencja nie może ograniczać pola zastosowania aplikacji. Nie może np.
zabraniać wykorzystania aplikacji w celach komercyjnych lub np. w celu
badań naukowych nad genomem.
7. Dystrybucja licencji
– Prawa przypisane do oprogramowania muszą w tej samej formie
obowiązywać wszystkich użytkowników bez konieczności akceptacji
dodatkowych licencji.
8. Licencja nie może być zależna od produktu
– Uprawnienia dostarczane wraz z licencją nie mogą być zależne od faktu czy
oprogramowanie należy do jakiejś konkretnej całości czy nie. Jeżeli
program zostanie w jakiś sposób wyłączony z większej dystrybucji i będzie
rozpowszechniany na podstawie tej samej licencji musi gwarantować takie
same prawa jak te, które uzyskują użytkownicy zagregowanej aplikacji.
Tomasz Boiński: 21
9. Licencja nie może ograniczać innego oprogramowania
– Licencja nie może wprowadzać dodatkowych ograniczeń co do
oprogramowania rozpowszechnianego wraz z licencjonowanym
oprogramowaniem. Przykładowo licencja nie może wymagać, by inne
zainstalowane na komputerze oprogramowanie było na określonej licencji.
10. Licencja musi być neutralna technologicznie
– Prawa wynikające z licencji nie mogą być zależne od wykorzystanej
technologii, stylu czy interfejsu.
Tomasz Boiński: 22
Open Source Initiative (2)
• OSI próbowała pozyskać wyłączność na znak firmowy,
jakim jest 'open source', jednak się to nie udało
• OSI udało się jednak nawiązać na tyle dobre stosunki z
środowiskiem biznesowym, że pojęcie to nie jest zbyt często
nadużywane
• Ruchowi udało się pozyskać uwagę głównych graczy na
raynku oprogramowania, doprowadzając, że znane
przedsiębiorstwa zaczęły w swojej ofercie proponować
rozwiązania typu OS (np. Corel (Corel Linux), Sun
Microsystems (OpenOffice.org), IBM (OpenAFS))
Tomasz Boiński: 23
OSI vs FSF
• Pochodząc z tego samego środowiska co Free Software Foundation,
Open Source Initiative została utworzona i zaadoptowała termin open
source, cytując Michaela Tiemanna, by "odrzucić moralizujące i
konfrontacyjne
nastawienie
wiązane
wcześniej
z
'wolnym
oprogramowaniem' oraz zachęcić innych do pomysłu kierując się
takimi samymi, pragmatycznymi ideami, jakimi kierowała się firma
Netscape."
• Wg Stallmana, istotną i podstawową różnica jest filozofia stojąca za
obiema instytucjami
• Stallman opisuje obie inicjatywy jako dwa odrębne obozy w tej samej
społeczności zorientowanej na otwartość oprogramowania
• Stallman: "Różnimy się z obozem open source w podstawowych celach I
wartościach, jednakże zarówno ich jak i nasze poglądy prowadziły
zazwyczaj do tych samych efektów, czyli tworzenia wolnego
oprogramowania. W wyniku tego działacze z obu obozów często
współpracują ze sobą."
• OSI oraz FSF są obecnie dwiema głównymi organizacjami w hakerskiej
społeczności
Tomasz Boiński: 24
Własność intelektualna
“Własność intelektualna to pewna liczba różnorodnych
monopoli obejmujących twórczość umysłową, zarówno
artystyczną jak i komercyjną, oraz odpowiadające jej obszary
prawne. Na podstawie własności intelektualnej, jej posiadacze
otrzymują pewne unikalne prawa w stosunku do chronionych
zasobów.”
Typowe rodzaje własności intelektualnej:
– Prawa autorskie
– Znaki towarowe
– Patenty
Tomasz Boiński: 25
Znaki towarowe
• Unikatowy symbol lub wyznacznik stosowany przez osoby
indywidualne, organizacje czy dowolny inny podmiot
prawny
• Wykorzystywany do odróżnienia produktu od podobnych
oferowanych przez inne podmioty
• Zazwyczaj jest to imię, frazes, logo, symbol, twór
artystyczny czy dowolna kombinacja tych elementów
• Właściciel znaku towarowego może podjąć akcje prawne
przeciwko podmiotom wykorzystującym znak towarowy bez
zezwolenia
• Definiuje się 3 rodzaje znaków towarowych:
– Niezarejestrowany znak towarowy (unregistered trademark) ( TM)
– Niezarejestrowany znak usługowy (unregistered service mark) (SM)
– Zarejestrowany znak towarowy lub usługowy (registered trade or service
mark) (®)
Tomasz Boiński: 26
Prawo autorskie
• Autor dzieła otrzymuje wyłączne prawa na pewien okres
czasu na publikację, dystrybucję oraz modyfikację
chronionego dzieła. Po tym czasie dzieło trafia do
przestrzeni publicznej
• Zazwyczaj czas ochrony trwa od 50 do 100 lat od czasu
śmierci autora. W przypadku dzieł anonimowych i
korporacyjnych czas ochrony jest zazwyczaj krótszy
• Zazwyczaj nie jest wymagana żadna formalna rejestracja
• Prawa autorskie są znormalizowane w skali światowej
dzięki podpisaniu przez większość krajów konwencji: Berne
Convention oraz Universal Copyright Convention
Tomasz Boiński: 27
Prawo autorskie w Polsce
• Mamy dwie formy prawa autorskiego – osobiste oraz
majątkowe. Osobiste mówią kto wykonał dzieło, są
niezbywalne. Prawa majątkowe umożliwiają decyzję o
sposobie dystrybucji itp. Dalej będziemy mówić o prawie
majątkowym
• Prace opublikowane są chronione przez 70 lat po śmierci
autora lub 70 lat od pierwszej publikacji, gdy autor jest
nieznany
• Trwa 70 lat gdy prawa materialne należą do kogoś innego
niż prawa osobiste lub gdy praca nie została opublikowana
• 50 lat dla programów TV, fonogramów i audiogramów
• Dzieło nie musi być w żaden sposób zarejestrowane czy
opatrzone jakimkolwiek znakiem by było chronione
Tomasz Boiński: 28
Prawo autorskie w pigułce
• Publikacja dzieła bez zgody jest zabroniona, zarówno w
przypadku zastosowań komercyjnych jak I
niekomercyjnych
• „Proste informacje prasowe” nie są chronione przez prawo
autorskie (art. 4 punkt 4)
• Raz opublikowane krótkie sprawozdania prasowe,
streszczenia itp. mogą być rozpowszechniane bez zgody
autora (art. 25)
• Jeżeli tego nie zabroniono w umowie pomiędzy
dystrybutorem a autorem, autor może rozpowszechniać
dzieła w inny sposób
• Prawo nie jest chronione prawem autorskim
Tomasz Boiński: 29
Dozwolony użytek w Polsce
• W określonych przypadkach dzieła mogą być wykorzystywane
bez zgody autora
• Osobisty dozwolony użytek:
– dzieła chronione prawem autorskim mogą być rozpowszechniane bez zgody
autora w obrębie niejasno zdefiniowanego kręgu „osób pozostających w
związku osobistym, w szczególności pokrewieństwa, powinowactwa lub
stosunku towarzyskiego”
• Nie osobisty dozwolony użytek:
– zdefiniowana jest szczegółowa lista przypadków, kiedy zgoda nie jest konieczna
– wykorzystanie utworów nie mających samodzielnego znaczenia gospodarczego,
a potrzebnego do przeprowadzenia procesu technologicznego (instrukcje
obsługi, know-how)
– rozpowszechnianie publicznie dostępnych kanałów TV i radiowych do nie
więcej niż 50 gospodarstw domowych
– sporządzać kopie i nieodpłatnie korzystać z fragmentów utworów potrzebnych
do celów dydaktycznych
– biblioteki i archiwa mogą udostępniać prace chronione poprzez wypożyczanie
Tomasz Boiński: 30
Dozwolony użytek w Polsce (2)
• Nie osobisty dozwolony użytek c.d.:
– „prawo cytatu”
– publiczne odtwarzanie materiałów chronionych podczas ceremonii
religijnych, akademickich i państwowych jest dozwolone, pod warunkiem,
że wstęp na uroczystość jest otwarty i darmowy a wykonawca nie otrzymuje
żadnej gratyfikacji za wykonane dzieło
– dystrybucja publicznie dostępnych dzieł zlokalizowanych w miejscach
publicznych takich jak place, skwery, ulice itp. pod warunkiem, że
dystrybuowane dzieło będzie miało inną formie niż oryginał, np. Zdjęcie
pomnika
– encyklopedie i atlasy mogą publikować materiały prawnie chronione w
sytuacji, gdy uzyskanie zgody może być trudne
– kilka innych przypadków
– we wszystkich przypadkach konieczne jest podanie źródła i autora
– jeżeli nie jest zaznaczone inaczej w konkretnym prawie, to właściciel praw
autorskich zawsze może wystąpić o zadośćuczynienie
Tomasz Boiński: 31
Dozwolony użytek w Polsce (3)
• Użytkownicy mogą wykonywać kopie bezpieczeństwa
legalnie nabytych materiałów pod warunkiem braku
zabezpieczeń przed kopiowaniem
• Materiały audio-video oraz tekst nie mogą być
rozpowszechniane bez zgody autora
• Legalność lub jej brak materiałów pobranych z sieci nie jest
oczywista, jest to jednak moralnie złe
• Oprogramowanie oraz cyfrowe bazy danych NIE są objęte
prawem dozwolonego użytku. Wykorzystywanie,
pobieranie, rozpowszechnianie, kopiowanie itp. Zawsze jest
niezgodne z prawem (chyba, że licencja mówi inaczej)
• Jeżeli chcesz by inni respektowali Twoje prawa, respektuj
ich, włączając w to prawa autorskie
Tomasz Boiński: 32
Dozwolony użytek w USA
• Opisane w par. 107 ustawy "Copyright Act of 1976"
• Zawiesza penalizację oraz roszczenia w przypadku, gdy
dzieło zostało wykorzystane “uczciwie” w celu krytyki,
komentarza, nauki czy badań.
• “Uczciwość” użycia określana jest na podstawie
następujących kryteriów:
–
–
–
–
jak i dlaczego dzieło zostało użyte
rodzaj dzieła, który został użyty
wielkość użytego fragmentu w stosunku do rozmiaru całej pracy pochodnej
Efekt, jaki przyniosło wykorzystanie dzieła i jego wpływ na wartość i
sprzedaż dzieła pochodnego
• Prawo oparte o precedensy – ciągłe zmiany
Tomasz Boiński: 33
Licencje na oprogramowanie
• Licencja na oprogramowanie jest to jest instrumentem
prawnym opisującym wykorzystanie i/lub dystrybucje
chronionego oprogramowania
• Każde oprogramowanie, które nie zostało przeniesione do
Public domain jest chronione
• Zazwyczaj licencja zezwala użytkownikowi na
wykorzystanie jednej lub więcej kopii w sposób, który w
innych wypadkach traktowany byłby jako naruszenie prawa
autorskiego
• Licencja jest więc obietnicą ze strony autora, że nie będzie
dochodził wobec użytkownika swoich praw opisanych przez
odpowiednie ustawy
• Porównanie wielu licencji znajdziemy pod adresem:
http://en.wikipedia.org/wiki/Comparison_of_free_software_licences
Tomasz Boiński: 34
Licencje na oprogramowanie a prawa
autorskie
• Zazwyczaj prawa autorskie dają więcej niż licencja
– Przykładowo w USA, sekcja 117 Copyright Act zezwala właścicielowi kopii
oprogramowania na wykorzystywanie tej kopii za pomocą komputera,
nawet jeżeli to wykorzystywanie będzie wymagało wykonania kopii lub
modyfikacji oprogramowania. Kopiowanie takie, czy też modyfikacja, nie
wymaga więc zgody właściciela praw autorskich i zezwala na wykorzystanie
kopii posiadanej kopii oprogramowania bez licencji.
• Własnościowe licencje mają na celu utrzymanie większej
kontroli nad oprogramowaniem poprzez utrzymanie
własności nad kopią przez dystrybutora
– Dzięki temu, sekcja 117 przestaje obowiązywać, a użytkownik końcowy,
chcąc korzystać z oprogramowania, musi zaakceptować ostrzejsze wymogi
licencyjne niż by to wynikało z prawa autorskiego.
Tomasz Boiński: 35
Licencje na oprogramowanie a prawa
autorskie (2)
• W Polsce dozwolony użytek nie dotyczy oprogramowania
• Inne dzieła mogą być współdzielone pomiędzy kręgiem
“osób pozostających w związku osobistym, w szczególności
pokrewieństwa, powinowactwa lub stosunku
towarzyskiego"
• Prowadzi to do wielu kontrowersji, gdyż definicja takiego
kręgu jest bardzo niejasne, zwłaszcza kiedy mówimy o
relacjach pomiędzy znajomościami internetowymi itp.
• Dozwolony użytek jest ograniczony poprzez DRM i inne
zabezpieczenia
• W Polsce to użytkownik końcowy musi udowodnić, że
wykorzystanie dzieła nie wykracza poza dozwolony użytek
Tomasz Boiński: 36
Rodzaje licencji na oprogramowanie
•
•
•
•
Licencje własnościowe (Proprietary licenses)
Wolne licencje (Free software licenses)
Otwarte licencje (Open Source licenses)
Każdy rodzaj ma inny wpływ na prawa końcowego
użytkownika
Tomasz Boiński: 37
Licencje własnościowe
• Dystrybutor oprogramowania udziela licencji na jedną lub
więcej kopii oprogramowania
• Dystrybutor pozostaje właścicielem każdej kopii (stąd
nazwa „własnościowe”)
– Konsekwencją tej cechy licencji własnościowych jest posiadanie przez
dystrybutora praktycznie wszystkich praw do każdej kopii
oprogramowania.
– Tylko wąski, dobrze zdefiniowany zakres uprawnień przekazany jest
użytkownikowi
– Użytkownik musi zaakceptować licencję chcąc wykorzystywac dane
oprogramowanie.
• Typowym przykładem tego typu licencji jest licencja
systemu Microsoft Windows. Ta licencja zawiera typową
listę zabronionych czynności, np.: reverse engineering,
używanie przez więcej niż 1 użytkownika naraz, publikacja
wyników benchmarków czy testów wydajnościowych
Tomasz Boiński: 38
Problem z EULA
• Licencje prawie zawsze udzielane są na zasadzie “wszystko
albo nic”
• Zazwyczaj można ją przeczytać dopiero po zakupie
produktu, często w postaci okienka dialogowego z
przyciskami Akceptuj/Odrzuć
• Zazwyczaj narzucają dodatkowe ograniczenia względem
praw użytkownika a także zwalniają dystrybutora z
jakiejkolwiek odpowiedzialności za działania wynikłe z
użytkowania oprogramowania
• Część dostawców używa EULA by ominąć ograniczenia
jakie na licencje nakłada prawo autorskie
Tomasz Boiński: 39
EULA problem (2)
Tomasz Boiński: 40
Wolne licencje
• W odróżnieniu od licencji własnościowych, prawo własności
do kopii nie pozostaje przy dystrybutorze a przechodiz na
użytkownika końcowego
• "właściciel kopii" nie jest tożsamy z "właścicielem praw
autorskich" – użytkownik końcowy uzyskuje prawa tylko
do tej jednej kopii, reszta praw pozostaje przy autorze
• Wolne licencje zazwyczaj rozszerzają prawa jakie posiada
użytkownik końcowy względem praw, jakie dałoby mu
prawo autorskie
Tomasz Boiński: 41
Wolne licencje (2)
• Akceptacja licencji jest opcjonalna – użytkownik końcowy
może używać oprogramowanie bez konieczności akceptacji
licencji
• Jeżeli użytkownik chce skorzystać z dodatkowych praw
wynikających z licencji (np. możliwość redystrybucji) to
musi ją zaakceptować i przestrzegać
• GNU GPL jest chyba najbardziej znaną wolną licencją
Tomasz Boiński: 42
Otwarte licencje
• Dzielą się na dwa rodzaje:
• 'copyleft' – mają na celu zachowanie wolności i otwartości
oprogramowania
– Dają końcowemu użytkownikowi duże uprawnienia takie jak możliwość
redystrybucji, reverse engineer'ingu czy innej formy modyfikacji kodu,
– Zazwyczaj dodatkowe prawa wymagają czegoś w zamian od użytkownika,
musi się on zgodzić na dodatkowe warunki by móc z tych praw skorzystać,
– GPL jest przykładem takiej licencji.
• Licencje „zezwalajace” (permissive licenses) – mają na celu
zachowanie wolności końcowego użytkownika
– Zezwalają końcowemu użytkownikowi na pełną dowolność w wykorzystaniu
oprogramowania,
– Nie ma żadnych zobowiązań połączonych z tymi prawami,
– Przykładem jest tutaj licencja BSD czy MIT
– Oprogramowanie na takiej licencji może być wykorzystywane przez
oprogramowanie własnościowe
Tomasz Boiński: 43
Inne cechy licencji
• Oprócz nadawania praw czy wymuszania ograniczeń
licencje opisują zależności oraz odpowiedzialność za kod i
wykorzystanie oprogramowania zachodzące pomiędzy
stronami porozumienia licencyjnego
• Zazwyczaj mówią, że producent nie ponosi
odpowiedzialności za wszelkie uszkodzenia wynikłe z
prawidłowego jak i nieprawidłowego wykorzystania
oprogramowania. Zazwyczaj stwierdzają, że korzystanie z
oprogramowania zgodnie z jego zastosowaniem nie powinno
spowodować jakiś złych rzeczy
• W rozwiązaniach komercyjnych zazwyczaj dodatkowo
chronią przedsiębiorstwo dystrybutora
Tomasz Boiński: 44
Najpopularniejsze licencje
Istnieje bardzo dużo wolnych/otwartych licencji (Free-Libre /
Open Source Software (FLOSS)), jednakże tylko kilka jest
powszechnie stosowane
Licencje są kompatybilne pomiędzy sobą – strzałka od A do B
oznacza, że można łączyć oprogramowanie oparte o licencję A z
oprogramowaniem opartym o licencję B, ale całość musi być
wydana na licencji B
Tomasz Boiński: 45
Public Domain
• W rzeczywistości nie jest to licencja, jednak w praktyce
działa tak jakby to była jedna z nich
• Oprogramowanie znajdujące się w przestrzeni publicznej
może być dowolnie używane, jest jednak rzadkością
• Oprogramowanie musi być jawnie umieszczone w
przestrzeni publicznej lub trafia tam automatycznie, gdy
jest wytworzone przez pracowników rządu USA w ramach
ich stosunku pracy
Tomasz Boiński: 46
MIT/X11
• Prosta, zezwalajaca licencja, zgodna z GPL
• Stosowana głównie przez XFree86, najpopularniejszej
implementacji systemu X Window dla systemów
UNIX'owych
• Generalna zasada: „Możesz rozbić co tylko zechcesz z
kodem, ale nie możesz powiedzieć, że go napisałeś.”
• Oprogramowanie oparte o licencję X11 może być
wykorzystywane w zamkniętym kodzie, pod warunkiem
dołączenia treści licencji
• W 2004, wraz z wydaniem XFree86 4.4, licencja X11 została
zmodyfikowana, wzbudzając tym samym wielkie
niezadowolenie w społeczności
Tomasz Boiński: 47
Zmodyfikowana MIT/X11
• Zmiana dodała jeden, prosty warunek:
The end-user documentation included with the redistribution, if any,
must include the following acknowledgment: "This product includes
software developed by The XFree86 Project, Inc
(http://www.xfree86.org/) and its contributors", in the same place and
form as other third-party acknowledgments. Alternately, this
acknowledgment may appear in the software itself, in the same form
and location as other such third-party acknowledgments.
• Tak zmodyfikowana licencja jest zgodna z GPL v3 ale nie
jest zgodna z GPL v2
• Zmiana ta spowodowała zaprzestanie wykorzystania
XFree86 przez wszystkie główne dystrybucje systemu Linux
Tomasz Boiński: 48
BSD
• Istnieją 3 wersje licencji BSD:
– Oryginalna, 4-zdaniowa zabraniająca używania w materiałach
reklamowych nazwisk/nazw autorów i wymagająca wspomnienia o nich w
dokumentacji
– Zmodyfikowana, 3-zdaniowa zabraniająca używania w materiałach
reklamowych nazwisk/nazw autorów
– Uproszczona, 2-zdaniowa nie posiadająca powyższych ograniczeń
• Wersja 4 zdaniowa nie jest zgodna z GPLv2
Tomasz Boiński: 49
Licencja BSD a MIT/X11
• Licencje te są w dużej mierze zgodne ze sobą i mogą być
stosowane wymiennie, zwłaszcza licencja 3 zdaniowa
• Licencja BSD jest niejednoznaczna – istnieją przynajmniej
jej 3 wersje
• Richard Stallman proponuje zamiast którejkolwiek z
licencji BSD używać licencji X11
• Licencja X11 zawiera nieprecyzyjne sformułowania
„zajmować się oprogramowaniem” (w oryg. „to deal in the
Software”) oraz „oprogramowanie i związane [dołączone]
pliki dokumentacji” (w oryg. „this software and associated
documentation files”), które (wg Rosena) mogą sprawiać
problemy w interpretacji prawnej.
• Uproszczona licencja BSD jest tożsama również z licencją
PostgreSQL
Tomasz Boiński: 50
Apache 2.0
• The Apache License (wersje 1.0, 1.1, oraz 2.0) wymaga
zachowania informacji o posiadaczu praw autorskich, nie
jest licencją typu 'copyleft' – zezwala na stosowanie
oprogramowania w trakcie wytwarzania zarówno
zamkniętego jak i wolnego czy otwartego kodu
• Jest zgodna z GPLv3, ale nie jest zgodna z GPLv1 and
GPLv2, z powodu dodatkowych wymagań nie
uwzględnianych przez te wersje licencji GPL. Te
wymagania obejmują pewne kwestie patentowe itp.
• Kod oparty o licencję Apache może być stosowany wraz z
kodem opartym o GPLv3 ale nie vice versa
Tomasz Boiński: 51
GPL
• Opracowana przez Ritcharda Stallmana, podstawa dla
filozofii stojącej za FSF
• Jest to najpopularniejsza i najbardziej znana licencja typu
'copyleft', wymaga by prace pochodne również były wydane
na GPL
– jest uważana za licencyjnego wirusa
• Zgodnie z filozofią FSF, licencja GPL daje użytkownikowi
prawa wynikające z definicji wolnego oprogramowania oraz
stosuje silny 'copyleft' by zachować przechodniość i
niezmienność tych praw w sytuacji gdy dzieło zostało
zmienione lub rozbudowane
• Oprogramowanie, które wykorzystuje, łączy, zmienia czy
nawet linkuje kod oparty o GPL, jeżeli tylko jest
rozpowszechniane, musi być rozpowszechniane na zasadach
licencji GPL
Tomasz Boiński: 52
GPL (2)
• Treść licencji GPL nie jest na licencji GPL. Modyfikacja
licencji jest zabroniona
• Kopiowanie oraz dystrybucja licencji jest dozwolona, gdyż
użytkownik końcowy wraz z produktem musi uzyskać kopie
licencji
• Zgodnie z FAQ licencji, każdy może wprowadzać zmiany w
licencji pod warunkiem zmiany nazwy wynikowej pracy,
usunięciu preambuły oraz braku wzmianki terminu 'GNU'
• Uwaga na zapis „GPLv2 or later”
Tomasz Boiński: 53
GPL - przykłady
• Joomla! jest wydana na GNU/GPL, rozszerzenia w
większości są utworami zależnymi Joomla!, w związku z
czym muszą być wydawane na licencji GNU/GPL
• eGroupWare jest wydawane na dwu licencjach – GPL i
komercyjnej. Wszelkie zmiany i dodatki do wersji GPL
muszą być wydane na GPL, nie stoi jednak nic na
przeszkodzie, by właściciel kodu (Stylide.de) wydał swoje
zmiany tylko do wersji komercyjnej na zamkniętej licencji
albo i tu i tu na różnych licencjach
• GPL posiada szereg wyjątków – classpath, libstdc++, system
itp.
Tomasz Boiński: 54
GPL - fork
• Modyfikując oprogramowanie wydane na GPL należy
pamiętać o kilku rzeczach:
– Nazwę można zmienić, a nawet jest to zalecane
– Nie można usuwać oryginalnych wpisów o prawie własności z plików
źródłowych a jedynie dodać własne
– Wskazywanie oryginalnego oprogramowania w informacjach reklamowych
nie jest konieczne (chyba) ale i tak wynika z kodu źródłowego i copyrights
– Loga itp. wręcz należy zmienić, bo możemy nie mieć do nich praw
autorskich
– Dzieło pochodne musi zostać wydane na GPL
Tomasz Boiński: 55
LGPL
• GNU Lesser General Public License (LGPL) jest to
zmodyfikowana, bardziej zezwalająca wersja licencji GPL
• Oryginalnie pomyślana została jako licencja dla bibliotek
• Główną różnicą pomiędzy GPL a LGPL jest możliwość
łączenia kodu opartego na LGPL z kodem opartym o inne
licencje bez konieczności zmiany licencji wynikłego dzieła,
niezależnie czy dodatkowy kod jest wolny czy zamknięty
• Jeżeli wynikowe dzieło jest dziełem pochodnym, to jego
licencja musi zezwalać na "modyfikację na potrzeby
użytkownika oraz reverse engineering potrzebny do
debugowania tych zmian."
• Od wersji 3 jest de facto wyjątkiem od licencji GPL
Tomasz Boiński: 56
Affero
• Affero General Public License (GNU AGPL) jest tożsama z
licencją GPL dla oprogramowania opartego o architekturę
klient-serwer
• Różnice polegają na objęciu licencją sytuacji, gdzie
oprogramowanie jest zainstalowane na serwerze i dostępne
zdalnie. Licencja ta wymaga by kod źródłowy aplikacji był
dostępny dla każdego użytkownika, mimo, że de facto nie
otrzymują kopii oprogramowania
• Przygotowana jest dla dostawców, którzy nie
rozpowszechniają kopii oprogramowania, a jedynie
udostępniają użytkownikom przez sieć jedną określoną
kopię
Tomasz Boiński: 57
MPL
• Mozilla Public License (MPL) – została opracowana przez
Mitchella Bakera, kiedy pracował jako prawnik w Netscape
Communications Corporation, wersja 1.1 została
opracowana przez Mozilla Foundation
• Jest to hybryda pomiędzy zmodyfikowaną licencją BSD a
licencją GPL
• Postrzegana jest jako słabe 'copyleft'. Kod wydany na MPL,
po modyfikacji musi pozostać na MPL
• MPL używana jest głównie przez Mozilla Application Suite,
Mozilla Firefox, Mozilla Thunderbird i inne
oprogramowanie wydane przez fundację Mozilla
Tomasz Boiński: 58
MPL (2)
• Inaczej niż to ma miejsce w silnych 'copyleft', kod wydany
na MPL może być łączony z kodem własnościowym w
jednym programie
• MPL jako granicę oddziaływania licencji traktuje plik
źródłowy – określony plik jest albo w całości na MPL albo w
całości na innej licencji
• GPL jako granicę ustanawia proces wykonany w
środowisku docelowym
Tomasz Boiński: 59
I wiele wiele innych...
Tomasz Boiński: 60
Patenty
• Patent jest to zestaw pewnych dodatkowych i wyłącznych
praw nadawany przez państwo wynalazcy lub wskazanej
jednostce na pewien okres czasu w zamian za ujawnienie
szczegółów wynalazku
• Wynalazek ubiegający się o patent musi być czymś nowym,
odkrywczym, użytecznym lub mającym zastosowanie w
przemyśle
• Patent nie jest prawem wykorzystania a sposobem na
wykluczenie innych z prawa do wykorzystania dzieła
• Wg WTO patenty powinny:
– być przydzielane każdemu typowi wynalazku
– na dowolnym polu technologicznym
– na minimum 20 lat
Tomasz Boiński: 61
Problemy z patentami
• Patent musi być przyznany w każdym kraju/regionie osobno
– każdy z nich może mieć inne standardy cy procedury
•
•
•
•
•
Dostęp do listy i treści patentu może być drogi
Trywialne patenty
Trolle patentowe
Tak naprawdę ograniczają innowacyjność
Wprowadzają problem niezgodności typów - GIF i PNG,
MP3 i OGG Vorbis
• Przesłanie, że ludzie nie tworzą a jedynie odkrywają
• Czy oprogramowanie powinno być patentowane?
– jeszcze nie możliwe w EU
– w praktyce możliwe w USA
Tomasz Boiński: 62
Problemy z patentami na
oprogramowanie
• Wspomniane wcześniej problemy z kompatybilnością
• Wynalazek zaimplementowany za pomocą komputera “wynalazek, którego implementacja wymaga zastosowanie
komputera, sieci komputerowej lub innego urządzenia
programowalnego, wynalazek, którego przynajmniej jedna
z cech jest częściowo lub w pełni realizowana przez program
komputerowy – co jest wynalazkiem w co jest tylko
programem?
• Pokrycie definicji z prawami autorskimi – EPO (European
Patent Office) wydało decyzję (T 424/03), że
oprogramowanie jest patentowalne, gdyż jest to metoda
techniczna wykonana za pomocą komputera. Należy ją
odróżnić od samego programu, który tak naprawdę
wykonuje metodę, wtedy program jest tylko sposobem
wyrazu tej metody a przez to chroni go prawo autorskie
Tomasz Boiński: 63
Patenty na oprogramowanie w USA
• "wholly pre-empt the mathematical formula and in
practical effect would be a patent on the algorithm itself"
vs. "it is said that the decision precludes a patent for any
program servicing a computer. We do not so hold."
• W wyniku powyższego dowolny program niezbędny do
uruchomienia patentowanego urządzenia jest patentowalny
wraz z tym urządzeniem na podstawie wyroku Sądu
Najwyższego z 1981: "a claim drawn to subject matter
otherwise statutory does not become nonstatutory simply
because it uses a mathematical formula, computer program,
or digital computer". Więc wniosek zawierający "algorytm
matematyczny i implementuje ten algorytm w pewnej
strukturze lub procesie, który postrzegany jako całość
wykonuje zadania, które z założenia powinny być chronione
przez prawo patentowe" jest patentowalny
Tomasz Boiński: 64
Prawo patentowe w Europie
• "programy dla komputerów" są wyłączone z możliwości
patentowania
• Mowa tutaj o wnioskach na samodzielny program
• Powyższe jest interpretowane jako możliwość patentowania
dowolnego wynalazku, nawet w całości realizowanego
poprzez program komputerowy, jeżeli stanowi nieoczywisty
wkład technologiczny lub rozwiązuje w nieoczywisty sposób
problem techniczny
• Komputerowo zaimplementowane wynalazki rozwiązujące
problem biznesowy traktowane są jako niepatentowalne,
gdyż brakuje im pierwiastka innowacyjności
Tomasz Boiński: 65
Sytuacja w innych krajach
• Japonia – wynalazki oparte o programy są patentowalne
– aby program był patentowalny musi zawierać rozwiązanie problemu
technicznego z wykorzystaniem praw natury
– to wymaganie zazwyczaj jest spełniany poprzez realizację procesu
przetwarzania informacji z wykorzystaniem zasobów sprzętowych
• Australia – algorytmy nie są patentowalne, ale ich
implementacje z wykorzystaniem komputera są
• Korea Poludniowa – oprogramowanie jest patentowalne i
wuele takich patentów zostało przyznanych
• Indie – patentowanie oprogramowania jest niedozwolone
Tomasz Boiński: 66
Wojna patentowa
Tomasz Boiński: 67
Status
•
•
•
•
•
•
•
Ciężko powiedzieć :(
Niespójne prawa w różnych krajach
Różne definicje tego co jest patentowalne a co nie
Naciski ze strony dużych korporacji
Programiści zazwyczaj są przeciwni patentom
Coraz więcej rozwiązań realizowana jest przez komputery
Przyszłość jest niepewna
Tomasz Boiński: 68
Zarządzanie dużym projektem
OpenSourcowym
• Cel – pozyskać użytkowników a część z nich przekonać do
przyłączenia się jako developerzy
• W czym leży problem?
–
–
–
–
–
–
Różne licencje muszą być wzięte pod uwagę
Geograficzne i kulturowe rozproszenie i zmienny zbiór developerów
Potrzeba silnego lidera
Brak stałego finansowania
Patenty na oprogramowanie
Typowe problemy developerskie:
- nieosiągalne wymagania,
- niejasna specyfikacja,
- słabe zarządzanie zasobami,
- niedostateczne wysiłki projektowe,
- etc.
Tomasz Boiński: 69
Otwracie projektu rozwiązaniem
problemów?
• Niestety nie
– Otwartość licencji nie gwarantuje hord developerów naglę chętnych do
poświęcania swojego czasu na nasz projekt,
– Jeżeli projekt ma problemy, to jego otwarcie nie spowoduje ich
automatycznego rozwiązania
- W krótkim okresie czasu utrzymanie projektu może kosztować więcej
- Wymaga uporządkowania kodu by był zrozumiały dla obcych,
- Wymaga utworzenia strony WWW, list dyskusyjnych itp.
- Konieczność napisania dokumentacji, bardzo często jest to pierwsza
dokumentacja projektu
– Nawet, jeżeli jakiś developer wykaże zainteresowanie projektem, to należy
liczyć się z narzutem czasowym koniecznym do przekazania mu wiedzy
niezbędnej do rozpoczęcia pracy
• W wyniku większość projektów OS skazana jest na porażkę
(90-95%)
Tomasz Boiński: 70
Typowe błędy
• Oszczędna prezentacja i możliwości instalacji
oprogramowania
• Brak dokumentacji
• Brak treści na stronach www
• Powody:
–
–
–
–
Nie mam wystarczających umiejętności,
Ja umiem zainstalować, używać i zarządzać moim oprogramowaniem
Kod jest najważniejszy
Więc po co?
• Brak zarządzania lub jego sposób identyczny z stosowanym
w projektach na własne potrzeby jest wystarczający
– Zespół indywidualistów doskonale się przecież dogada bez jakiś specjalnych
procedur.
– Nacisk na niewłaściwe aspekty zarządzania.
Tomasz Boiński: 71
Aspekty kulturowe a stabilność
projektu
• Globalna kultura wolnego oprogramowania jest relatywnie
nowym osiągnięciem
• Pomimo tendencji do podziałów, posiada powszechnie
akceptowany rdzeń zachowawczy
– Nagradza pewne zachowania, karze inne
– Zachęca do spontanicznego zaangażowania kosztem sterowania centralnego,
– Ma jasno określone co jest traktowane jako miłe a co jako niemiłe
• Aktywni developerzy rozpowszechnili ten standard, więc
jest globalna spójność w oczekiwaniach
• Projekty, które odniosły sukces zawsze opierają się na
dobrze ugruntowanych zachowaniach w celu rozwiązania
sytuacji konfliktowych
Tomasz Boiński: 72
Więc jak zapewnić projektowi sukces?
• Bądź świadomy różnic pomiędzy wolnym a otwartym
oprogramowaniem, developerzy mają swoje preferencje
• Wolna kultura oparta jest o możliwość wyboru
• Cierpliwości – aby grupa się zżyła potrzebny jest czas,
zwłaszcza gdy brak bezpośredniej komunikacji
• Developerzy i użytkownicy muszą widzieć przełożenie ich
zaangażowania na wpływalność na decyzje
• Tworzone oprogramowanie musi być przydatne samym
twórcom, zwiększa to szansę na jego poprawę
Tomasz Boiński: 73
Rozruch projektu
• Sprawdź, czy ktoś nie robi już czegoś podobnego
• Określ co tworzony system będzie robił, a co nie – ustalenie
zakresu projektowego jest fundamentem pod dalsze prace
• Zadbaj o dobre pierwsze wrażenie
– Użytkownicy kontakt z projektem zaczną od jego strony www i na jej
podstawie ocenią sam projekt
– Informacje muszą być łatwo dostępne
– Odnośniki powinny prowadzić tam, gdzie sugeruje ich nazwa
– Zadbaj, by by sama strona mówiła „nie stracisz z nami czasu”
• Zbierz wiedzę dostępną dotychczas jedynie dla
rozwijających system
• Udokumentuj wszystko co możliwe i uporządkuj kod – dla
Ciebie może on być oczywisty, dla innych już niekoniecznie
Tomasz Boiński: 74
Rozruch projektu (2)
• Nadaj projektowi jakąś ciekawą nazwę
• Jasno określ swój cel i to co chcesz osiągnąć
• Wyraźnie określ czy to będzie projekt typu closed/open/free
source
• Opisz funkcje i wymagania twojego oprogramowania
• Określ status projektu na jego drodze rozwojowej
• Stosuj powszechnie wykorzystywane standardy
paczkowania i instalacji oprogramowania
• Zapewnij system kontroli wersji i śledzenia błędów zarówno
deweloperom jak i użytkownikom
• Zapewnij możliwości komunikacji pomiędzy użytkownikami
i deweloperami
Tomasz Boiński: 75
Rozruch projektu (3)
• Przygotuj zarówno dokumentację techniczną, jak i zestaw
reguł społecznych:
– Jak różne rzeczy są realizowane
– Jakie są zasady komunikacji itp.
• Dobrze jest dostarczyć dokumentację zarówno on-line na
stronach www jak i off-line wraz z kodem/paczką binarną
• Umieść na www zrzuty ekranu czy przykładowe wyjście
• Wybierz licencję i dołącz ją zarówno do kodu jak i
dokumentacji
Tomasz Boiński: 76
No ok, mamy projekt. Co teraz? :)
Tomasz Boiński: 77
Jak spowodować, by projekt żył?
• Nie narzucaj decyzji – w projektach OS ważny jest
consensus
• Nie wdawaj się w kłótnie, nie zmuszaj ludzi do
przepraszania, trzymaj się tematu dyskusji
• Oceniajcie krzyżowo kod w zespole:
– Dobrze jest powiadomić wszystkich o nowym commicie
– Propozycje zmian, potencjalne błędy itp. powinny być publiczne
• Kiedy projekt jest gotowy na to – pokaż go światu (nie musi
być skończony, wystarczy, że jest co pokazać
– http://freshmeat.net/
– Grupy dyskusyjne, listy mailingowe itp. skupiające osoby, które mogą być
zainteresowane projektem
• Postępuj dalej zgodnie z planem, rozwijaj swój projekt i
cierpliwie czekaj na rozrost społeczności
Tomasz Boiński: 78
Infrastruktura techniczna
• Strona www
– Główne źródło informacji, interfejs dla pozostałych usług
• Listy mailingowe
– Zazwyczaj najbardziej dynamiczna forma komunikacji w projekcie,
również sposób na archiwizację informacji
• System kontroli wersji
• System śledzenia błędów
– Służy do śledzenia nie tylko błędów, ale także zadań, wydań czy
funkcjonalności
– Pozwala na koordynację prac i śledzenie zaawansowania realizacji zadania
• Komunikacja na żywo
– Czasami potrzeba szybkiej formy komunikacji czy możliwości szybkiego
uzyskania odpowiedzi na pytanie
Tomasz Boiński: 79
Infrastruktura społeczna i polityczna
• Groźba rozgałęzienia (fork) jest sposobem na zmuszenie do
kompromisu
– W rzeczywistości rozgałęzienia są rzadkie
• W jaki sposób podejmować decyzje?
– Łaskawy Dyktator
- Czy projekt ma w swoich zasobach osobę o odpowiednich
umiejętnościach?
- Czy zostanie zaakceptowany przez zespół?
- Zazwyczaj model ten jest stosowany w początkowej fazie rozwoju
– Demokracja oparta o kompromis
- Stosowana w dojrzałych projektach
– Głosowanie
- Kiedy głosować? - powinno być rzadkie.
- Jak? Kto może? - jasno zdefiniowane regóły
Tomasz Boiński: 80
Pieniądze
• Czy wolne/otwarte projekty mogą pozyskać pieniądze lub
inną formę wsparcia?
• Oczywiście, finansowanie można pozyskać na różne cele:
–
–
–
–
–
Odciążenie organizacyjne
Wsparcie podległych projektów
Marketing
Podwójne licencjonowanie
Pozbycie się konkurencji itp.
• Pieniądze niosą pokusę komercjalizacji i centralizacji –
pomimo tego staraj się trwać jako luźno związana grupa
• Pieniądze nie kupią lojalności deweloperów – jeżeli podoba
im się to co robią to zostaną, jeżeli nie to odejdą
• Nie zmieniaj natury projektu (np. licencji) w trakcie pracy
Tomasz Boiński: 81
Inne rodzaje wsparcia
•
•
•
•
Dotacje w postaci sprzętu
Dotacje w postaci łącza
Pomoc zespołów testowych
Pomoc prawna
– Programiści zazwyczaj orientują się w prawach autorskich, ale nie mają
czasu/wiedzy by śledzić patenty, znaki towarowe, aktualne prawo itp.
• Tworzenie dokumentacji
• Marketing – ale nie kłam w reklamie, łatwo jest
zweryfikować ich prawdziwość
• Nie pozwól na docinanie konkurencji, ani tej closed ani tej
open source
Tomasz Boiński: 82
A jak nasze oprogramowanie
wprowadzić do oficjalnych
repozytoriów dystrybucji?
Tomasz Boiński: 83
Włączanie oprogramowania do
dystrybucji Linuksa
Podstawowe wymagania:
– Jakość
– Wymogi prawne (licencje)
– Utrzymanie pakietów
Zazwyczaj dystrybucje dostarczają kompletnych wytycznych i
wymogów, jakie należy spełnić zanim oprogramowanie będzie
w ogóle mogło być traktowane jako kandydat do włączenia do
dystrybucji. W dalszej części zostanie to zaprezentowane na
przykłądzie dystrybucji Debian Linux
http://www.debian.org/doc/debian-policy/
Inne dystrybucje oferują podobne wytyczne, czasami
przyjmując bardziej swobodne podejście do
problematycznych pakietów, takich jak sterowniki binarne,
paczki z firmware itp.
Tomasz Boiński: 84
Aspekty prawne (1)
Z punktu widzenia inżyniera, jakość i funkcjonalność są
najważniejszymi aspektami kodu. Dla świata w równym, a
może i nawet większym stopniu liczą się także aspekty prawne
i to one stoją u podstaw polityki, jaką kieruje się dana
dystrybucja. Debian opiera się o:
“Celem Debiana jest dostarczenie wolnego systemu
operacyjnego, jednakże nie każdy program, jaki chcielibyśmy
do niego włączyć jest wolny w naszym rozumieniu tego słowa
lub może być włączany bez dodatkowych ograniczeń. Stąd
zbiór paczek podzielny jest na trzy fragmenty (main, contrib,
non-free), każdy grupujący pakiety pod względem licencji i
innych ograniczeń”
Tomasz Boiński: 85
Aspekty prawne (2)
W dalszej części ta polityka mówi:
“Celem takiego podziału jest:
• możliwość dostarczania tak wielu paczek jak tylko możliwe,
• możliwość zachęcania innych do tworzenia wolnego
oprogramowania
• uproszczenie tworzenia dystrybucyjnych płyt cd bez
konieczności naruszania jakichkolwiek licencji, ograniczeń
czy innych form prawnych.
Dystrybucja Debian GNU/Linux składa się tylko z części main
repozytorium!
Repozytoria contrib oraz non-free nie są traktowane jako
część dystrybucji, jednakże wspieramy je i dostaczamy dla
nich pełną infrastrukturę (jak np. system śledzenia błędów czy
listy mailingowe). ”
Tomasz Boiński: 86
Aspekty prawne (3)
Definicję wolnego oprogramowania dostarcza Free Software
Guidelines (DFSG):
• Wolność redystrybucji
• Dostępność kodu źródłowego
• Możliwość tworzenia dzieł pochodnych
• Dopuszczalny jest wymóg integralności kodu
• Brak dyskryminacji wobec osób, grup czy zastosowań
• Licencja musi być poprawnie rozpowszechniana
• Licencja nie może dotyczyć tylko Debiana
• Licencja nie może wymuszać niczego na innym oprogramowaniu
Przykładowo GPL, BSD itp. traktowane są jako wolne.
Tomasz Boiński: 87
Jakość (1)
Debian kieruje się następującą wytyczną: “Twój kod nie może
być na tyle zarobaczony, że nie chcemy go utrzymywać”. Poza
tym istnieje pewien zestaw standardów/wymagań, jakie kod
musi spełniać by trafił do dystrybucji.
Ważnym aspektem jest rozkład docelowych plików binarnych
zgodnie z Filesystem Hierarchy Standard (FHS)
http://www.pathname.com/fhs/
Dobrze jest kierować się tym standardem, gdy planujemy
rozkład plików, zdecydowanie upraszcza to pracę osoby
utrzymującej naszą paczkę.
Zwiększa to też zadowolenie użytkowników końcowych.
Tomasz Boiński: 88
Jakość (2)
W zależności od zastosowań, może być konieczne spełnienie
dodatkowych zaleceń:
• Wsparcie dla MIME
• Poprawna integracja z Menu systemowym
• Zalecenia względem różnych języków programowania:
–
–
–
–
–
Java,
Python,
Perl,
PHP
Inne w zależności od potrzeb
• Zalecenia dla aplikacji webowych
• Położenie bibliotek, zmienne środowiskowe itp.
Tomasz Boiński: 89
Utrzymanie pakietów (1)
Dystrybucje określają własne zasady przekształcenia kodu w
paczkę włączaną do tej dystrybucji. W przypadku Debiana
jego Debian Developer's Reference mówi:
• Wymagana jest weryfikacja w liście o nazwie Work-Needing
and Prospective Packages (WNPP), czy ktoś już nie pracuje
nad stworzeniem paczki dla danego programu. Lista tę
można znaleźć tutaj: http://www.debian.org/devel/wnpp/
• Następnie należy zgłosić błąd w stosunku do pakietu
wirtualnego o nazwie 'wnpp' z priorytetem ustawionym
jako 'wishlist'. Zgłoszenie takie powinno zawierać opis
aplikacji, jej licencję oraz adres url, skąd można je pobrać.
• Następnie należy przesłać oprogramowanie z odpowiednimi
informacjami dodatkowymi.
Tomasz Boiński: 90
Utrzymanie pakietów (2)
Samo wprowadzenie oprogramowania do dystrybucji jest
tylko wstepem do dalszej pracy. Jako deweloper zobowiązani
jesteśmy do reagowania na różne zdarzenia, takie jak:
• Zgłoszenia błędów
• Poprawki bezpieczeństwa
• Porządkowanie zmian wprowadzonych do kodu
• Reagowanie na zmiany w głównej gałęzi programu lub
innych programów
• Pilnowanie spójności poprzez korektę zależności itp.
Niezbędne jest pewne doświadczenie w obsłudze narzędzi
kontroli wersji oraz śledzenia błędów
Tomasz Boiński: 91
Cykl rozwojowy dystrybucji Linuksa
na przykładzie Fedory
•
•
•
•
•
•
•
Czym jest dystrybucja Linuksa i projekt Fedora
Komunikacja
Planowanie wydan
Dokumentacja i szata graficzna
Zarzadzanie jakoscia
Opieka na paczkami
Infrastruktura sieciowa i aplikacyjna
Tomasz Boiński: 92
Czym jest dystrybucja Linuksa?
• Jądro linuksa
• Zestaw współpracującego ze sobą oprogramowania
pochodzącego z różnych projektów (pakiety)
• Instalator
• System zarządzania pakietami
• Dystrybucje mogą być bazą dla innych dystrybucji, a nawet
jedna dystrybucja może mieć wiele wersji.
Tomasz Boiński: 93
Projekt Fedora
„Projekt Fedora jest współpraca na szczeblu globalnym
członków społeczności wolnego oprogramowania.”
• RedHat sponsoruje infrastrukturę i tworzenie części
oprogramowania
• baza dla Red Hat Enterprise Linux
• krótki cykl wydawniczy
• kolejne wersje co pół roku
• składa się z wielu pod projektów oraz narzędzi
wspomagających silnie rozproszona prace zespołowa
Tomasz Boiński: 94
Struktura projektu
• Projekt Fedora składa się z:
– podprojektów
„Aby dana inicjatywa mogła otrzymać miano oficjalnego projektu,
musi wykazać się długofalowa zdolność do sprostania przeciwnościom
losu. Oznacza to, ze musi być opatrzona kompletna strategia
zarządzania projektem, w tym także schemat postępowania przy
rozwiązywaniu zależności kadrowych. Musi również zaprezentować
udokumentowane materiały i zasoby wykorzystywane w projekcie,
strategie komunikacji oraz udokumentowane procesy postępowania Od
tego typu projektów oczekuje się regularnych raportów z prac. Tylko
Rada Projektu Fedora (Fedora Project Board) może ogłaszać i
akceptować nowe projekty w ramach projektu Fedora.”
– grup zainteresowania (SIG — Special Interest Group)
Tomasz Boiński: 95
Special Interest Group
• SIG musi dostarczać regularnych raportów relacjonujących
postępy w następujących dziedzinach:
– Liczba aktywnych współpracowników i developerów
– Postępy w realizacji projektów i ich obecny stan względem wyznaczonych
celów
– Relacji projektu ze społecznością
– Bieżących zasad nadzorowania projektu
– Harmonogram drogi ku osiągnięciu zadeklarowanych celów
Tomasz Boiński: 96
Główne obiekty, projekty i role w
projekcie Fedora
• Pakiety
– Mają swojego właściciela
– Składają się z oryginalnego kodu źródłowego i zestawu patchy.
• Wydania
– mają określone cele wydania, plany nowych cech i terminarz
• Rada Fedory
– odpowiada za zarządzanie całością projektu i zmienia się co 2 wydania
(połowa rady powinna być zmieniona)
– główny szef projektu wyznaczany przez RedHata (ma prawo weta)
– 4 uczestników wyznaczanych przez RedHata
– 5 uczestników wybieranych ze społecznosci Fedory
• FESco Fedora Engineering Steering Committee
– odpowiada za akceptowanie nowych cech, grup zainteresowań,
podprojektów, procesu paczkowania aplikacji i innymi technicznymi
sprawami
Tomasz Boiński: 97
Komunikacja
•
•
•
•
•
•
•
•
listy dyskusyjne
IRC
fora dyskusyjne
strony społecznościowe
blogi uczestników projektu
wydarzenia (spotkania)
ambasadorzy
marketing
Tomasz Boiński: 98
Terminarz i planowanie
• Projekt ma ściśle zdefiniowane etapy, których osiągniecie
oznacza zrealizowanie dobrze zdefiniowanych celów oraz
określone konsekwencje w cyklu tworzenia dystrybucji.
– Development freeze - pakiety zostają zamrożone. Jedynie pakiety
naprawiające znaczące błędy mogą zostać dodane do drzewa pakietów
– Feature freeze - zamrożone zostają cechy nowego produktu. Na tym etapie
odrzucone zostają wszystkie niekompletne rozwiązania
– String freeze - zamrożone zostają wszelkie dane tekstowe pakietów
– Translation deadline - wszelkie tłumaczenia wykonane do tego momentu
maja zagwarantowane, ze trafia do finalnego wydania. Pakiety powinny po
tym terminie, a przed właściwym przeniesieniem ich do drzewa testowego,
zostać przekompilowane z uwzględnieniem tych tłumaczeń
– Beta freeze - zamrożenie wszystkich zmian aż do wydania wersji beta.
– Final Development freeze - zamrożenie wszystkich zmian aż do wydania
wersji finalnej.
– Release - udostępnienie społeczności Wraz z wydaniem wersji testowej
odmrożone zostaje drzewo testowe, a wraz z wydaniem wersji ostatecznej
odmrożone zostaje drzewo rozwojowe.
Tomasz Boiński: 99
Proces włączania nowych cech
(features) do Fedory
Jako propozycje nowych cech Fedory uznaje się:
• bardzo widoczne zmiany dla końcowego użytkownika
• zmiany, które wymagają integracji z wieloma pakietami
• „ekscytujące nowości”
• zmiany, których nieukończenie może spowodować
opóźnienie wydania
• rzeczy wystarczająco ważne by znaleźć się w informacjach o
wydaniu
Tomasz Boiński: 100
Zatwierdzanie nowych propozycji
Nowe cechy a cykl wydawniczy
• Strony opisujące cechy wydania powinny być aktualizowane
przed każdym z następujących wydań:
– Alpha Freeze
– Beta Freeze - cechy, które nie są w 100% zaimplementowane przed
wydaniem bety powinny być zaktualizowane nie później niż w przeciągu 2
tygodni
– Final Freeze - na tydzień przed Final Freeze wszystkie cechy wydania
zostana ocenione na podstawie bieżących informacji
• W momencie Final Freeze dokumentacja cech powinna być
wykonana w 100% i dostosowana do rzeczywistego zakresu
wykonanych prac
Nowe cechy a cykl wydawniczy (2)
• Feature Wrangler jest odpowiedzialny za wysyłanie
powiadomień do osób odpowiedzialnych za dane cechy za
pośrednictwem listy fedora-devel-announce
• Podsumowanie bieżącego stanu wszystkich cech zawarte jest
na stronie danego wydania wraz z odnośnikami do
krótkiego opisu danej cechy
– Za aktualizacje tej strony odpowiada Feature Wrangler
– Dla projektu Fedora strona ta znajduje sie pod adresem:
http://fedoraproject.org/wiki/Releases/<release_number>/FeatureList
• W przypadku braku aktualizacji strony cechy w
odpowiednim terminie informacja o tym w postaci
“delikatnej” umieszczana jest na liście [email protected] a odpowiedzialna za to osoba otrzymuje
“ostra” wersje w postaci wiadomości prywatnej
Ważne etapy cyklu życia nowej cechy
• Nowe cechy mogą być zgłaszane i akceptowane jedynie do
stadium Feature Freeze
• Do momentu wydania wersji Alpha:
– Opis cechy musi być wykonany i sformalizowany, by możliwe było jasne
określenie zakresu prac.
– Określone muszą zostać kryteria akceptacji bądź odrzucenia cechy.
• Do czasu Beta Freeze wykonany musi zostać plan oraz
procedury testów akceptacyjnych. W tym samym czasie
cecha musi być gotowa pod względem funkcjonalnym, by
możliwe było jej testowanie.
• W trakcie etapu Feature Freeze, Feature Wrangler
przekazuje do FESCo status wszystkich cech do
zaopiniowania.
• Po wydaniu opinii przez FESCo, Feature Wrangler
publikuje ostateczna listę cech.
Tworzenie informacji o wydaniu
• Tworzone z cząstek tematycznych („uderzeń” - „beats”),
którymi zajmują się ludzie odpowiedzialni za określone
cechy
• Zależnie od etapu cyklu wydawniczego maja formę krótkich
stron WIKI lub są konwertowane w odpowiedni dokument
HTML
• Po przygotowaniu dokumentu powstają jego tłumaczenia
(umieszczone na WWW)
• Na stronie projektu do każdego wydania tworzona jest
strona o najczęściej spotykanych błędów
Szata graficzna wydania
• Zbieranie pomysłów i koncepcji na nowy temat graficzny
• Przygotowanie roboczej wersji tapety i 3 pomocniczych
grafik (2 panoramiczne i jedna standardowa)
• Wybranie najładniejszego tematu i przygotowanie
potrzebnych grafik dla nowego wydania
Wyszukiwanie i naprawianie błędów
• Zanim wykonamy jakąkolwiek pracę należy rozważyć:
– Czy jest to błąd?
– Czy został przypisany do właściwego komponentu systemu i jego właściwej
wersji?
– Czy jest to nowy błąd czy duplikat wcześniej zgłoszonego?
– Czy są jakieś powiązane błędy?
– Czy błąd opisuje pojedynczy problem czy kilka problemów?
– Czy zgłoszenie dostarcza wystarczającej ilości informacji?
– Czy błąd jest na tyle poważny, ze uniemożliwia wydanie dystrybucji?
– Czy błąd jest trywialny w naprawie?
– Czy do zgłoszenia została dołączona łatka naprawiająca błąd?
– Czy ten błąd został już zgłoszony do twórcy danego komponentu?
– itp.
Dni testowania
• Są to imprezy organizowane dla użytkowników i
deweloperów
• Ważne nowe prace developerskie są testowane w „dni
testowania”
• Grupy zainteresowane dniami testowania najczęściej
przygotowują specjalne Live CD lub Live USB by pomóc
chętnym testerom
Opieka nad pakietami
• Każda paczka opiekuje się wyznaczona osoba lub grupa
ludzi (np. SIG)
• Istnieje lista, na które powinno się wpisywać terminy swojej
nieobecności
• Istnieje specjalna grupa sprawdzonych opiekunów
(provenpackagers), która ma prawa zapisu do CVS
wszystkich pakietów. Można wykluczyć wybrane paczki z
możliwości edycji przez grupę sprawdzonych opiekunów
• Sponsorzy pakietów to doświadczeni opiekunowie, którzy
prowadzą mniej doświadczonych opiekunów pakietów
• Oczekiwane terminy naprawiania paczek:
– 1 dzień - bardzo ważne rzeczy (np. niszczenie danych użytkowników)
– 2 - 14 dni - inne, trochę mniej ważne rzeczy
– 21 dni - irytujące błędy, ale nie powodujące strat danych
Rozwiązania komercyjne oparte o
Open Source
Niektóre projekty typu open source stanowią podstawę pdo
aplikacje komercyjne. Otwarte oprogramowanie jest również
powszechnie wykorzystywane w zastosowaniach domowych
jak i niekomercyjnych. Ponadto wiele dystrybutorów i
usługodawców wykorzystuje otwarte frameworki, moduły czy
biblioteki w swoich komercyjnych, nastawionych na zysk
usługach i produktach.
Z punktu widzenia taka działalność jest opłacalna. Klienci
chętnie płacą za ochronę prawną (np. przed roszczeniami
wynikającymi z naruszeń prawa autorskiego) oraz
„gwarancję” wsparcia technicznego w określonym czasie w
połączeniu z innowacyjnością oraz niezależnością płynącą za
Open Source.
Open Source (2) – modele biznesowe
Wymóg większości licencji, by dzieła pochodne rozpowszechniać na
identycznej licencji zmusił firmy do opracowania mechanizmów
umożliwiających realizację ich modelu biznesowego:
• Podwójne licencjonowanie – kod jest rozpowszechniany równolegle
zarówno na licencji otwartej jak i komercyjnej. Dostawcy zazwyczaj
pobierają opłaty za dodatkową funkcjonalność obecną w wersji
zamkniętej, dodatkową dokumentację, testy, ochrone prawną czy
wsparcie techniczne.
• Rozszerzenie funkcjonalności – otwarty framework czy biblioteka,
zainstalowana na komputerze użytkownika odrębnie w stosunku do
komercyjnej aplikacji, która to wykorzystuje możliwości otwartego
oprogramowania (jednakże została dostarczona bez otwartego
komponentu). Opłata pobierana jest zazwyczaj za usługę dodaną –
wsparcie nie obejmuje otwartego komponentu.
Open Source (3) – modele biznesowe
• Oprogramowanie jako usługa – dostawca pobiera opłaty za świadczona
usługę a nie samo oprogramowanie, które nigdy nie jest dostarczane do
klienta. Zazwyczaj opłata jest w postaci miesięcznej opłaty
abonamentowej umożliwiającej dostęp do usługi.
• Pobieranie opłat za wsparcie techniczne, szkolenia, porady – płatne jest
wsparcie dla oprogramowania a nie samo oprogramowanie. Dostawcy
zazwyczaj pobierają roczne opłaty za wsparcie techniczne, opłaty per
studenta za szkolenia czy opłaty za usługę konsultingową.
• Dochód z reklamy – dostawca, zazwyczaj strony WWW, posiada
dochód wnoszony przez reklamodawców ogłaszających się na danej
stronie, która jest wytworzona za pomocą otwartych komponentów.
Każdy z tych modeli biznesowych ma za zadanie ujęcie międzynarodowego
charakteru społeczności open source, której rozmiar zazwyczaj przekracza
rozmiar możliwy do uzyskania w przypadku zamkniętego
oprogramowania. W przypadku OS, liczba osób płacących za rozwiązanie
wynosi zazwyczaj poniżej 1% osób, które otwarte rozwiązanie stosują,
więc, by uzyskać zysk, szczególnie istotna jest redukcja kosztów
dystrybucji oraz poleganie na efekcie skali.
Open Source (4) – przykłady
Krótka lista:
Compiere – oprogramowanie ERP i CRM.
Open/Libre/Star/Novell Office – pakiet biurowy.
Red Hat Linux – komercyjna dystrybucja Linuksa.
SUSE Linux Enterprise Server / Desktop – inna komercyjna
dystrybucja Linuksa.
OpenWorkbench – zarządzanie projektem.
Db4o – ODBMS.
Rational Application Developer – narzędzia wspierające
wytwarzanie oprogramowania dostarczane przez IBM, a
oparte o Eclipse.
Open Source (4) – podsumowanie
Trwa debata, czy dostawcy rzeczywiście mają dochody z
działalności opartej o OS. Z punktu widzenia tradycyjnego
biznesu może to być jednak niewłaściwie zadane pytanie.
Większość dużego otwartego oprogramowania jest
sponsorowana przez firmy takie jak IBM czy Oracle, których
celem nie jest przychód z licencji. Motywacje działań takich
firm bardziej opierają się na redukcji wpływu konkurencji na
rynek oraz dostępności gotowych komponentów, z których
mogą tworzyć większe usługi. W przypadku mniejszych firm,
zastosowanie OS wiąże się raczej z tworzeniem lojalnej bazy
użytkowników, przekładającej się na wartość firmy w oczach
większych graczy, niż bezpośredniemu dochodowi ze
sprzedaży.
Standardy
• Co powoduje, że różne rozwiązania mogą współpracować ze
sobą?
–
–
–
–
Wspólne interfejsy
Protokoły
Oczekiwane zachowanie
Itp.
• Organizacje zajmujące się tworzeniem standardów
–
–
–
–
Internet Engineering Task Force: RFC oraz STD
ISO
W3C
inne
RFC oraz STD
• RFC jest to memorandum publikowanym przez Internet
Engineering Task Force (IETF)
• Opisuje działanie, zachowanie, badania naukowe czy
innowacje mające wpływ na działanie sieci Internet i
opartych o nią systemów
• Nie w pełni formalna forma standaryzacji, propozycje w
postaci Internet Drafts mogą być zgłaszane bez wsparcia
jakiejkolwiek zewnętrznej organizacji
• RFC są bazą dla Internet Standards (STD)
• Każde RFC jest statyczne, każda zmiana to nowe RFC
• RFC można oznaczyć tagami: informative, experimental,
best known practice, unknown, historic, deprecate, obsolete,
obsoleted
• Freely available at http://www.rfc-editor.org/
Droga do Internet Standard
• Krok 1: Internet Draft
–
–
–
–
–
Jest to pewien zestaw roboczych dokumentów opublikowanych przez IETF
Oczekuje się odniesienia do podstawowych wymagań stawianych RFC
Ważność dokumentów ograniczona jest do 6 miesięcy
W dowolnym momencie mogą być zmienione czy usunięte
Po wygaśnięciu są całkowicie usuwane z repozytorium IETF
• Krok 2: RFC oraz Proposed Standard
–
–
–
–
–
Internet Draft przekształcany jest w RFC
Nie może zostać usunięty czy zmodyfikowany
Dobrze opisuje znane problemy implementacyjne
Zasada działania jest dobrze rozumiana
Zebrał dobre opinie w społeczności, jest uznawany za wartościowy
Droga do Internet Standard (2)
• Krok 3: Draft Standard
– Istnieją przynajmniej dwie niezależne, ale współpracujące ze sobą
implementacje oparte o niezależnie rozwijany kod
– Dla tych implementacji zebrano wystarczająca ilość doświadczenia
– Traktowany jako ostateczna specyfikacja, ew. zmiany będą wprowadzać
jedynie poprawki wynikające z nowonapotkanych problemów
– Producenci na tym etapie mogą z powodzeniem implementować rozwiązanie
w wrażliwych aplikacjach
• Krok 4: Standard
– Zgromadzono znaczne doświadczenie oraz powstało wiele implementacji
– Duża dojrzałość techniczna propozycji
– Rozwiązane problemy interoperacyjności w Internecie poprzez definicje
protokołów, formatów komunikatów, języków itp.
– Najistotniejsze z standardów są te, które definiują protokół IP
International Organization for
Standardization (ISO)
• Międzynarodowe ciało standaryzujące, składające się z
reprezentantów narodowych organizacji standaryzujących
• Publikuje różne dokumenty:
–
–
–
–
–
Standardy
Raporty techniczne
Specyfikacje
Przewodniki
Itp.
• Dokumenty wydane przez ISO są chronione prawem
autorskim. Za kopie większości pobierane są opłaty
• ISO poddane zostaje czasami krytyce, głównie za proces
standaryzacyjny formatu Office Open XML
W3C
• The World Wide Web Consortium (W3C) jest głównym
ciałem standaryzującym dla sieci World Wide Web
• 5 poziomów stadaryzacji:
–
–
–
–
–
Working Draft (WD)
Last Call Working Draft
Candidate Recommendation (CR)
Proposed Recommendation (PR)
W3C Recommendation (REC)
• Rekomendacje mogą być korygowane poprzez Erraty
• W3C pozostawia producentom wolną rękę w przestrzeganiu
rekomendacji
• Odpowiedzialni za HTML, XML, XHTML, SOAP etc.
OASIS
• The Organization for the Advancement of Structured
Information Standards (OASIS)
• Jest globalnym konsorcjum rozwijającym, utrzymującym i
wdrażającym standardy e-biznesu i usług sieciowych
• Działają w następujących dziedzinach:
– Web Services, e-Commerce, Security, Law & Government, Supply Chain,
Computing Management, Application Focus, Document-Centric, XML
Processing, Conformance/Interop, and Industry Domains
• Odpowiedzialna za DocBook, OpenDocument, UDDI, WSBPEL, WSDM etc.
• OASIS zgadza się na standaryzację rozwiązań opartych o
licencjonowane czy opatentowane komponenty
Ecma International
• Ecma International (Ecma) jest międzynarodową prywatną
organizacją typu non-profit zajmującą się standaryzacją
systemów komunikacyjnych i informacyjnych
• Ich celem jest:
– Rozwijanie standardów i publikacja raportów technicznych w celu
upowszechnienia i ujednolicenia protokołów komunikacyjnych w systemach
informatycznych i elektronice użytkowej
– Zachęca do przestrzegania standardów
– Publikuje standardy i raporty w postaci papierowej i elektronicznej
• Publikacje wydane przez Ecma mogą być bezpłatnie
rozpowszechniane
• Odpowiedzialna za JavaScript, specyfikajcę języka C#,
Common Language Infrastructure (CLI), Office Open
XML, itp.
Mnogość standardów i organizacji
standaryzujących
OpenDocument
•
•
•
•
Proces standaryzacyjny wystartował 16.12.2002
Uznane przez OASIS 01.05.2005
Oparty o format XML znany z OpenOffice 1.0
Proces miał dwie fazy:
– Zapewnienie, że format OpenDocument będzie w stanie obsłużyć informacje
zapisane przez znaczną większość dotychczasowych systemów
– Skupienie się na współpracy opartej o Open Internet
• Przekazane do ISO SC na tzw. "Fast-Track Processing"
• 30ego listopada 2006 opublikowano ISO/IEC 26300:2006
Information technology – Open Document Format for
Office Applications (OpenDocument) v1.0
• OASIS ukończyło pracę nad wersją 1.1 (jeszcze nie
przesłaną do ISO/IEC) oraz rozpoczęła pracę nad wersją 1.2
Office Open XML
• Proces został zapoczątkowany przez Ecma, format został
standardem Ecma (ECMA-376) 7ego Grudnia 2006
• Następnie został przekazany do ISO/IEC w trybie "FastTrack Processing", gdyż Ecma jest członkiem typu JTC-1
(Joint Technical Committee 1)
• Specyfikacja została sklasyfikowana przez ISO oraz IEC
jako DIS 29500 (Draft International Standard 29500)
Information technology – Office Open XML file formats
• Proces standaryzacyjny składał się z 3 etapów:
– Poszukiwanie sprzeczności
– Głosowanie
– Faza doprecyzowania głosów
Office Open XML (2)
• W fazie poszukiwania sprzeczności członkowie ISO oraz
IEC przekazali zauważone błędy i sprzeczności do JTC 1
• Podczas fazy głosowania członkowie ISO głosowali nad
przekazaną przez Ecma specyfikacją. Wraz z głosem
przekazywana była opinia oraz komentarze co do
dokumentacji itp.
• W ostatniej fazie zgłaszający propozycję standardu
wypowiadał się co do przekazanych uwag, a głosujący na tej
podstawie mieli prawo zmiany swojego głosu
Office Open XML (3)
• We wrześniu 2007 sto cztery kraje-członkowie ISO i IEC
przystąpiło do głosowania
• Wymagane jest by "P-members", którzy mają obowiązek
głosowania, w 66.67% byli za.
• W tej grupie za było 53% członków, co nie dało
wymaganego poziomu.
• Nie więcej niż 25% wszystkich głosów może być
negatywnych. Te wymaganie również nie zostało spełnione,
gdyż 26% głosów było negatywne.
• W wyniku powyższego proces wszedł w fazę
doprecyzowania głosów
Office Open XML (4)
• W odpowiedzi na uwagi zgłoszone w trakcie fazy głosowania
Ecma opublikowała dokument zatytułowany "Disposition of
Comments", który nawiązywał do 1,027 różnych
przesłanych uwag ("NB comments" (National Bodies))
• Dokument składał się z 1600 stron komentarzy i
proponowanych zmian
• Członkowie ISO oraz IEC mieli 6 tygodni na zapoznanie się
z dokumentem i ustosunkowaniem do niego. W tym czasie
mieli też okazję do uczestniczenia w nieformalnych
konferencjach organizowanych przez Ecma by móc
przedyskutować zmiany
• Integralną częścią ostatniej fazy jest Ballot Resolution
Meeting (BRM). To od ustaleń na nim poczynionych zależy
czy propozycja DIS 29500 zostanie zaakceptowana jako
standard czy nie.
Office Open XML (5)
• W trakcie tego spotkania 873 zaproponowane przez Ecma
zmiany poddane zostały dyskusji (spośród 1,027 przesłanych
odpowiedzi 154 proponowały brak zmiany)
– Z powodu ograniczenia czasowego wynoszącego 5 dni jedynie 20% spośród
tych zmian zostało przedyskutowane
– Pozostałe 80% podlegało jedynie głosowaniu bez przeprowadzenia dyskusji
– Głosowaniu podlegała każda zmiana z osobna, każdy z NB mógł
zaakceptować lub odrzucić zmianę bądź wstrzymać się od głosu
– Dzięki temu część aspektów standardu przeszło bez jakiejkolwiek debaty
• Następnie Project Editor przystępował do tworzenia finalnej
wersji specyfikacji
– Oryginalny wniosek traktowany był jako podstawa do zmian
– Nanoszone były zmiany, co do których wynik głosowania wskazywał na
akceptację
• NB miały 30 dni od BRM na ew. zmianę swojego stanowiska
w poprzednim głosowaniu
Office Open XML (6)
• Część członków zmieniła zwój głos, głównie na korzyść DIS
29500
• 2 kwietnia 2008, ISO oraz IEC oficjalnie ogłosiły przyjęcie
DIS 29500 jako standardu ISO/IEC
– 75 % spośród członków JTC 1 (P-members) wyraziło swoją aprobatę
– 14 % wszystkich członków było przeciw
• 4 (RPA, Brazylia, Indie oraz Wenezuela) kraje odwołały się
od tej decyzji, jednakże nie wpłynęło to na wynik
• Międzynarodowy standard ISO/IEC 29500:2008 został
opublikowany w listopadzie 2008
• Podgrupa ISO/IEC JTC1/SC34 przejęła obowiązki ciała
utrzymującego standard ISO/IEC 29500
Office Open XML (7)
• Cały proces wzbudził wiele kontrowersji
• W wielu krajach wykazano szereg naruszeń procedur
procesu standaryzacyjnego oraz silnego lobby ze strony
Microsoftu
• Przemysł informatyczny szeroko komentował standard i
debatował nad nimi. Jednakże rozmiar specyfikacji (6000
stron) uniemożliwia szybką i pełną ocenę propozycji.
• Przeciwnicy wskazywali również na zbytnie podobieństwo
nazwy "Office Open XML" do zarówno "OpenDocument"
jak i "OpenOffice"
• Oponowano również, że standard ISO opisu dokumentów
już istnieje, a ponadto ma zaledwie 867 stron realizując tą
samą funkcjonalność. W związku z tym nie ma potrzeby
ustanawiania kolejnego.
Plusy i minusy zarówno zamkniętego
jak i otwartego oprogramowania
Spojrzenie z dwu perspektyw: użytkownika i dewelopera.
Użytkownicy korzystają z tego co im najbardziej odpowiada.
W zależności od sytuacji zmienia się definicja słowa
„najbardziej” (osoba prywatna vs. małe przedsiębiorstwo vs.
duża korporacja).
Deweloperzy z kolei oczekują jasnym i przejrzystych
informacji o sposobach zastosowania technologii, co mogą
zrobić a co nie itp.
Przyszłość
• Ruch Open Source jest silniejszy niż kiedykolwiek
• Przestrzeganie standardów stało się popularne – nawet
najbardziej uparte rządy idą w kierunku standardów I
otwartości
• Otwarte oprogramowanie jest tak samo dojrzałem jak
zamknięte, część zamkniętego oprogramowania bazuje na
otwartym
• OS jest bazą dla wielu aplikacji, służy jako firmware dla
urządzeń itp.
• Pozostaje problem z patentami
• Problem z pozyskiwaniem funduszy
Bibliografia
•
•
•
•
•
•
Wikipedia, http://en.wikipedia.org
Free Software Foundation, http://www.fsf.org
Open Source Initiative, http://www.opensource.org
Eric S. Raymond, “The Cathedral and the Bazaar”
David A. Wheeler’s Personal Home Page, http://www.dwheeler.com/
Karl Fogel, Producing Open Source Software: How to Run a Successful
Free Software Project, http://www.producingoss.com/
• Fedora Project, http://fedoraproject.org
• Polish Copyright Law, from 4th February 1994 with later changes
• Rzeczpospolita,
http://www.rp.pl/artykul/64143,179350_Pobieranie_filmow_i_muzyki_to_nie_kradziez.html
• EPO, http://legal.european-patent-office.org/dg3/biblio/t030424eu1.htm
• The Debian GNU/Linux Project, http://www.debian.org/

Open Source

Transkrypt

Podobne dokumenty

Nazwa przedsiębiorstwa Adres Ulica Miescowość i kod pocztowy

Ćwiczenie 2 - Teleinformatyk

Przepisy prawa autorskiego

Licencja Joomla!

Prezentacja

Licencja Joomla! - Zakład Gospodarki Mieszkaniowej w Głogowie

odpowiedzi na pytania PN 377/14