Учим английский язык, читая классическую литературу.

Challenges in our future

Угрозы нашему будущему

We have proved our ability to develop a broad spectrum of free software. This does not mean we are invincible and unstoppable. Several challenges make the future of free software uncertain; meeting them will require steadfast effort and endurance, sometimes lasting for years. It will require the kind of determination that people display when they value their freedom and will not let anyone take it away.

Мы доказали нашу способность разработать широкий спектр свободного ПО. Но это не значит, что нас невозможно победить или остановить. Некоторые угрозы делают наше будущее неопределенным; чтобы достойно встретить их, могут потребоваться усилия и непоколебимость, возможно в течение нескольких лет. Нам потребуется уверенность, что люди продемонстрируют, как они ценят свою свободу и не отдадут ее никому.

The following four sections discuss these challenges.

Эти угрозы обсуждаются ниже.

Secret hardware

Засекречивание оборудования

Hardware manufacturers increasingly tend to keep hardware specifications secret. This makes it difficult to write free drivers so that Linux and XFree86 can support new hardware. We have complete free systems today, but we will not have them tomorrow if we cannot support tomorrow's computers.

Производители аппаратного обеспечения все активнее пытаются сохранить в тайне его спецификации. Это затрудняет разработку свободных драйверов, чтобы Linux и XFree86 могли работать с новым "железом". Сегодня мы располагаем полноценной свободной системой, но не будем иметь ее завтра, если не сможем поддерживать компьютеры, которые у нас будут.

There are two ways to cope with this problem. Programmers can do reverse engineering to figure out how to support the hardware. The rest of us can choose the hardware that is supported by free software; as our numbers increase, secrecy of specifications will become a self-defeating policy.

Есть два пути решить эту проблему. Программисты могут делать реконструкцию (reverse engineering) устройств, чтобы понять, как с ними работать. Все остальные в состоянии выбирать только те устройства, которые поддерживаются свободным ПО. С ростом нашего сообщества засекречивание спецификаций обернется против его инициаторов.

Reverse engineering is a big job; will we have programmers with sufficient determination to undertake it? Yes - if we have built up a strong feeling that free software is a matter of principle, and non-free drivers are intolerable. And will large numbers of us spend extra money, or even a little extra time, so we can use free drivers? Yes, if the determination to have freedom is widespread.

Реконструкция - сложная работа; найдем ли мы программистов, решимости которых хватит довести дело до конца? Да, если мы создадим в обществе стойкое убеждение, что свобода является делом принципа, и несвободные драйверы неприемлемы. И будет ли большинство из нас тратить дополнительные средства и, возможно, время, чтобы использовать свободный драйвер? Да, если решимость иметь свободу получит широкое распространение.

Non-free libraries

Несвободные библиотеки

A non-free library that runs on free operating systems acts as a trap for free software developers. The library's attractive features are the bait; if you use the library, you fall into the trap, because your program cannot usefully be part of a free operating system. (Strictly speaking, we could include your program, but it won't run with the library missing.) Even worse, if a program that uses the proprietary library becomes popular, it can lure other unsuspecting programmers into the trap.

Несвободная библиотека, используемая в свободной ОС, может стать ловушкой для разработчиков свободных программ. Привлекательные возможности этой библиотеки служили приманкой, если вы начинали пользоваться библиотекой, вы оказывались в западне, так как ваша программа уже не может быть частью свободной ОС. (Строго говоря, мы можем включить вашу программу в состав дистрибутива, но вы не сможете запустить ее в отсутствие библиотеки.) Что еще хуже, если такая программа завоюет популярность, это может завлечь в ловушку других ничего не подозревающих программистов.

The first instance of this problem was the Motif toolkit, back in the 80s. Although there were as yet no free operating systems, it was clear what problem Motif would cause for them later on. The GNU Project responded in two ways: by asking individual free software projects to support the free X toolkit widgets as well as Motif, and by asking for someone to write a free replacement for Motif. The job took many years; LessTif, developed by the Hungry Programmers, became powerful enough to support most Motif applications only in 1997.

Первым примером этой проблемы, проявившимся еще в 1980-е годы, был Motif. Хотя в те времена не было свободных ОС, было ясно что Motif создаст множество проблем позднее. Проект GNU ответил двумя путями: призывал разработчиков использовать в своих проектах альтернативные свободные библиотеки X widgets наряду с Motif, и обратился к желающим создать свободный заменитель Motif. Работа потребовала многих лет: LessTif, разработанный Hungry Programmers, приобрел возможности, достаточные для большинства Motif-приложений, лишь в 1997.

Between 1996 and 1998, another non-free GUI toolkit library, called Qt, was used in a substantial collection of free software, the desktop KDE.

Между 1996 и 1998 гг. другая несвободная библиотека компонент пользовательского интерфейса, называемая Qt, была использована в значительной коллекции свободных программ, оболочке KDE.

