Metodologia Open Source

Transkrypt

1 Metodologia Open Source dr inż. Tomasz Maria Boiński Tomasz Boiński: 1

2 Współautorzy dr inż. Mariusz Matuszek dr inż. Michał Piotrowski Tomasz Boiński: 2

3 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

4 Open Source - Wstęp Taken from Tomasz Boiński: 4

5 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

6 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

7 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

8 Open Source (3) Tomasz Boiński: 8 Taken from

9 Tomasz Boiński: 9 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.

10 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. Tomasz Boiński: 10

11 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

12 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

13 Działalność FSF (2) The Free Software Directory - 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 ( oraz Tomasz Boiński: 13

14 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

15 Tomasz Boiński: 15 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 i 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

16 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

17 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." Tomasz Boiński: 17

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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 Tomasz Boiński: 26 mark) ( )

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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: Tomasz Boiński: 34

35 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

36 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

37 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

38 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

39 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

40 EULA problem (2) Taken from Tomasz Boiński: 40

41 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

42 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

43 Tomasz Boiński: 43 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

44 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

45 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

46 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

47 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

48 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 ( 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

49 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

50 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

51 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

52 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

53 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

54 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

55 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

56 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

57 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

58 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

59 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

60 Tomasz Boiński: 60 I wiele wiele innych...

61 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

62 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

63 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

64 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

65 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

66 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

67 Tomasz Boiński: 67 Wojna patentowa

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 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

76 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

77 Tomasz Boiński: 77 No ok, mamy projekt. Co teraz? :)

78 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ć 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

79 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

80 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

81 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

82 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

83 Tomasz Boiński: 83 A jak nasze oprogramowanie wprowadzić do oficjalnych repozytoriów dystrybucji?

84 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 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

85 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

86 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

87 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

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

89 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

90 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: 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

91 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

92 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

93 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