1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/hackathons.en.html" -->
<!--#include virtual="/server/header.ru.html" -->
<!-- Parent-Version: 1.84 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title>На хакатонах нужно настаивать на свободных программах - Проект GNU - Фонд
свободного программного обеспечения</title>
<!--#include virtual="/philosophy/po/hackathons.translist" -->
<!--#include virtual="/server/banner.ru.html" -->
<h2>Почему на хакатонах надо настаивать на свободных программах</h2>
<p>Хакатоны — общепринятый метод предоставления поддержки проектам
цифровой разработки со стороны сообщества. Сообщество приглашает
разработчиков к участию в мероприятии, на котором в дружественной атмосфере
предлагаются какие-то полезные ресурсы, а также возможность поработать над
полезными задачами. В большинстве хакатонов на основании заявленных
критериев выбираются проекты, которым будет оказываться поддержка.</p>
<p>Хакатоны отвечают духу сообщества, в котором люди сотрудничают и уважают
друг друга. Программы, которые гармонируют с таким духом — это
свободные программы, <a href="/philosophy/free-sw.html">от слова
“свобода”</a>. Свободные программы отличаются лицензией, которая
дает всем их пользователям (в том числе программистам) свободу
сотрудничества. Таким образом, хакатоны имеют смысл в пределах сообщества
свободных программ. <a href="/philosophy/free-hardware-designs.html">Проекты
по разработке аппаратуры</a> также могут и должны быть свободны.</p>
<p>Уважение к свободе нельзя принимать как само собой разумеющееся. Напротив,
нас окружают компании, бессовестно выпускающие несвободные программы,
которыми дают пользоваться только тем, кто уступает власти этих
компаний. Эти компании разрабатывают программы как <a
href="/philosophy/free-software-even-more-important.html">средство
господства и контроля над людьми</a>.</p>
<p>Пагубный успех этих компаний побуждает молодых разработчиков следовать их
примеру, разрабатывая собственные программы или аппаратуру для господства
над пользователями. Иногда они приходят на хакатоны со своими проектами,
намереваясь получить поддержку сообщества, но отвергая в то же время дух
этого сообщества: они не собираются отвечать сотрудничеством на
сотрудничество. Хакатоны, которые допускают такое, подрывают дух сообщества,
на котором они основаны.</p>
<p>Некоторые извращенные хакатоны полностью посвящены помощи в обработке
информации конкретными компаниями: в некоторых случаях это <a
href="https://www.beyondhackathon.com/en">европейские</a> и <a
href="http://www.hackathon.io/rbc-digital">канадские банки</a>, а также <a
href="http://expediaconnectivity.com/blog#madrid-hackathon-winners">
Expedia</a>. Они прямо этого не говорят, однако судя по объявлениям, они
ставят целью содействие в разработке каких-то несвободных программ, а
участники приглашаются для помощи этим неблаготворительным проектам.</p>
<p>Эти примеры показывают, до чего могут докатиться хакатоны. Вернемся к более
обычному случаю хакатона, не чисто коммерческого, но допускающего проекты,
которые несвободны.</p>
<p>Когда разработчик приходит на хакатон с проектом и не говорит, будет ли
результат свободным, это не идет явно против духа сообщества, но подрывает
этот дух. Хакатоны должны укреплять дух сообщества, на котором они зиждутся,
настаивая на том, чтобы проекты хакатона брали обязательство выпускать
программы в соответствии с этим духом.</p>
<p>Это значит говорить разработчикам: “Итак, чтобы заслужить нашу
поддержку и помощь, вы должны согласиться дать сообществу свободно
пользоваться результатами вашего проекта, если вы вообще сочтете их
достаточно хорошими для пользования или публикации”.</p>
<p>Участвуя в хакатонах лично, вы можете поддержать этот принцип. Перед
присоединением к любому проекту на хакатоне спрашивайте: “Под какой
лицензией вы это опубликуете? Перед тем, как подключиться к разработке, я
хочу удостовериться, что эти программы будут свободны”. Если
разработчики проекта говорят, что они выберут лицензию позже, вы могли бы
ответить, что и вы подумаете об участии позже. Не стесняйтесь —
если этот разговор услышат другие, они, возможно, поступят так же.</p>
<p>Чтобы определить, какие лицензии свободны, см. <a
href="/licenses/license-list.html">список лицензий GNU</a>. Большинство
лицензий “открытого исходного текста” являются лицензиями
свободных программ, но <a
href="/philosophy/open-source-misses-the-point.html"> некоторые лицензии
открытого исходного текста не являются лицензиями свободных программ, потому
что они слишком ограничительны</a>.</p>
<p>Твердость отдельных людей приводит к своим результатам, но правила самого
хакатона сказываются еще больше. Хакатоны должны просить каждый
проект-участник обязаться следовать правилу:</p>
<blockquote>
<p>Если вы когда-нибудь выпустите или используете эту программу или схему, вы
выпустите ее исходный текст под свободной лицензией. Если вы будете
распространять программу в исполняемом виде, вы также сделаете ее свободной.</p>
</blockquote>
<p>Многие хакатоны финансируются учебными заведениями или проводятся в них, и
это еще один довод в пользу этого правила. Свободные программы представляют
вклад в знания общества, а несвободные программы удерживают знания от
общества. Таким образом, <a href="/education/edu-schools.html">свободные
программы поддерживают дух просвещения, а несвободные противостоят
ему</a>. Учебные заведения должны настаивать на том, чтобы все развиваемые в
них программы были свободными, в том числе и на хакатонах, которым учебное
заведение оказывает поддержку.</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.ru.html" -->
<div id="footer">
<div class="unprintable">
<p>Пожалуйста, присылайте общие запросы фонду и GNU по адресу <a
href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Есть также <a
href="/contact/">другие способы связаться</a> с фондом. Отчеты о
неработающих ссылках и другие поправки или предложения можно присылать по
адресу <a href="mailto:webmasters@gnu.org"><webmasters@gnu.org></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">
<web-translators@gnu.org></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>. -->
Мы старались сделать этот перевод точным и качественным, но исключить
возможность ошибки мы не можем. Присылайте, пожалуйста, свои замечания и
предложения по переводу по адресу <a
href="mailto:web-translators@gnu.org"><web-translators@gnu.org></a>.
</p><p>Сведения по координации и предложениям переводов наших статей см. в
<a href="/server/standards/README.translations.html">“Руководстве по
переводам”</a>.</p>
</div>
<!-- Regarding copyright, in general, standalone pages (as opposed to
files generated as part of manuals) on the GNU web server should
be under CC BY-ND 4.0. Please do NOT change or remove this
without talking with the webmasters or licensing team first.
Please make sure the copyright date is consistent with the
document. For web pages, it is ok to list just the latest year the
document was modified, or published.
If you wish to list earlier years, that is ok too.
Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
years, as long as each year in the range is in fact a copyrightable
year, i.e., a year in which the document was published (including
being publicly visible on the web or in a revision control system).
There is more detail about copyright years in the GNU Maintainers
Information document, www.gnu.org/prep/maintain. -->
<p>Copyright © 2017 Richard Stallman</p>
<p>Это произведение доступно по <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.ru">лицензии
Creative Commons Attribution-NoDerivs (<em>Атрибуция — Без
производных произведений</em>) 4.0 Всемирная</a>.</p>
<!--#include virtual="/server/bottom-notes.ru.html" -->
<div class="translators-credits">
<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
<em>Внимание! В подготовке этого перевода участвовал только один человек. Вы
можете существенно улучшить перевод, если проверите его и расскажете о
найденных ошибках в <a
href="http://savannah.gnu.org/projects/www-ru">русской группе переводов
gnu.org</a>.</em></div>
<p class="unprintable"><!-- timestamp start -->
Обновлено:
$Date: 2018/02/27 18:30:30 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
