Программы GNU. Мир лицензий: разбираемся с GNU GPL
make предназначена для отслеживания зависимостей одних файлов от других, выявления "устаревших" файлов при помощи сравнения времен модификации файлов и выполнения команд для "обновления" устаревших файлов. Позволяет автоматизировать процессы трансляции, компоновки, запуска модульных тестов и развертывания системы за счет описания соответствующих сценариев на специальном языке
Сценарии Make описываются в т.н. файле проекта. Проектом называется совокупность файлов, зависящих друг от друга. Файл описания проекта перечисляет зависимости между файлами и задает команды для обновления зависимых файлов. Имя файла описания проекта задается опцией –f командной строки программы make и по умолчанию предполагается равным Makefile или makefile . Если имя файла проекта явно не задано, при запуске утилита ищет в текущем каталоге файл с указанными выше именами, и, если такой файл существует, выполняет команды из него.
по описанию проекта в файле Makefile или makefile программа make определяет, какие файлы устарели и нуждаются в обновлении и запускает соответствующие команды.
Обычно программы на языках Си или Си++ представляют собой совокупность нескольких.c (.cpp) файлов с реализациями функций и.h файлов с прототипами функций и определениями типов данных. Как правило, каждому.c файлу соответствует.h файл с тем же именем.
Предположим, что разрабатываемая программа называется earth и состоит из файлов arthur.c, arthur.h, trillian.c, trillian.h, prosser.c, prosser.h.
Разработка программы ведется в POSIX-среде с использованием компилятора GCC.
Простейший способ скомпилировать программу - указать все исходные.c файлы в командной строке gcc:
Gcc arthur.c trillian.c prosser.c -o earth
Компилятор gcc выполнит все этапы компиляции исходных файлов программы и компоновку исполняемого файла earth. Обратите внимание, что в командной строке gcc указываются только.c файлы и никогда не указываются.h файлы.
Компиляция и компоновка при помощи перечисления всех исходных файлов в аргументах командной строки GCC допустима лишь для совсем простых программ. С ростом числа исходных файлов ситуация очень быстро становится неуправляемой. Кроме того, каждый раз все исходные файлы будут компилироваться от начала до конца, что в случае больших проектов занимает много времени. Поэтому обычно компиляция программы выолняется в два этапа: компиляция объектных файлов и компоновка исполняемой программы из объектных файлов. Каждому.c файлу теперь соответствует объектный файл, имя которого в POSIX-системах имеет суффикс.o. Таким образом, в рассматриваемом случае программа earth компонуется из объектных файлов arthur.o, trillian.o и prosser.o следующей командой:
Gcc arthur.o trillian.o prosser.o -o earth
Каждый объектный файл должен быть получен из соответствующего исходного файла следующей командой:
Gcc -c arthur.c
Обратите внимание, что явно задавать имя выходного файла необязательно. Оно будет получено из имени компилируемого файла заменой суффикса.c на суффикс.o. Итак, для компиляции программы earth теперь необходимо выполнить четыре команды:
Gcc -c arthur.c gcc -c trillian.c gcc -c prosser.c gcc arthur.o trillian.o prosser.o -o earth
Хотя теперь для компиляции программы необходимо выполнить четыре команды вместо одной, взамен получаются следующие преимущества:
- если изменение внесено в один файл, например, в файл prosser.c, нет необходимости перекомпилировать файлы trillian.o или arthur.o; достаточно перекомпилировать файл prosser.o, а затем выполнить компоновку программы earth;
- компиляция объектных файлов arthur.o, trillian.o и prosser.o не зависит друг от друга, поэтому может выполняться параллельно на многопроцессорном (многоядерном) компьютере.
В случае нескольких исходных.c и.h файлов и соответствующих промежуточных.o файлов отслеживать, какой файл нуждается в перекомпиляции, становится сложно, и здесь на помощь приходит программа make. По описанию файлов и команд для компиляции программа makе определяет, какие файлы нуждаются в перекомпиляции, и может выполнять перекомпиляцию независимых файлов параллельно.
Файл A зависит от файла B, если для получения файла A необходимо выполнить некоторую команду над файлом B. Можно сказать, что в программе существует зависимость файла A от файла B. В нашем случае файл arthur.o зависит от файла arthur.c, а файл earth зависит от файлов arthur.o, trillian.o и prosser.o. Можно сказать, что файл earth транзитивно зависит от файла arthur.c. Зависимость файла A от файла B называется удовлетворенной , если:
- все зависимости файла B от других файлов удовлетворены;
- файл A существует в файловой системе;
- файл A имеет дату последней модификации не раньше даты последней модификации файла B.
Если все зависимости файла A удовлетворены, то файл A не нуждается в перекомпиляции. В противном случае сначала удовлетворяются все зависимости файла B, а затем выполняется команда перекомпиляции файла A.
Например, если программа earth компилируется в первый раз, то в файловой системе не существует ни файла earth, ни объектных файлов arthur.o, trillian.o, prosser.o. Это значит, что зависимости файла earth от объектных файлов, а также зависимости объектных файлов от.c файлов не удовлетворены, то есть все они должны быть перекомпилированы. В результате в файловой системе появятся файлы arthur.o, trillian.o, prosser.o, даты последней модификации которых будут больше дат последней модификации соответствующих.c файлов (в предположении, что часы на компьютере идут правильно, и что в файловой системе нет файлов "из будущего"). Затем будет создан файл earth, дата последней модификации которого будет больше даты последней модификации объектных файлов.
В получившейся конфигурации все зависимости всех файлов друг от друга удовлетворены, и поэтому для компиляции программы earth не нужно выполнять никаких команд
Предположим теперь, что в процессе разработки был изменен файл prosser.c. Его время последнего изменения теперь больше времени последнего изменения файла prosser.o. Зависимость prosser.o от prosser.c становится неудовлетворенной, и, как следствие, зависимость earth от prosser.o также становится неудовлетворенной. Чтобы удовлетворить зависимости необходимо перекомпилировать файл prosser.o, а затем файл earth. Файлы arthur.o и trillian.o можно не трогать, так как зависимости этих файлов от соответствующих.c файлов удовлетворены. Такова общая идея работы программы make и, на самом деле, всех программ управления сборкой проекта: ant http://ant.apache.org/ , scons http://www.scons.org/ и др
Хотя утилита make присутствует во всех системах программирования, вид управляющего файла или набор опций командной строки могут сильно различаться. Далее будет рассматриваться командный язык и опции командной строки программы GNU make. В дистрибутивах операционной системы Linux программа называется make. В BSD, как правило, программа GNU make доступна под именем gmake.
Файл описания проекта может содержать описания переменных, описания зависимостей и описания команд, которые используются для компиляции. Каждый элемент файла описания проекта должен, как правило, располагаться на отдельной строке. Для размещения элемента описания проекта на нескольких строках используется символ продолжения \ точно так же, как в директивах препроцессора языка Си.
Определения переменных записываются следующим образом:
<имя> = <определение>
Использование переменной записывается в одной из двух форм:
$(<имя>) или ${<имя>} - Эти формы равнозначны.
Переменные рассматриваются как макросы, то есть использование переменной означает подстановку текста из определения переменной в точку использования. Если при определении переменной были использованы другие переменные, подстановка их значений происходит при использовании переменной (опять так же, как и в препроцессоре языка Си)
Зависимости между компонентами определяются следующим образом:
<цель> : <цель1> <цель2> ... <цельN>
Где <цель> - имя цели, которое может быть либо именем файла, либо некоторым именем, обозначающим действие, которому не соответствует никакой файл, например clean. Список целей в правой части задает цели, от которых зависит <цель> .
Если описание проекта содержит циклическую зависимость, то есть, например, файл A зависит от файла B, а файл B зависит от файла A, такое описание проекта является ошибочным.
Команды для перекомпиляции цели записываются после описания зависимости. Каждая команда должна начинаться с символа табуляции (\t). Если ни одной команды для перекомпиляции цели не задано, будут использоваться стандартные правила, если таковые имеются. Для определения, каким стандартным правилом необходимо воспользоваться, обычно используются суффиксы имен файлов. Если ни одна команда для перекомпиляции цели не задана и стандартное правило не найдено, программа make завершается с ошибкой.
Для программы earth простейший пример файла Makefile для компиляции проекта может иметь вид:
Earth: arthur.o trillian.o prosser.o gcc arthur.o trillian.o prosser.o -o earth arthur.o: arthur.c gcc -c arthur.c trillian.o: trillian.c gcc -c trillian.c prosser.o: prosser.c gcc -c prosser.c
Однако, в этом описании зависимостей не учтены.h файлы. Например, если файл arthur.h подключается в файлах arthur.c и trillian.c, то изменение файла arthur.h должно приводить к перекомпиляции как arthur.c, так и trillian.c. Получается, что.o файлы зависят не только от.c файлов, но и от.h файлов, которые включаются данными.c файлами непосредственно или косвенно. С учетом этого файл Makefile может приобрести следующий вид:
Earth: arthur.o trillian.o prosser.o gcc arthur.o trillian.o prosser.o -o earth arthur.o: arthur.c arthur.h gcc -c arthur.c trillian.o: trillian.c trillian.h arthur.h gcc -c trillian.c prosser.o: prosser.c prosser.h arthur.h gcc -c prosser.c
Первой в списке зависимостей обычно записывается «главная» зависимость, а затем записываются все остальные файлы-зависимости.
В командной строке программы make можно задать имя цели, которую требуется (при необходимости) перекомпилировать. Так, при запуске
Make prosser.o
будет при необходимости перекомпилирован только файл prosser.o и те файлы, от которых он зависит, все прочие файлы затронуты не будут. Если в командной строке имя цели не указано, берется первая цель в файле. В нашем случае это будет цель earth.
Если придерживаться хорошего стиля написания Makefile, то каждый Makefile должен содержать как минимум два правила: all – основное правило, которое соответствует основному предназначению файла, и правило clean, которое предназначено для удаления всех рабочих файлов, создаваемых в процессе компиляции. В случае программы earth рабочими файлами можно считать сам исполняемый файл программы earth, а также все объектные файлы.
С учетом этих дополнений файл Makefile примет вид:
All: earth earth: arthur.o trillian.o prosser.o gcc arthur.o trillian.o prosser.o -o earth arthur.o: arthur.c arthur.h gcc -c arthur.c trillian.o: trillian.c trillian.h arthur.h gcc -c trillian.c prosser.o: prosser.c prosser.h arthur.h gcc -c prosser.c clean: rm -f earth *.o
Обратите внимание, что у правила clean отсутствует список файлов, от которых этот файл зависит. Поскольку существование файла с именем clean в рабочем каталоге не предполагается, команда rm -f ... будет выполняться каждый раз, когда make запускается на выполнение командой
Make clean
Данный файл, безусловно, решает задачу автоматизации сборки программы earth. Теперь можно придать этому файлу более общий вид, чтобы в этот файл легче было вносить изменения.
Во-первых, можно параметризовать название используемого компилятора, а также предоставить возможность управлять параметрами командной строки компилятора. Для задания компилятора можно определить переменную CC , для задания опций командной командной строки компиляции объектных файлов - переменную CFLAGS , а для задания опций командной строки компоновки выходной программы - переменную LDFLAGS .
Получим следующий файл:
CC = gcc CFLAGS = -Wall -O2 LDFLAGS = -s all: earth earth: arthur.o trillian.o prosser.o $(CC) $(LDFLAGS) arthur.o trillian.o prosser.o -o earth arthur.o: arthur.c arthur.h $(CC) $(CFLAGS) -c arthur.c trillian.o: trillian.c trillian.h arthur.h $(CC) $(CFLAGS) -c trillian.c prosser.o: prosser.c prosser.h arthur.h $(CC) $(CFLAGS) -c prosser.c clean: rm -f earth *.o
Теперь можно изменить используемый компилятор, не только отредактировав Makefile, но и из командной строки. Например, запуск программы make в виде
Make CC=icc
Позволит для компиляции программы использовать не gcc, а Intel компилятор Си. Аналогично запуск
Make CFLAGS="-g" LDFLAGS="-g"
Позволит включить отладочную информацию в генерируемые объектные файлы и исполняемую программу
Во-вторых, можно избавиться от дублирования имен файлов сначала в зависимостях, а потом в выполняемых командах. Для этого могут быть использованы специальные переменные $^ , $< и $@ . Переменная $@ раскрывается в имя цели, стоящей в левой части правила. Переменная $< раскрывается в имя первой зависимости в правой части правила. Переменная $^ раскрывается в список всех зависимостей в правой части. Правило для компиляции файла arthur.o приобретет следующий вид:
Arthur.o: arthur.c arthur.h $(CC) $(CFLAGS) -c $<
Именно такое правило для компиляции.o файлов из.c файлов уже встроено в make, поэтому строку компиляции можно просто удалить. Останется следующий Makefile:
CC = gcc CFLAGS = -Wall -O2 LDFLAGS = -s all: earth earth: arthur.o trillian.o prosser.o $(CC) $(LDFLAGS) $^ -o $@ arthur.o: arthur.c arthur.h trillian.o: trillian.c trillian.h arthur.h prosser.o: prosser.c prosser.h arthur.h clean: rm -f earth *.o
При желании можно создавать новые шаблонные зависимости, то есть зависимости не конкретных файлов друг от друга, а файлов, имена которых удовлетворяют заданному шаблону. Тогда команды в зависимостях конкретных файлов также могут быть опущены. Например, стандартное шаблонное правило для зависимостей.o файлов от.c файлов может быть определено следующим образом:
%.o: %.c: $(CC) -c $(CFLAGS) $<
Тем не менее, в этом файле проекта осталось слабое место. Оно связано с тем, что зависимости объектных файлов включают в себя помимо.c файлов и.h файлы, подключаемые.c файлами непосредственно или транзитивно. Представим себе, что в файл prosser.c была добавлена директива
#include "trillian.h"
Но Makefile не был соответствующим образом изменен. Теперь может получиться так, что в файле trillian.h будет изменена некоторая структура данных, но файл prosser.o не будет перекомпилирован и код модуля prosser.o будет продолжать работать со старой версией структуры данных, в то время как остальная программа - с новой версией структуры данных. Такое расхождение в описании данных в рамках одной программы может привести к "загадочным" ошибкам при ее работе.
Хотелось бы каким-либо образом строить списки зависимостей объектных файлов от.c и.h файлов автоматически. Для этого мы воспользуемся специальными опциями компилятора gcc и расширенными возможностями GNU make.
Предположим, что автогенерируемые зависимости не находятся в самом файле Makefile, а подключаются из внешнего файла deps.make. Для подключения содержимого внешнего файла в Makefile необходимо добавить директиву
include deps.make
Для генерации файла deps.make с зависимостями воспользуемся опцией -MM компилятора gcc:
Deps.make: arthur.c trillian.c prosser.c arthur.h trillian.h prosser.h gcc -MM arthur.c trillian.c prosser.c > deps.make
Файл deps.make зависит от всех.c и.h файлов, из которых собирается программа. Может показаться, что это правило не будет работать, так как в Makefile необходимо включить файл deps.make, для генерации которого необходимо выполнить Makefile, то есть возникает циклическая зависимость, однако GNU make умеет корректно обрабатывать такие ситуации.
Для того, чтобы не выписывать списки.c и.h файлов несколько раз, в начале Makefile можно определить переменные:
CFILES = arthur.c trillian.c prosser.c HFILES = arthur.h trillian.h prosser.h
Более того, список объектных файлов можно получать из списка.c файлов заменой суффикса.c на.o:
OBJECTS = $(CFILES:.c=.o)
В итоге получили следующий Makefile:
CC = gcc CFLAGS = -Wall -O2 LDFLAGS = -s CFILES = arthur.c trillian.c prosser.c HFILES = arthur.h trillian.h prosser.h OBJECTS = $(CFILES:.c=.o) TARGET = earth all: $(TARGET) earth: $(OBJECTS) $(CC) $(LDFLAGS) $^ -o $@ include deps.make deps.make: $(CFILES) $(HFILES) gcc -MM $(CFILES) > deps.make clean: rm -f $(TARGET) *.o
Этот файл можно легко модифицировать для сборки других проектов с помощью изменения значений переменных CFILES, HFILES и TARGET.
Пример файла C++ проекта:
CXX = g++ LDFLAGS = CXXFLAGS = -Wall -O2 -g CXXFILES = main.cpp fn.cpp HFILES = fn.h OBJECTS = $(CXXFILES:.cpp=.o) TARGET = proga all: $(TARGET) proga: $(OBJECTS) $(CXX) $(LDFLAGS) $^ -o $@ include deps.make deps.make: $(CXXFILES) $(HFILES) $(CXX) -MM $(CXXFILES) > deps.make clean: rm -f proga *.oДля просмотра результирующих значений переменных полезно просматривать вывод команды: make -p
Рано или поздно каждый разработчик сталкивается с вопросом лицензирования своих разработок. Более или менее понятно, когда разрабатывается коммерческий продукт с закрытым кодом. Но когда разработчик желает распространять программу, плагин или библиотеку классов бесплатно и с открытыми кодами, то могут возникнуть трудности, потому что в природе существует масса лицензий подобного рода. Эта статья призвана собрать, упорядочить данные по лицензиям и вычленить самое главное.
UPD
: опубликован перевод небольшого куска официального GPL FAQ habrahabr.ru/blogs/Dura_Lex/45878
UPD2
: скорректирован и переформулирован список совместимых лицензий
Если касаться мира «свободных» лицензий, то основным столпом и стержнем можно посчитать GNU General Public License (GPL). И в этой статье я хотел бы разделить лицензии, которые попадают под GNU GPL и описать все другие, которые не попадают под условия этой лицензии. Первая часть статьи будет описывать саму GNU GPL, ее краткую историю, другие лицензии, которые похожи на нее. В конце я приведу небольшой словарик терминов и сокращений.
GNU General Public License
Вначале хотелось бы пояснить что такое «GNU». GNU расшифровывается как «GNU"s not UNIX» - это рекурсивный акроним придуманный Ричардом Столлманом, известным идеологом открытого и свободного программного обеспечения. Такое название было придумано для операционной системы, которую в 80-х годах разрабатывал Столлман. История GNU заслуживает отдельной статьи поэтому я перейду сразу к делу.GNU General Public License или открытое лицензионное соглашение GNU - это лицензия, первый вариант которой датируется 1 февраля 1989 года (википедия сообщает о 1988 г, но я считаю дату которая стоит на оригинале). На сегодняшний день существует четыре варианта лицензии, которые нумеруются в порядке появления.
GNU GPL v1.0
Основными позициями GNU GPL v1.0 стали следующие требования:- предоставление исходных кодов, доступных для изучения, к бинарным кодам публикуемым с данной лицензией;
- наследование лицензии в случае модификации исходного кода, то есть модифицированный или объединенный с другим код в результате так же должен быть выпущен под лицензией GNU GPL, следовательно, быть доступным для модификации любым желающим.
GNU GPL v2.0
Вторая версия лицензии датируется 1991 годом и основным мотивом провозглашает (согласно wiki) принцип «Liberty or Death» (Свобода или Смерть). Этот принцип заключен в седьмом и восьмом пункте соглашения:7. Лицензиат не освобождается от исполнения обязательств в соответствии с настоящей Лицензией в случае, если в результате решения суда или заявления о нарушении исключительных прав или в связи с наступлением иных обстоятельств, не связанных непосредственно с нарушением исключительных прав, на Лицензиата на основании решения суда, договора или ином основании возложены обязательства, которые противоречат условиям настоящей Лицензии. В этом случае Лицензиат не вправе распространять экземпляры Программы, если он не может одновременно исполнить условия настоящей Лицензии и возложенные на него указанным выше способом обязательства. Например, если по условиям лицензионного соглашения сублицензиатам не может быть предоставлено право бесплатного распространения экземпляров Программы, которые они приобрели напрямую или через третьих лиц у Лицензиата, то в этом случае Лицензиат обязан отказаться от распространения экземпляров Программы.
Если любое положение настоящего пункта при наступлении конкретных обстоятельств будет признано недействительным или неприменимым, настоящий пункт применяется за исключением такого положения. Настоящий пункт применяется в целом при прекращении вышеуказанных обстоятельств или их отсутствии.
Целью данного пункта не является принуждение Лицензиата к нарушению патента или заявления на иные права собственности или к оспариванию действительности такого заявления. Единственной целью данного пункта является защита неприкосновенности системы распространения свободного программного обеспечения, которая обеспечивается за счет общественного лицензирования. Многие люди внесли свой щедрый вклад в создание большого количества программного обеспечения, которое распространяется через данную систему в надежде на ее длительное и последовательное применение. Лицензиат не вправе вынуждать автора распространять программное обеспечение через данную систему. Право выбора системы распространения программного обеспечения принадлежит исключительно его автору.
Настоящий пункт 7 имеет целью четко определить те цели, которые преследуют все остальные положения настоящей Лицензии.
8. В том случае если распространение и/или использование Программы в отдельных государствах ограничено соглашениями в области патентных или авторских прав, первоначальный правообладатель, распространяющий Программу на условиях настоящей Лицензии, вправе ограничить территорию распространения Программы, указав только те государства, на территории которых допускается распространение Программы без ограничений, обусловленных такими соглашениями. В этом случае такое указание в отношении территорий определенных государств признается одним из условий настоящей Лицензии.
Как можно заметить, основным мотивом служит следующий принцип: программа не должна распространяться, если конечный пользователь не может в полной мере использовать свое право на модификацию и распространение под той же самой лицензией.
GNU Lesser GPL v2.1
Данная версия лицензии датируется 1999 годом и содержит одно огромное отличие от обычной лицензии GNU GPL: предназначенная для библиотек, лицензия позволяет использовать их в проприетарном программном обеспечении. Например, библиотеки GNU C распространяются под лицензией GNU Lesser GPL v2.1, для того, чтобы сторонние разработчики могли использовать их в своем ПО, свободном или коммерческом.GNU GPL v3.0
Последняя на сегодняшний день версия GPL, которая вышла в 2007 году. Изменения, внесенные в лицензию, были призваны оградить пользователей лицензии от судебных исков связанных с патентами, теперь создатели программы не могу подать в суд на пользователя. GPL 3.0 запрещает применять лицензию к программному обеспечению, которое запрещено «обходить» некоторыми законами и директивами (Digital Millennium Copyright Act и the European Union Copyright Directive). То есть, нельзя выпустить под лицензией любое ПО, попадающее под действие этих директив. Таким образом, GPL 3.0 заботится о том, чтобы любое ПО, выпущенное под ее лицензией, можно было свободно модифицировать, обходить или изменять.Кроме того, GPL 3.0 борется с таким явлением как «тивоизация», когда устройство, на котором установлено программное обеспечение под лицензией GPL, не позволяет вам в силу различных причин модифицировать его. GPL v3.0 запрещает тивоизацию для товаров народного потребления (оставляя возможность тивоизации для медицинских и других важных устройств).
Вместе с GPL 3.0 вышла так же обновленная версия GNU Lesser GPL 3.0, которая продолжает отличаться тем, что позволяет использовать свободные библиотеки в закрытом ПО.
Совместимость
Многие лицензии практически повторяют принципы, заложенные в GPL и отличаются, в принципе, только тем, что приняты коммерческими или другими организациями. Ниже я постараюсь свести такие лицензии под определенные версии GPL. Совместимость означает то, что отдельные части ПО с лицензией совместимого типа можно выпускать в комплексе с GPL-частями и под одной GPL лицензией.Совместимые только с GPL 3.0 лицензии
GNU Affero General Public License (AGPL) v3 - содержит пункт о том, что пользователи, которые взаимодействуют с программой по сети, так же должны иметь возможность получать исходные коды;Apache License, Version 2.0;
Educational Community License 2.0;
Freetype Project License;
Microsoft Public License (Ms-PL);
XFree86 1.1 License;
Совместимые с GNU GPL лицензии (как с v2 так и с v3 версией)
Artistic License 2.0;Berkeley Database License (aka the Sleepycat Software Product License);
Boost Software License;
Modified BSD license;
CeCILL version 2;
Cryptix General License;
Eiffel Forum License, version 2 - предыдущие версии не были совместимы;
Expat License;
FreeBSD license;
Лицензия the iMatix Standard Function Library;
Independent JPEG Group License;
Лицензия imlib2;
Intel Open Source License;
ISC License;
NCSA/University of Illinois Open Source License;
Лицензия Netscape Javascript;
OpenLDAP License, Version 2.7;
Лицензия Perl 5 и ниже;
Public Domain;
Лицензии Python 2.0.1, 2.1.1, и более новые версии;
Лицензия Ruby;
Standard ML of New Jersey Copyright License;
Unicode, Inc. License Agreement for Data Files and Software;
W3C Software Notice and License;
X11 License - иногда ошибочно называют MIT license.
Совместимые с Lesser GPL лицензии
eCos license version 2.0.Словарь
GNU - рекурсивный акроним GNU"s Not Unix;GNU GPL - открытое лицензионное соглашение GNU;
Проприетарное ПО - программное обеспечение, которое имеет ограничения в использовании и закрыто для модификации, другими словами «несвободное ПО»;
Программы GNU -- это программы, выпускаемые под эгидой проекта GNU. Если программа является программой GNU, мы также говорим, что это -- пакет GNU. Это должно быть указано в руководстве пользователя или файле README пакета. Кроме того, все пакеты GNU отмечены в Каталоге свободных программ.
Некоторые программы GNU были написаны персоналом Фонда свободного программного обеспечения, но большинство программ GNU поступило от многочисленных добровольцев. (Работа некоторых из этих добровольцев оплачивается компаниями или университетами, но для нас они -- добровольцы.) Авторские права на одни из поступивших программ принадлежат Фонду свободного программного обеспечения, авторские права на другие остаются за теми, кто предоставляет эти программы.
Нужно заметить, что преимущества свободной разработки для пользователя не следует преувеличивать. Не все свободные программы в равной степени доступны для изменения пользователям, и это совершенно не связано с лицензией на их распространение. Важный фактор здесь - объем программы: если в ней десятки тысяч строк (как, например, в OpenOffice.org), то даже квалифицированному пользователю потребуется слишком много времени, чтобы разобраться, что к чему. А если при этом еще нет толковой документации... Рассчитывать же на то, что разработчики ответят на все замечания и предложения пользователя немедленным исправлением программы тоже нельзя, поскольку они не несут перед пользователем никаких обязательств по качеству программы. В этом отношении пользователь патентованной программы может быть даже в лучшем положении.
Свободное программное обеспечение (СПО) (англ. free software, opensource software) - программное обеспечение, в отношении которого права пользователя на неограниченную установку, запуск, а также свободное использование, изучение, распространение и изменение юридически защищены авторскими правами при помощи свободных лицензий. Сотни тысяч компаний в России и по всему миру используют в своей деятельности операционную систему Linux, интернет-браузер Mozilla Firefox, офисный пакет OpenOffice.org, веб-сервер Apache и другое программное обеспечение, не подозревая, что именно оно является свободным. Другие подходят к внедрению в своей компании СПО обстоятельно, изучив преимущества и возможные сложности. А многие до сих пор не торопятся воспользоваться возможностями СПО. Причиной такого настороженного отношения, как правило, являются не только технические нюансы, но и неопределенность с юридическим статусом СПО в России.
Для большинства пользователей привычной и стандартной является схема использования проприетарного ПО - на каждую устанавливаемую копию программного продукта приобретается лицензия, часто также ограниченная по сроку действия. СПО предоставляет пользователям право устанавливать сколько угодно большое число копий программы, работать с ней без каких-либо ограничений, без необходимости платить при этом за лицензии. Такой порядок использования СПО является вполне легальным и регулируется специальными свободными лицензиями.
Возможность взять и пользоваться программным обеспечением без необходимости тратить огромные деньги на лицензии, масштабировать ИТ-решения с развитием компании без дополнительных затрат - эти черты СПО являются весьма привлекательными для многих российских компаний. Но здесь есть и свои подводные камни, в том числе и в юридической сфере.