Free GNU/Linux systems were unable to use KDE, because we could not use the library. However, some commercial distributors of GNU/Linux systems who were not strict about sticking with free software added KDE to their systems - producing a system with more capabilities, but less freedom. The KDE group was actively encouraging more programmers to use Qt, and millions of new "Linux users" had never been exposed to the idea that there was a problem in this. The situation appeared grim.

Свободные системы GNU/Linux не могли применять KDE, поскольку не были в состоянии использовать библиотеку. В то же время, некоторые коммерческие дистрибьюторы GNU/Linux, которые не ограничивались исключительно свободным ПО, включали KDE в свои дистрибутивы, получая систему с большими возможностями, но с меньшей свободой. Группа разработчиков KDE активно поощряла все большее количество программистов использовать Qt, и миллионы новых "пользователей Linux" даже и не подозревали о проблеме, скрытой здесь. Ситуация была зловещей.

The free software community responded to the problem in two ways: GNOME and Harmony.

Ответом общества свободного ПО были GNOME и Harmony.

GNOME, the GNU Network Object Model Environment, is GNU's desktop project. Started in 1997 by Miguel de Icaza, and developed with the support of Red Hat Software, GNOME set out to provide similar desktop facilities, but using free software exclusively. It has technical advantages as well, such as supporting a variety of languages, not just C++. But its main purpose was freedom: not to require the use of any non-free software.

GNOME (Модель Сетевой Объектной Среды GNU, GNU Network Object Model Environment) является проектом создания GNU-десктопа. Начатый в 1997 Мигелем де Иказа (Miguel de Icaza) и разрабатываемый при поддержке Red Hat Software, GNOME будет поддерживать схожие со своими аналогами возможности, но исключительно при помощи свободного ПО. У него есть и технические преимущества, такие, как поддержка широкого спектра языков, не только C++. Но главной целью была свобода - исключение зависимости от несвободных программ.

Harmony is a compatible replacement library, designed to make it possible to run KDE software without using Qt.

Harmony - это библиотека, предназначенная для работы с программами KDE не используя Qt.

In November 1998, the developers of Qt announced a change of license which, when carried out, should make Qt free software. There is no way to be sure, but I think that this was partly due to the community's firm response to the problem that Qt posed when it was non-free. (The new license is inconvenient and inequitable, so it remains desirable to avoid using Qt.)

В ноябре 1998 г. разработчики Qt объявили об изменении своей лицензии, которое должно сделать Qt свободным ПО. Нельзя утверждать наверняка, но я считаю, что отчасти это следствие жесткой реакции общества на проблемы, созданные Qt, когда она была несвободной. (Новая лицензия неудобна и неуравновешена, так что по-прежнему желательно избегать использования Qt.)

[Subsequent note: in September 2000, Qt was rereleased under the GNU GPL, which essentially solved this problem.]

[]

How will we respond to the next tempting non-free library? Will the whole community understand the need to stay out of the trap? Or will many of us give up freedom for convenience, and produce a major problem? Our future depends on our philosophy.

Как мы ответим на очередную соблазнительную несвободную библиотеку? Сможет ли общество понять необходимость обойти эту ловушку? Или многие из нас предпочтут удобство свободе, создав тем самым серьезную проблему? Наше будущее зависит от нашей философии.

Software patents

Программные патенты

The worst threat we face comes from software patents, which can put algorithms and features off limits to free software for up to twenty years. The LZW compression algorithm patents were applied for in 1983, and we still cannot release free software to produce proper compressed GIFs. In 1998, a free program to produce MP3 compressed audio was removed from distribution under threat of a patent suit.

Серьезнейшей угрозой для нас являются патенты, которые лишают разработчиков свободного ПО права использовать алгоритмы и возможности на срок до 20 лет. Патенты на алгоритм сжатия LZW были выданы в 1983, и мы по-прежнему не можем выпустить свободное ПО, генерирующее правильные файлы формата GIF. В 1998 свободная программа сжатия аудиозаписей методом MP3 была исключена из дистрибутива под угрозой патентного иска.

There are ways to cope with patents: we can search for evidence that a patent is invalid, and we can look for alternative ways to do a job. But each of these methods works only sometimes; when both fail, a patent may force all free software to lack some feature that users want. What will we do when this happens?

Существуют способы бороться с патентами: можно разыскать доказательства. что патент недействителен, а можно сделать работу другим путем. Но оба эти метода работают не всегда: когда оба они терпят неудачу, патент может лишить свободное ПО некоторых возможностей, которые требуются пользователям. Как они поступят в этом случае?

Those of us who value free software for freedom's sake will stay with free software anyway. We will manage to get work done without the patented features. But those who value free software because they expect it to be techically superior are likely to call it a failure when a patent holds it back. Thus, while it is useful to talk about the practical effectiveness of the "cathedral" model of development(1), and the reliability and power of some free software, we must not stop there. We must talk about freedom and principle.

