Право собственности на программное обеспечение и ответственность

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

Машина therac-25

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

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

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

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

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

Если сходство таких характеристик не нарушает закона об авторском праве, что же тогда можно признать нарушением авторского права? Некоторые обвинители с успехом доказывали, что авторское право должно защищать внешний вид программной системы и способ взаимодействия с пользователем. Хотя эти понятия и не использовались до 1985 года, они появились в 60-е годы XX века, когда фирма IBM объявила о выпуске семейства ЭВМ System/360. Это семейство ЭВМ включало в себя самые разные машины — от небольшой машины для мелких предприятий до крупных машин, выполняющих сложные действия. Все эти машины поставлялись в комплекте с операционными системами, в которых способы взаимодействия с внешней средой мало отличались друг от друга. То есть вся серия машин имела стандартный пользовательский интерфейс. Предприятие могло с легкостью перейти на более сложные машины той же серии. Для этого не потребовалось бы ни перестройки программ, ни дополнительного обучения персонала, поскольку внешний вид системного программного обеспечения и способ взаимодействия пользователя и системы были одинаковыми для всей серии.

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

Этот довод в защиту авторского права был проверен в 1987 году, когда корпорация Lotus Development Corporation подала в суд на компанию Mosaic Software за использование интерфейса системы табличных вычислений Lotus 1-2-3 и выиграла дело. Однако в настоящее время этот аргумент не всегда приводит к успеху. Если, например, защитнику удастся убедить суд в том, что интерфейс системы настолько распространен и популярен, что стал стандартом и всеобщим достоянием, тогда авторское право не будет распространяться на данный пользовательский интерфейс.

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

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

Существует еще одна сложность использования патентов для защиты права собственности на программное обеспечение. Получение патента — дорогостоящий и длительный процесс, который часто продолжается несколько лет. За это время программное обеспечение может устареть, а до получения патента заявитель не защищен от незаконного присвоения созданного им продукта.

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

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

Часть 3 ОРГАНИЗАЦИЯ ДАННЫХ

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

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

СТРУКТУРЫ ДАННЫХ

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