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) Taken from http://xkcd.com 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 Definicja Open Source (3) 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 Definicja Open Source (4) 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 Definicja Open Source (5) 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) Taken from http://xkcd.com 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 Tomasz Boiński: 101 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 Tomasz Boiński: 102 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 Tomasz Boiński: 103 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. Tomasz Boiński: 104 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 Tomasz Boiński: 105 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 Tomasz Boiński: 106 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. Tomasz Boiński: 107 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 Tomasz Boiński: 108 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 Tomasz Boiński: 109 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. Tomasz Boiński: 110 Rozwiązania komercyjne oparte o 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. Tomasz Boiński: 111 Rozwiązania komercyjne oparte o 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. Tomasz Boiński: 112 Rozwiązania komercyjne oparte o 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. Tomasz Boiński: 113 Rozwiązania komercyjne oparte o 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. Tomasz Boiński: 114 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 Tomasz Boiński: 115 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/ Tomasz Boiński: 116 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 Tomasz Boiński: 117 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 Tomasz Boiński: 118 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 Tomasz Boiński: 119 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. Tomasz Boiński: 120 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 Tomasz Boiński: 121 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. Tomasz Boiński: 122 Mnogość standardów i organizacji standaryzujących Taken from http://xkcd.com Tomasz Boiński: 123 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 Tomasz Boiński: 124 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 Tomasz Boiński: 125 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 Tomasz Boiński: 126 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 Tomasz Boiński: 127 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. Tomasz Boiński: 128 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 Tomasz Boiński: 129 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 Tomasz Boiński: 130 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. Tomasz Boiński: 131 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. Tomasz Boiński: 132 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 Tomasz Boiński: 133 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/ Tomasz Boiński: 134