Те из нас, кто ценит в свободном ПО его свободу, останется с нами в любом случае. Мы сделаем нашу работу, не используя патентованных возможностей. Но те, кто ценит свободное ПО за его техническое превосходство, вероятно, сочтут катастрофой ситуацию, когда патент лишит нас возможности конкурировать на равных. Поэтому недостаточно говорить о практической эффективности "соборной" ("cathedral") модели разработки программ, о надежности и богатых возможностях конкретных свободных программ. Мы также должны говорить о свободах и принципах.

Free documentation

Свободная документация

The biggest deficiency in our free operating systems is not in the software - it is the lack of good free manuals that we can include in our systems. Documentation is an essential part of any software package; when an important free software package does not come with a good free manual, that is a major gap. We have many such gaps today.

Наиболее дефицитной составляющей свободных операционных систем является на сегодня не программное обеспечение, а хорошие свободные руководства, которые могут включаться в их состав. Многие из наших важнейших программ не полностью документированы. Документация представляет собой неотъемлемую часть любого программного пакета; когда важный свободный программный продукт ее не имеет, в этом его основной недостаток. На сегодня мы имеем много подобных прорех.

Free documentation, like free software, is a matter of freedom, not price. The criterion for a free manual is pretty much the same as for free software: it is a matter of giving all users certain freedoms. Redistribution (including commercial sale) must be permitted, on-line and on paper, so that the manual can accompany every copy of the program.

Свобода документации, подобно свободному ПО, подразумевает свободу, а не цену. Критерии свободы документации примерно те же, что и свободного ПО: предоставляются ли пользователям определенные свободы. Дальнейшее распространение (включая коммерческое) должно разрешаться, так что руководство может сопутствовать каждой копии программы, причем как на бумаге, так и в электронном виде.

Permission for modification is crucial too. As a general rule, I don't believe that it is essential for people to have permission to modify all sorts of articles and books. For example, I don't think you or I are obliged to give permission to modify articles like this one, which describe our actions and our views.

Важной является также свобода модификации. Вообще говоря, я не считаю, что необходимо позволять каждому изменять все виды статей и книг. Продукт писательской деятельности может отличаться от ПО. Например, я не думаю, что вы или я обязаны давать разрешение модифицировать статьи, подобные этой, которые описывают наши действия и взгляды.

But there is a particular reason why the freedom to modify is crucial for documentation for free software. When people exercise their right to modify the software, and add or change its features, if they are conscientious they will change the manual too - so they can provide accurate and usable documentation with the modified program. A manual which does not allow programmers to be conscientious and finish the job, does not fill our community's needs.

Но есть одна ситуация, в которой свобода модификации критична для руководств по свободным программам. Когда люди реализуют свое право модифицировать программы, и добавляют либо изменяют их возможности, то если они добросовестны, эти изменения также будут отражены и в руководстве, так что документация будет точной и полезной для пользователей измененной программы. Руководство, запрещающее программистам проявить добросовестность и завершить работу, не удовлетворяет нужд нашего сообщества.

Some kinds of limits on how modifications are done pose no problem. For example, requirements to preserve the original author's copyright notice, the distribution terms, or the list of authors, are ok. It is also no problem to require modified versions to include notice that they were modified, even to have entire sections that may not be deleted or changed, as long as these sections deal with nontechnical topics. These kinds of restrictions are not a problem because they don't stop the conscientious programmer from adapting the manual to fit the modified program. In other words, they don't block the free software community from making full use of the manual.

Некоторые ограничения на проведение модификаций возражений не вызывают. Например, требование сохранить оригинальное уведомление об авторском праве, условия распространения или список авторов вполне обосновано. Также не является проблемой обязательно сообщать для измененных версий, что они были исправлены, либо даже определить целые разделы, которые не могут изменяться либо удаляться, если они затрагивают нетехнические вопросы. Такие разновидности ограничений не создают проблем, так как они не препятствуют добросовестным программистам в адаптации руководства к измененной программе. Другими словами, они позволяют нашему сообществу извлечь из документации максимум пользы.

However, it must be possible to modify all the *technical* content of the manual, and then distribute the result in all the usual media, through all the usual channels; otherwise, the restrictions do obstruct the community, the manual is not free, and we need another manual.

В то же время, должна быть возможной модификация всего технического содержимого руководства и дальнейшее распространение результата на общепринятых носителях и через стандартные каналы. В противном случае ограничения идут во вред обществу, документация не является свободной и требуется другая.

Will free software developers have the awareness and determination to produce a full spectrum of free manuals? Once again, our future depends on philosophy.

Найдут ли разработчики свободного ПО достаточные знания и решимость, чтобы выпустить полный набор документации? И в этом случае наше будущее зависит от нашей философии.