Главная страница Visual 2000 · Общий список статей
Как обеспечить права пользователейАндрей Колесов
© Андрей Колесов, 2004Вопросы безопасности за последние годы превратились...
Вопросы безопасности за последние годы превратились в одну из главных проблем развития информационных технологий. Это вполне понятно. С одной стороны, растет значимость ИТ для обеспечения основной деятельности организаций, с другой — стремительно повышается сложность информационных систем, а значит, и степень их технологической уязвимости.
Однако следует отметить, что сам термин "безопасность" в его нынешнем общепринятом понимании в сфере ИТ трактуется лишь как обеспечение защиты ИС от внешних угроз. В то же время очевидно, что с точки зрения пользователя (которого интересует в первую очередь обеспечение надежного и стабильного функционирования и развития основного бизнеса) такой подход к проблеме надежности ИС является несовершенным, односторонним. Ведь клиенту в общем-то все равно, по какой причине его информационная система работает не так, как ему хотелось бы, — из-за происков злоумышленников или из-за внутреннего "жука" (порожденного не хакером, а самим разработчиком ПО), который "перегрыз" критичный алгоритм в используемом софте <*>.
<*> Здесь вполне уместны параллели с вопросом национальной безопасности, которая охватывает не только вопросы защиты от происков внешних и внутренних врагов с применением насильственных методов, но и сферы образования, демографии, здравоохранения и пр.
Правда, тут возникает вопрос: а каково реальное соотношение внешних и внутренних угроз при оценке безопасности ИС? Я вполне допускаю, что уровень опасности различного рода диверсий гораздо выше, но при этом считаю, что практически полное отсутствие публикаций в профессиональной прессе на тему "защита от разработчика" во многом определяется отражением вялой позиции потребителей ИТ (особенно на фоне дискуссий о хакерах, вирусах, спаме и пр., инициируемых при активном участии поставщиков ПО). С учетом всего этого представляется, что вопросы, затронутые в статье Сергея Свинарева "Кому нужен билль о правах" (PC Week/RE, N 31/2004, с. 27), весьма актуальны и требуют конструктивного обсуждения.
Принцип "As Is" остается неизменным
Первые дискуссии о юридических правах пользователей ПО начались в нашей стране в 90-х годах с обсуждения принятого впоследствии российского закона об охране интеллектуальной собственности разработчиков программных продуктов. Тогда задавался и такой вопрос: какую ответственность за свою продукцию (качество, функциональность) несут поставщики перед своими клиентами?
Ответ был довольно неожиданным: фактически никакой! Анализ специфики софтверной отрасли показал, что программы, несмотря на их признание рыночным товаром, по характеру разработки и применения радикально отличаются от "материальных" продуктов, и традиционные подходы к определению прав и ответственности тут не работают. Выяснилось, что главным юридическим документом, регламентирующим отношения производителя и пользователя, является лицензионное соглашение, суть которого уже не одно десятилетие сводится к закреплению принципа "As Is" — покупатель приобретает программный продукт по состоянию "как есть" и принимает все риски по его применению на себя. Именно это положение составляет юридический базис развития софтверной индустрии последних двух-трех десятилетий <**>.
<**> Разумеется, речь идет о "коробочных" программных продуктах. В случае же с заказными ПО (а зачастую и тиражируемых решений) взаимоотношения между разработчиком и заказчиком определяются конкретным договором между ними.
Сейчас не стоит обсуждать причины этой ситуации, подчеркнем лишь, что при всей кажущейся спорности принцип "As Is" появился не из-за происков коварных "олигархов от ИТ", а стал следствием объективных потребностей рынка и пользователей вычислительной техники. В этой связи отметим только один момент: клиенты имеют дело не с отдельными приложениями или аппаратурой, а со сложным аппаратно-программным комплексом (даже если речь идет о карманных компьютерах). У него нет единого поставщика: система состоит из ряда компонентов (в самом простом варианте — "железо" и "софт"), за работоспособность которых отвечает целый ряд независимых производителей.
Казалось бы, можно вспомнить о благословенных временах середины прошлого столетия, когда программы поставлялись только в составе компьютеров. Но тогда не очень понятно, почему потребители (в лице властей США) заставили корпорацию IBM отказаться от этой практики под угрозой судебного преследования?
Однако если 10 лет назад вопрос "за что мы платим деньги поставщикам ПО?" волновал в основном частных пользователей, то сейчас его чаще всего задают корпоративные клиенты. При этом акцент смещается от собственно стоимости продукта к оценкам стоимости бизнес-рисков предприятий. Именно поэтому в дополнению к проблемы качества ПО возникает еще и задача обеспечения надежного и непрерывного развития программных технологий.
Идея создания "Билля о правах пользователей ПО" (об этом, в частности, говорится в статье "Кому нужен билль о правах") в общем-то не нова, она обсуждается ровно столько, сколько существует софтверная отрасль. И именно эти вопросы лежат в центре внимания целого ряда классических работ 70-х гг. (Э. Дейкстра, Э. Йордан, Ф. Брукс и др.) <***>.
<***> Например, актуальные и сегодня рассуждения содержатся в разделе "Что такое хорошая программа и хорошие программисты" книги Э. Йордана "Структурное проектирование и конструирование программ" (М.: Мир, 1979). Некоторые мои собственные соображения на этот счет модно найти в разделе "Размышления бывшего программиста".
И хотя тогда данная проблема рассматривалась в основном с точки зрения технологий разработки программ, в них все же была показана вся сложность (фактически невозможность) формального описания такого понятия, как "качественное ПО", которое является пунктом ь 1 упомянутого "Билля".
Взять хотя бы требование к отсутствию ошибок. Но ведь еще тридцать лет назад Э. Дейсктра сформулировал очевидное положение: "Тест может показать наличие ошибок, но ни один тест не может доказать их отсутствия". А раз так, то понятие "отсутствие ошибок" может быть применено лишь по отношению к конкретному тесту. Но тогда возникает вопрос: кто должен отвечать за полноту и надежности самих тестов?
Не говоря уже о том, что "качество ПО" отнюдь не ограничивается наличием/отсутствием ошибок. К нему нужно отнести еще и удобство пользовательского интерфейса, и масштабируемость, и возможность сопровождения и адаптации, и наличие хорошей (?!) документации и пр. Но вот проблема: сформулировать все эти понятия на уровне четких проверяемых показателей очень и очень сложно.
Однако еще более странными в "Билле" выглядят положения с требованиями контроля за ценообразованием, структурой расходов, используемыми методиками разработки и тестирования и пр. расценить лишь как вмешательство во внутренние дела независимых коммерческих организаций. Более реалистичным выглядит обеспечение права на техническую поддержку, хотя на самом деле в соответствии со сложившимся в последние два десятилетия законодательством данная услуга не входит в состав программного продукта в качестве обязательного компонента. Сложность проблемы выработки "Билля" лучше всего иллюстрирует тот факт, что его автор — компания AMR Research (www.amrresearch.com) — не очень сильно продвинулась по пути реализации выдвинутых ею же идей...
Open Source не решает всех проблем
Казалось бы, многие вопросы качества и сопровождения ПО должна решить идеология открытых исходных кодов (Open Source). Однако в действительности мы видим, что данная модель не дает каких-то радикальных преимуществ по сравнению с "закрытыми" (proprietary) программными продуктами: решая одни проблемы, она порождает другие, не менее сложные. С одной стороны, получая в свое распоряжение исходные коды, пользователь получает и полный контроль над приобретаемым ПО, в том числе по исправлению ошибок и развитию продуктов. При этом поставщик как бы автоматически снимает с себя ответственность за сопровождение продуктов.
Но, с другой стороны, реально воспользоваться этими возможностями может далеко не каждый клиент (ведь для этого нужны дополнительные ресурсы), особенно если речь идет о системах в сотни тысяч и даже более строк кода. Не говоря уже о проблеме качества исходного кода — всем программистам известна ситуация, когда переписать программу бывает проще, чем исправить чужой код.
Определенные проблемы вносит и система лицензирования программ с открытым исходным кодом: последовательная передача прав от одного разработчика к другому при постоянном пополнении и изменении кода создает ситуацию, когда пользователь уже не знает, кто же отвечает за конечный продукт.
Здесь, кстати, хотелось бы обратить внимание на один важный момент. В нашей ИТ-литературе довольно часто термин Open Source как бы автоматически означает "бесплатный". Это в общем случае конечно же не так — есть довольно большое число сугубо коммерческих продуктов, поставляемых с исходными кодами (самый простой пример — прикладные решения "1С"). В то же время имеется огромное количество свободно распространяемых, но закрытых с точки зрения кода программ.
В правовой сфере Open Source в последние годы обозначилась еще одна тенденция — предъявление разработчиками друг другу патентных исков (самый яркий пример - SCO против Linux). При этом самое неприятное, что эти юридические разбирательства могут выйти боком конечными пользователями, которым в случае признания применения "чужого" кода придется (совершенно неожиданно для себя) платить деньги правообладателю...
После всего сказанного возникает вопрос, нужно ли тогда вообще вести все эти дискуссии о правах пользователя, критериях "хороших" программ и т. д. Конечно, нужно!
Здесь мы имеем дело с ситуацией, когда построение идеальной модели (в данном случае взаимоотношений разработчика и потребителя) позволяет нам лучше понять реальные процессы, происходящие в ИТ-индустрии, и, как следствие, более эффективно адаптироваться к ним и управлять ими. К тому же следует учитывать, что даже если многие идеи нельзя в законодательном виде закрепить для "коробочного" ПО, то их можно успешно применять во взаимоотношениях клиент — исполнитель в заказных проектах.
Безусловно, вполне возможна и даже необходима корректировка базового законодательства в области авторского права на ПО в соответствии с общим прогрессом ИТ и изменением их роли в жизни общества. (Понятно, что особое внимание должно быть обращено на ПО, относящиеся к категории базовых платформенных технологий). В этой связи стоит, например, отметить, что в российском законодательстве проблема дизассемблирования (о ней говориться в статье С. Свинарева) в целом давно решена — эту операцию над кодом можно делать при адаптации работы программы на конкретном компьютере, в том числе и исправлять обнаруженные ошибки. Что касается упомянутого в той же статье вопроса о запрете поставщиком публичного обсуждения недостатков приобретаемого ПО, то подобные записи в лицензионных соглашениях вряд ли имеют какую-то юридическую силу, поскольку противоречат базовому законодательству о защите прав потребителя, а может быть, и Конституции.
В то же время нужно подчеркнуть очень важный момент: одно дело формулировать требования к "качественному ПО" на уровне рекомендаций и совсем другое фиксировать их в виде юридических или нормативных актов. Результаты последнего варианта могут быть крайне плачевными для софтверной индустрии в виде различного рода государственных сертификаций. И эта угроза реально существует, особенно в нашей стране, где уже есть примеры введения различных ведомственных сертификаций ПО "на соответствие", которые из рекомендательных быстро превращаются в обязательные.
Главное право пользователя — право выбора!
Итак, главенство принципа "As Is" в софтверной индустрии вроде бы полностью освобождает поставщика ПО от каких-либо серьезных обязательств перед потребителем. Что же тогда толкает разработчика на развитие технической поддержки, повышение качества программ, их постоянное обновление, информирование рынка о своих планах и т. д. Угроза юридических санкций? Конечно, нет. Прежде всего — конкурентная борьба за клиента!
Действительно, главное право заказчика — это право выбора продуктов и поставщиков в условиях конкурентного рынка. А раз так, то, если потребитель хочет обеспечить свою независимость от вендоров и получать качественные продукты и услуги, он должен понимать, что залогом этого является поддержка свободной и честной конкуренции и борьба против монополизма. Такая постановка вопроса правомерна для любого сегмента экономики, но для софтверной отрасли она особенно актуальна в силу специфики "мягких" продуктов и сложностей регулирования отношений в сфере интеллектуальной собственности.
Вспомним, что именно после предписания суда по антимонопольному иску IBM пришлось сделать компьютеры рыночным товаром: в 1956 г. она перешла от сдачи аренды машин к их продаже. В 1969-м, уже не дожидаясь судебных разбирательств, корпорация впервые начала продажу техники, программ и услуг в качестве независимых продуктов; тогда ПО впервые стало рыночным товаром.