summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/pl/udi.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/pl/udi.html')
-rw-r--r--talermerchantdemos/blog/articles/pl/udi.html199
1 files changed, 199 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/pl/udi.html b/talermerchantdemos/blog/articles/pl/udi.html
new file mode 100644
index 0000000..eea5145
--- /dev/null
+++ b/talermerchantdemos/blog/articles/pl/udi.html
@@ -0,0 +1,199 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
+
+<!--#include virtual="/server/header.pl.html" -->
+<!-- Parent-Version: 1.77 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Ruch Wolnego Oprogramowania a&nbsp;UDI - Projekt GNU - Free Software
+Foundation</title>
+
+<!--#include virtual="/philosophy/po/udi.translist" -->
+<!--#include virtual="/server/banner.pl.html" -->
+<h2>Ruch Wolnego Oprogramowania a&nbsp;UDI</h2>
+
+<p>
+Projekt zwany UDI (Uniform Driver Interface, Uniwersalny Interfejs
+Sterowników) stawia sobie za&nbsp;cel opracowanie jednolitego standardu
+interfejsu pomiędzy jądrami systemów operacyjnych a&nbsp;sterownikami
+urządzeń. Jak powinien się odnieść do&nbsp;tego pomysłu ruch wolnego
+oprogramowania?</p>
+<p>
+Jeśli wyobrazimy sobie rzeszę programistów systemów operacyjnych
+i&nbsp;projektantów sprzętu, współpracujących ze sobą na&nbsp;równych
+prawach, UDI (jeśli jest technicznie wykonalne) byłoby bardzo dobrym
+pomysłem. Dzięki niemu moglibyśmy napisać tylko jeden sterownik dla danego
+urządzenia, a&nbsp;wszyscy mogliby z&nbsp;niego korzystać. Umożliwiłoby to
+zwiększenie poziomu współpracy.</p>
+<p>
+Kiedy ten pomysł zastosujemy w&nbsp;realnym świecie, w&nbsp;którym istnieją
+zarówno wytwórcy wolnego oprogramowania, dążący do&nbsp;współpracy, jak
+i&nbsp;wytwórcy programów zastrzeżonych dążący do&nbsp;dominacji,
+konsekwencje są zupełnie inne. Żadna metoda wykorzystania UDI nie może
+przynieść pożytku światu wolnego oprogramowania. Jeśli w&nbsp;ogóle jakoś
+na&nbsp;nas wpłynie, to podzieli nas i&nbsp;osłabi.</p>
+<p>
+Gdyby Linux obsługiwał UDI i&nbsp;gdybyśmy zaczęli projektować nowe
+sterowniki do&nbsp;komunikowania się z&nbsp;Linuksem poprzez&nbsp;UDI, jakie
+byłyby tego skutki?</p>
+
+<ul>
+<li> Ludzie mogliby wykorzystywać w&nbsp;systemach Windows wolne, objęte GPL
+linuksowe sterowniki urządzeń.
+<p>
+To zmieniłoby na&nbsp;lepsze tylko sytuację użytkowników
+Windows&nbsp;&ndash; nam, użytkownikom wolnych systemów operacyjnych, nie
+dałoby nic. Owszem, bezpośredniej szkody też by nam nie przyniosło,
+ale&nbsp;programiści objętych licencją GPL wolnych sterowników mogliby
+poczuć się zniechęceni, widząc w&nbsp;jaki sposób wykorzystywana jest ich
+praca, a&nbsp;to byłoby bardzo źle. Włączanie tych sterowników
+do&nbsp;zastrzeżonego jądra mogłoby również naruszać warunki GNU
+GPL. Zwiększanie pokusy takiego postępowania, to igranie z&nbsp;ogniem.</p></li>
+
+<li> Ludzie mogliby wykorzystywać w&nbsp;systemach <a
+href="/gnu/linux-and-gnu.html">GNU/Linux</a> niewolne sterowniki
+z&nbsp;Windows.
+<p>
+Bezpośrednio nie wpływałoby to na&nbsp;liczbę sprzętu obsługiwanego przez
+wolne oprogramowanie. Lecz&nbsp;sprzyjałoby jej zmniejszaniu się pośrednio,
+przez podsuwanie pokusy milionom użytkowników GNU/Linuksa, którzy nie
+nauczyli się jeszcze dla własnego dobra obstawać przy wolności. Im bardziej
+społeczność zaczęłaby ulegać pokusie, tym bardziej przesuwalibyśmy się
+w&nbsp;kierunku korzystania z&nbsp;niewolnych sterowników zamiast pisania
+wolnych.</p>
+<p>
+Samo w&nbsp;sobie UDI nie przeszkadza w&nbsp;rozwoju wolnych
+sterowników. Tak więc, jeśli wystarczająco wielu z&nbsp;nas odrzuci pokusę,
+nadal będziemy mogli rozwijać wolne sterowniki mimo istnienia UDI, dokładnie
+tak samo jak robimy to bez&nbsp;UDI.</p>
+<p>
+Ale&nbsp;dlaczego mielibyśmy zachęcać społeczność, żeby stała się słabsza
+niż być powinna? Czemu mielibyśmy stwarzać niepotrzebne trudności przyszłemu
+rozwojowi wolnego oprogramowania? Skoro UDI niczego dobrego nam nie
+przynosi, lepiej je odrzucić.</p></li>
+</ul>
+
+<p>
+Biorąc pod&nbsp;uwagę konsekwencje, nie jest żadną niespodzianką,
+że&nbsp;popierający UDI Intel zaczął ogłaszać, iż &bdquo;ma nadzieję,
+że&nbsp;społeczność Linuksa pomoże przy pracy
+nad&nbsp;UDI&rdquo;. W&nbsp;jaki sposób bogata i&nbsp;egoistyczna spółka
+może podchodzić do&nbsp;wspólnoty opartej na&nbsp;współpracy? Prosząc
+o&nbsp;jałmużnę, oczywiście. Prosząc nas nie mają nic do&nbsp;stracenia,
+a&nbsp;gdybyśmy nie mieli się na&nbsp;baczności, moglibyśmy się zgodzić.</p>
+<p>
+Współpraca z&nbsp;UDI nie jest wykluczona. Nie powinniśmy UDI, Intelowi
+czy&nbsp;komukolwiek innemu przylepiać etykietki Zła
+Wcielonego. Lecz&nbsp;za każdym razem zanim weźmiemy udział
+w&nbsp;proponowanym nam interesie, musimy starannie go ocenić, żeby upewnić
+się, że&nbsp;jest korzystny dla społeczności wolnego oprogramowania,
+a&nbsp;nie tylko dla rozwijających programy zastrzeżone. W&nbsp;tej
+konkretnej sprawie oznacza to wymaganie, aby&nbsp;ta współpraca zaprowadziła
+nas o&nbsp;krok dalej na&nbsp;drodze prowadzącej do&nbsp;ostatecznego celu
+wolnych jąder systemowych i&nbsp;sterowników: obsługi <em>wszelkiego</em>
+ważnego sprzętu przez wolne sterowniki.</p>
+<p>
+Jednym ze sposobów na&nbsp;to, żeby interes był udany może być
+zmodyfikowanie samego projektu UDI. Eric Raymond zaproponował, żeby zgodność
+z&nbsp;UDI obejmowała wymóg, że&nbsp;sterownik musi być wolnym
+oprogramowaniem. Tak byłoby idealnie, ale&nbsp;wchodzą w&nbsp;grę także inne
+możliwości. Wystarczyłoby wymaganie, żeby opublikowano kod źródłowy
+sterownika, by nie był tajemnicą handlową&nbsp;&ndash; gdyż nawet jeśli taki
+sterownik nie jest wolny, to przynajmniej dzięki temu dowiemy się tego,
+czego potrzebujemy do&nbsp;napisania wolnego sterownika.</p>
+<p>
+Intel mógłby także poza UDI zrobić coś, co pomogłoby społeczności wolnego
+oprogramowania rozwiązać ten program. Dajmy na&nbsp;to, istnieją pewnego
+rodzaju certyfikaty, którymi są zainteresowani konstruktorzy sprzętu,
+a&nbsp;Intel bierze udział w&nbsp;ich przyznawaniu. Jeśli tak, to mógłby
+przystać na&nbsp;wprowadzenie utrudnień w&nbsp;certyfikacji,
+w&nbsp;przypadku jeżeli&nbsp;specyfikacja sprzętu jest tajna. Nie
+rozwiązałoby to zapewne problemu całkowicie, ale&nbsp;sporo mogłoby pomóc.</p>
+<p>
+Jedną z&nbsp;trudności przy porozumieniu z&nbsp;Intelem na&nbsp;temat UDI
+jest fakt, że&nbsp;mielibyśmy wykonać naszą część na&nbsp;rzecz Intela
+na&nbsp;samym początku, podczas gdy oni spłacaliby ją przez długi
+okres. W&nbsp;praktyce, udzielalibyśmy Intelowi kredytu. Lecz&nbsp;czy
+kontynuowałby spłatę pożyczki? Prawdopodobnie tak, jeśli mielibyśmy to
+na&nbsp;piśmie, bez&nbsp;luk prawnych, w&nbsp;przeciwnym razie nie możemy
+na&nbsp;to liczyć. Powszechnie wiadomo, że&nbsp;korporacje są niegodne
+zaufania: ludzie, z&nbsp;którymi się umawiamy, mogą być porządni,
+ale&nbsp;stojący ponad nimi mogą uchylić ich decyzje, a&nbsp;nawet
+w&nbsp;dowolnej chwili wymienić ich na&nbsp;innych ludzi. Nawet dyrektor
+naczelny firmy posiadający większość udziałów może zostać wymieniony
+w&nbsp;wyniku wykupienia spółki przez inną. Przy transakcjach
+z&nbsp;korporacją zawsze bierzcie wiążące zobowiązanie na&nbsp;piśmie.</p>
+<p>
+Nie wydaje się, żeby Intel zechciał zaoferować nam interes, który dawałby
+nam to, czego potrzebujemy. Faktycznie, UDI wydaje się być zaplanowane
+w&nbsp;celu ułatwienia utajniania specyfikacji.</p>
+<p>
+Niemniej jednak, niezamykanie drzwi nie szkodzi, dopóki uważamy na&nbsp;to,
+komu pozwalamy wejść.</p>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+ </div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.pl.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Wszelkie pytania dotyczące GNU i&nbsp;FSF prosimy kierować na&nbsp;adres <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Inne metody kontaktu
+z&nbsp;FSF można znaleźć na&nbsp;stronie <a
+href="/contact/contact.html">kontakt</a> <br /> Informacje o niedziałających
+odnośnikach oraz&nbsp;inne poprawki (lub propozycje) prosimy wysyłać
+na&nbsp;adres <a
+href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+Staramy się, aby&nbsp;tłumaczenia były wierne i&nbsp;wysokiej jakości,
+ale&nbsp;nie jesteśmy zwolnieni z&nbsp;niedoskonałości. Komentarze odnośnie
+tłumaczenia polskiego oraz&nbsp;zgłoszenia dotyczące chęci współpracy
+w&nbsp;tłumaczeniu prosimy kierować na&nbsp;adres <a
+href="mailto:www-pl-trans@gnu.org">www-pl-trans@gnu.org</a>. <br /> Więcej
+informacji na&nbsp;temat koordynacji oraz&nbsp;zgłaszania propozycji
+tłumaczeń artykułów znajdziecie na&nbsp;<a
+href="/server/standards/README.translations.html">stronie tłumaczeń</a>.</p>
+</div>
+
+<p>Copyright &copy; 1998 Richard M. Stallman</p>
+
+<p>Ta strona jest dostępna na&nbsp;<a rel="license"
+href="http://creativecommons.org/licenses/by-nd/3.0/us/">licencji Creative
+Commons Uznanie autorstwa-Bez utworów zależnych 3.0 Stany Zjednoczone</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.pl.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+Tłumaczenie: Wojciech Kotwica 2003; poprawki: Jan Owoc 2016.</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Aktualizowane:
+
+$Date: 2016/03/10 05:29:04 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+</body>
+</html>