Искусство программирования для Unix

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

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

Правда, адвокаты и судьи запутываются в формулировках лицензий больше, чем разработчики. Законодательство о правах на программное обеспечение туманное, а прецедентного права по лицензиям на открытый исходный код (к середине 2003 года) не существовало; никто никогда не преследовался за нарушение данных лицензий.

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

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

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

Часть IV Сообщество

17 Переносимость: переносимость программ и соблюдение стандартов

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

Переносимость С-программ и операционной системы Unix (Portability of С Programs and the UNIX System, 1978)

–Стив Джонсон, Деннис Ритчи

Unix была первой действующей операционной системой, переносимой между различными семействами процессоров (Version 6 Unix, 1976 - 1977). В настоящее время Unix регулярно переносится на все новые машины, мощность которых достаточна для поддержки блока управления памятью. Unix-приложения просто переносятся между Unix-системами, работающими на различном аппаратном обеспечении; фактически, неудачные попытки переноса не известны.

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

Unix-программисты знают по опыту, что очень легко ошибиться, предрекая короткую жизнь программному проекту[136]. Поэтому они склонны избегать создания программного обеспечения, зависимого от специфических и недолговечных технологий, и в большой степени полагаются на открытые стандарты. Привычка писать программы с учетом переносимости уже стала одной из традиций Unix, так что теперь она относится даже к мелким проектам, которые задумывались как однократно используемый код. Она оказала влияние на всю конструкцию инструментария Unix-разработчика, а также на языки программирования, такие как Perl, Python и Tcl, которые создавались в Unix-среде.