<<<TOC / OBSAH  >>>ENCSEN/CSZVONP/T

4. Ownership and Open Source

4. Vlastnictví a "open source"

What does `ownership' mean when property is infinitely reduplicable, highly malleable, and the surrounding culture has neither coercive power relationships nor material scarcity economicsĹľ Co znamená "vlastnictví", když majetek je nekonečně duplikovatelný, vysoce tvárný a okolní kultura nemá ani donucovací mocenské vztahy a ani materiálně chudou ekonomiku?
Actually, in the case of the open-source culture this is an easy question to answer. The owner(s) of a software project are those who have the exclusive right, recognized by the community at large, to re-distribute modified versions. Skutečně, v případě "open-source" kultury je to jednoduchá otázka. Vlastníkem(ky) softwarového projektu jsou ti, kteří mají exkluzivní právo, uznávané široce komunitou, redistribuovat modifikované verze.
(In discussing `ownership' in this section I will use the singular, as though all projects are owned by some one person. It should be understood, however, that projects may be owned by groups. We shall examine the internal dynamics of such groups later in this paper.) (Při diskusi "vlastnictví" v této sekci budu používat singulár, jako by všechny projekty byly vlastněny nějakou jedinou osobou. Měli bychom však vzít na vědomí, že projekty mohou být vlastněny skupinami. Vnitřní dynamiku těchto skupin prozkoumáme později.)
According to the standard open-source licenses, all parties are equals in the evolutionary game. But in practice there is a very well-recognized distinction between `official' patches, approved and integrated into the evolving software by the publicly recognized maintainers, and `rogue' patches by third parties. Rogue patches are unusual, and generally not trusted . Podle standardů "open source" licencí, všechny strany jsou si rovné ve vývojové hře. Ale v praxi je velmi dobře rozeznáván rozdíl mezi "oficiálními" _patches_ (asi nejblíže "opravami", lepší český termín neznám), které jsou potvrzené a integrované do vyvíjeného softwaru veřejně uznávanými udržovateli softwaru, a mezi "samotářskými" _patches_, dodaných třetí osobou. Samotářské patches jsou neobvyklé a obecně se jim nedůvěřuje.
That public redistribution is the fundamental issue is easy to establish. Custom encourages people to patch software for personal use when necessary. Custom is indifferent to people who redistribute modified versions within a closed user or development group. It is only when modifications are posted to the open-source community in general, to compete with the original, that ownership becomes an issue. Veřejná redistribuce je základní prvek a je snadné jej zavést. Zvyk dodává lidem odvahu,, aby "patchovali" softwaru pro svou osobní potřebu, když je to potřeba. Zvyk je lhostejný lidem, kteří redistribují modifikované verze ve skupině vývojové nebo ve skupině uzavřených uživatelů. Pouze tehdy, když jsou modifikace poslány "open source" komunitě obecně, aby soutěžily s originálem, je vlastnictví na pořadu dne.
There are, in general, three ways to acquire ownership of an open-source project. One, the most obvious, is to found the project. When a project has only one maintainer since its inception and the maintainer is still active, custom does not even permit a question as to who owns the project. Obecně jsou tři způsoby, jak nabýt vlastnictví "open source" projektu. Jedna, nejzřejmější, je založit projekt. Když projekt má pouze jednoho udržovatele od svého počátku a udržovatel je stále aktivní, zvyk ani nedovoluje otázku, kdo vlastní projekt.
The second way is to have ownership of the project handed to you by the previous owner (this is sometimes known as `passing the baton'). It is well understood in the community that project owners have a duty to pass projects to competent successors when they are no longer willing or able to invest needed time in development or maintenance work. Druhá cesta je obdržet vlastnictví projektu předchozím vlastníkem (občas známo jako "předání žezla"). Komunita je dobře srozuměna s tím, že vlastníci projektu mají povinnost předat projekt úspěšným následníkům, pokud už si dále nepřejí nebo nemohou investovat potřebný čas do vývoje či údržbových prací.
It is significant that in the case of major projects, such transfers of control are generally announced with some fanfare. While it is unheard of for the open-source community at large to actually interfere in the owner's choice of succession, customary practice clearly incorporates a premise that public legitimacy is important. Je významné, že v případě hlavních projektů jsou přenosy řízení obecně ohlašovány s nějakými fanfárami. Zatímco není známo, že by široká "open source" komunita zasahovala do výběru následníka, obyklá praxe jasně zahrnuje premisu, že veřejná legitimita je důležitá.
For minor projects, it is generally sufficient for a change history included with the project distribution to note the change of ownership. The clear presumption is that if the former owner has not in fact voluntarily transferred control, he or she may reassert control with community backing by objecting publicly within a reasonable period of time. Pro malé projekty je obecně dostačující zahrnout změnu do historie, přiložené k distribuci projektu. Jasný předpoklad je, že pokud dřívější vlastník v podstatě neodevzdal kontrolu dobrovolně, může ji znovu získat s podporou komunity tim, že bude veřejně protestovat v nějakém rozumném čase.
The third way to acquire ownership of a project is to observe that it needs work and the owner has disappeared or lost interest. If you want to do this, it is your responsibility to make the effort to find the owner. If you don't succeed, then you may announce in a relevant place (such as a Usenet newsgroup dedicated to the application area) that the project appears to be orphaned, and that you are considering taking responsibility for it. Třetí cesta, jak získat vlastnictví projektu, je zpozorovat, že projekt potřebuje práci a vlastník zmizel nebo ztratil zájem. Pokud chcete udělat toto, je to vaše zodpovědnost, dát si práci s nalezením vlastníka. Když neuspějete, můžete oznámit na relevantním místě (jako např. Usenet newsgroup, určený pro danou oblast), že projetk nejspíš osiřel a že uvažujete o převzetí zodpovědnosti za něj.
Custom demands that you allow some time to pass before following up with an announcement that you have declared yourself the new owner. In this interval, if someone else announces that they have been actually working on the project, their claim trumps yours. It is considered good form to give public notice of your intentions more than once. More points for good form if you announce in many relevant forums (related newsgroups, mailing lists); and still more if you show patience in waiting for replies. In general, the more visible effort you make to allow the previous owner or other claimants to respond, the better your claim if no response is forthcoming. Zvyk vyžaduje, abyste nějakou dobu počkali, než se prohlásíte novým vlastníkem. Pokud někdo v této době oznámí, že skutečně pracovali na tom projektu, jejich nárok váš přebíjí. Patří k dobrému tónu oznámit vaše záměry více než jednou. Ještě slušnější je oznámit to na více fórech (patřičné newsgroups, mailing lists); a ještě lépe, pokud máte trpělivost čekat na odpovědi. Obecně, čím více dáte příležitosti, aby se předchozí vlastník či nějaký jiný zájemce ozval s odpovědí, tím silnější nárok budete mít, pokud žádná odpověď nepřijde.
If you have gone through this process in sight of the project's user community, and there are no objections, then you may claim ownership of the orphaned project and so note in its history file. This, however, is less secure than being passed the baton, and you cannot expect to be considered fully legitimate until you have made substantial improvements in the sight of the user community. Pokud jste prošli celým tímto procesem před očima uživatelské komunity tohoto projektu a nejsou žádné námitky, pak můžete prohlásit vlastnictví osiřelého projektu za své a označit je v souboru historie. Toto je však méně bezpečné, než obdržet žezlo a nemůžete očekávat uznání plné legitimity, pokud neuděláte zásadní zlepšení před očima uživatelské komunity.
I have observed these customs in action for twenty years, going back to the pre-FSF ancient history of open-source software. They have several very interesting features. One of the most interesting is that most hackers have followed them without being fully aware of doing so. Indeed, the above may be the first conscious and reasonably complete summary ever to have been written down. Pozoroval jsem tyto zvyky v akci během dvaceti let, zpátky k dávné historii "open source" softwaru před FSF. Mají několik zajímavých rysů. Jeden z nejdůležitějších je ten, že většina hackerů je dodržovala, bez toho aby si toho byla plně vědoma. Skutečně, výše uvedené řádky mohou být prvním vědomým a rozumně zkompletovaným souhrnem, který byl kdy napsán.
Another is that, for unconscious customs, they have been followed with remarkable (even astonishing) consistency. I have observed the evolution of literally hundreds of open-source projects, and I can still count the number of significant violations I have observed or heard about on my fingers. Další rys pro nevědomé zvyky je ten, že byly následovány s pozoruhodnou, až překvapující konsistencí. Pozoroval jsem doslova stovky "open source" projektů a počet významných porušení, která jsem viděl či o nich slyšel, mohou spočítat na prstech.
Yet a third interesting feature is that as these customs have evolved over time, they have done so in a consistent direction. That direction has been to encourage more public accountability, more public notice, and more care about preserving the credits and change histories of projects in ways which (among other things) establish the legitimacy of the present owners. Další zajímavý rys je, že jak se tyto zvyky vyvíjely v čase, dělo se to také v konzistentní linii. Toto řízení mělo za cíl podpořit větší veřejnou odpovědnost, větší veřejnou známost a větší péči o zachování kreditu a změn v historiích projektu tak, aby zajistily legitimitu současných vlastníků.
These features suggest that the customs are not accidental, but are products of some kind of implicit agenda or generative pattern in the open-source culture that is utterly fundamental to the way it operates. Tyto rysy naznačují, že zvyky nejsou náhodné, ale jsou produktem jakési implicitní agendy či plodného vzoru v "open source" kultuře, ????
An early respondent pointed out that contrasting the Internet hacker culture with the cracker/pirate culture (the ``warez d00dz'' centered around game-cracking and pirate bulletin-board systems) illuminates the generative patterns of both rather well. We'll return to the d00dz for contrast later in the paper. Porovnání Internetové hackerovské kultury s crackerskou/pirátskou kulturou ("warez d00dz" soustředěné kolem "crackování" her a pirátských vývěskových systémů) osvětluje plodné vzory v obou dosti dobře. Vrátíme se k d00dz pro kontrast později v tomto článku.

<<<TOC / OBSAH  >>>ENCSEN/CSZVONP/T