ПРАВО СОБСТВЕННОСТИ И ОТВЕТСТВЕННОСТЬ ЗА СОЗДАВАЕМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ.docx

ПРАВО СОБСТВЕННОСТИ И ОТВЕТСТВЕННОСТЬ ЗА СОЗДАВАЕМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

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

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

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

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

С целью применить закон об авторском праве к программному обеспечению были сделаны попытки обратиться к кон- цепции сценария диалога с пользователем (look and feel) в системе программного обеспечения. Хотя сама фраза look and feel не использовалась до 1985 г., данная концепция уходит своими корнями в начало 1960-х гг., когда компания IBM выпустила новую серию машин System/360. Эта серия состояла из нескольких машин, предназначенных для удовлетворения самых раз- нообразных потребностей: от приложений мелкого бизнеса до мощных корпоративных систем. Все эти машины поставля- лись с операционными системами, которые общались с окружающей средой аналогичным образом. Иными словами, маши- ны этой серии имели стандартизованный интерфейс пользователя. По мере роста бизнеса можно было заменить используе- мую машину на более мощную из той же серии, не затрачивая усилий на переделку программ и переобучение персонала. Действительно, внешний вид (look) (оформление, поддерживаемое системным программным обеспечением) и способы рабо- ты (feel) (то, как пользователь взаимодействует с системным программным обеспечением) были одинаковы для всех машин этой серии.

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

Первую проверку аргумент схожести сценариев диалога с пользователем прошел в 1987 г., когда корпорация Lotus De- velopment Corporation судилась с компанией Mosaic Software, заявив, что последняя скопировала сценарий диалога с пользо- вателем системы электронных таблиц Lotus 1-2-3. Дело было выиграно. Однако в дальнейшем аргументы схожести сценари- ев диалога с пользователем имели переменный успех.

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

– ее алгоритм. Кроме того, получение патента – дорогостоящий и длительный процесс, часто занимающий несколько лет. За это время программный продукт может устареть; пока патент еще не выдан, претендент на его получение имеет весьма спорное право препятствовать другим присваивать его продукт. Однако существуют и прецеденты выдачи патентов на алго- ритмы. Примером может служить алгоритм кодирования RSA, активно используемый во множестве современных систем кодирования с открытым ключом.

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

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

Чтобы избежать ответственности, разработчики программного обеспечения зачастую сопровождают свои продукты оговорками, ограничивающими уровень их ответственности. Часто можно встретить предложения следующего вида: "Ком- пания X не несет никакой ответственности за ущерб, нанесенный в связи с использованием этого программного обеспече- ния". Суды, однако, редко принимают во внимание такие оговорки, если истец может указать на небрежное отношение со стороны ответчика. Следовательно, при разрешении вопроса об ответственности исходят из того, насколько тщательно был разработан продукт и соответствует ли он предполагаемому использованию. Уровень тщательности, приемлемый при разра- ботке редакторской системы, может считаться недостаточным, если речь идет о программном обеспечении для управления ядерным реактором. Поэтому при разработке программного обеспечения лучшей защитой против исков о возмещении убыт- ков является выбор общего с заказчиком подхода к процессу разработки.

Вопросы для самопроверки

1.  Какой тест можно использовать для определения того, является ли одна программа фактическим подобием другой?

2.  Каким образом закон об авторском праве, патентное право и закон о коммерческой тайне служат на благо обществу?

3.  В каких случаях оговорки об отказе от ответственности не принимаются во внимание судами?

Упражнения

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

2.  Что такое пошаговая модель?

3.  Охарактеризуйте, как изменило использование инструментов CASE-технологии процесс разработки программного обеспечения.

4.  Объясните, как влияет на технологию разработки программного обеспечения отсутствие метрик для измерения точ- ных характеристик программного обеспечения.

5.  Чем отличаются технологии разработки программного обеспечения от традиционных технических дисциплин?

6.  а) В чем заключаются недостатки использования традиционной модели водопада при разработке программного обес- печения?

б) В чем заключаются преимущества использования традиционной модели водопада при разработке программного обеспечения?

7.  Как помогает в разработке высококачественного программного обеспечения принятие кодексов о профессиональной этике?

8.  Опишите, как может упростить модификацию программного обеспечения использование констант вместо литералов?

9.  В чем заключается различие между связанностью и связностью модулей? Что следует минимизировать, а что – мак- симизировать?

10.  Какое из следующих предложений является аргументом в пользу связанности, а какое – в пользу связности?

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

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

11.  В тексте упоминалось понятие связанности по управлению, но эта тема не получила достаточного развития. Сравни- те связанность между двумя программными единицами, достигаемую с помощью команды goto, со связанностью, получае- мой при использовании механизма вызова процедур.

12.  Ответьте на следующие вопросы, пользуясь приведенной ниже структурной схемой: а) Какому модулю возвращает управление модуль Y?

б) Какому модулю возвращает управление модуль Z?

в) Являются ли модули W и X связанными по управлению? г) Связаны ли модули W и X данными?

д) Какие данные совместно используются модулями W и Y?

е) В каких отношениях находятся модули Y и X?

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

14.  Ответьте на следующие вопросы, пользуясь прилагаемой ниже схемой:

а) Чем отличаются способы использования модулями А и В элементов данных х и у?

б) Если один из модулей отвечает за получение элемента данных z от пользователя удаленного терминала, то какой именно?

15.  Начертите простую диаграмму классов, представляющую взаимоотношения между издателями, журналами и под- писчиками.

16.  Расширьте предыдущую диаграмму классов до диаграммы совместно выполняемых действий.

17.  Чем диаграмма классов отличается от диаграммы взаимодействий?

18.  Что такое UML?

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

20.   Разработайте решение для предыдущей задачи с использованием объектно-ориентированной парадигмы и пред- ставьте его в виде диаграммы классов.

21.  Приведите несколько примеров шаблонов проектирования в областях, отличных от архитектуры и программирова-

ния.

22.  Охарактеризуйте роль шаблонов проектирования в технологии разработки программного обеспечения.

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

24.  Сравните информацию, представленную на схеме потоков данных, с информацией, отображаемой на структурной

схеме.

25.  Чем отличаются связи типов "один ко многим" и "многие ко многим"?

26.  Начертите диаграмму "сущность – связь" для отношений между поварами, официантами, посетителями и кассирами в ресторане.

27.  Начертите диаграмму "сущность – связь", представляющую отношения между журналами, издателями и подписчи- ками.

28.   В каждом из следующих случаев определите, о чем идет речь – о структурной схеме, схеме потоков данных, диа- грамме "сущность – связь" или словаре данных.

а) Определяет данные, относящиеся к разрабатываемой системе.

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

г) Определяет, какие элементы данных совместно используются различными частями системы.

29.  В чем отличие между диаграммой классов и диаграммой "сущность – связь"?

30.  Охарактеризуйте различие между нисходящей и восходящей стратегиями проектирования.

31.  В чем отличие между тестированиями по принципам "черного ящика" и "прозрачного" ящика?

32.   Предположим, что перед окончательным тестированием крупной системы программного обеспечения в нее было намеренно внесено 100 ошибок. Допустим, во время этого тестирования было обнаружено и исправлено 200 ошибок, из ко- торых 50 оказались из группы намеренно помещенных в систему. Если исправить оставшиеся 50 известных ошибок, сколько не выявленных ошибок, по-Вашему, еще останется в системе? Объясните, почему.

33.  В каких случаях закон о защите авторских прав не может защитить инвестиции разработчиков программного обес- печения?

34.  По каким причинам патентное право не может защитить инвестиции разработчиков программного обеспечения?

Скачано с www.znanio.ru