Свободных лицензий недостаточно для защиты разработчиков
В свете недавнего раскола команды OpenOffice.org и основания Open Document Foundation Энди Апдегрув (Andy Updegrove), юридический консультант организации Linux Foundation, размышляет об уязвимости разработчиков открытого ПО и способах защиты их прав. Основные мысли публикации таковы:На фоне нескончаемых споров о будущем Java и OpenOffice удивительным является то, что разработчики вообще дали себя поймать в подобную ловушку. Причина этого: сообщество переоценило возможности лицензий по защите их прав, а также не стали прибегать к другим средствам, хотя и могли. Сегодня ограничительные лицензии предоставляют серьёзные возможности и права, но эти права ограничиваются возможностью их обладателей их предъявить. Возлагать все надежды только на одно средство закона несерьёзно, потому что враг обходит с флангов, и у врага более разнообразный арсенал вооружений.
Возможности разработчиков несравнимы с возможностями корпорации, входящей в список Fortune 500, такой, как Oracle, особенно если этой корпорации всё равно, продолжат ли независимые разработчики поддерживать приобретённые ей проекты. Сейчас выясняется, что предоставляемые лицензией возможности по защите прав разработчиков в больших проектах довольно трудно реализуемы.
В качестве практического примера можно привести высказывание известного Java-разработчика Боба Ли (Bob Lee) по поводу выдвижения кандидатов в исполнительный комитет JCP (Java Community Process), который контролирует содержимое будущих релизов Java. Исполнительный комитет утверждает изменения в Java и одобряет новые функции, при этом у Oracle есть право контролировать три из пяти мест в комитете. В частности, Боб пишет: "Они закрыли Java и запретили независимые реализации. Они отхватили свою львиную долю и поедают её. Java не имела бы и половины сегодняшнего признания и успеха, если бы не была открытым стандартом. И я точно бы не стал делать никакого вклада. Теперь же я нахожусь в нелепом положении - я слишком много вложил, чтобы просто встать и уйти. Я вынужден сидеть и надеяться, что Oracle поступит правильно. Я обвиняю себя.". Главный момент здесь в том, что у Oracle есть право выбора между назначением в комитет честных и независимых членов или явных марионеток.
Сегодня разработчики могут защититься двумя способами: либо форком проекта, либо, в случае если корпорация следит, чтобы проект не вышел за контролируемые рамки, отстаивать свои законные права согласно лицензии, под который они осуществили свой вклад. Но форк проекта влечёт за собой огромные усилия, неуверенность, отсрочки и риск (всё, с чем сейчас приходится сталкиваться контрибуторам OpenOffice.org). И в случае нарушения открытой лицензии, откуда взять ресурсы для отстаивания прав разработчика? Есть некоторые не-коммерческие организации, желающие отстоять эти права. Но компании уровня Oracle располагают ресурсами и возможностями совершенно другого масштаба. В итоге, хоть сколько-нибудь эффективно разработчики могут защитить себя от фактического закрытия проекта или размножения подверсий только если с самого начала не станут подвергать свои проекты таким рискам. Cредства достичь этого уже давно имеются и настало время для разработчиков воспользоваться ими.
Разработчики open-source должны настаивать на том, чтобы корпоративный спонсор создал независимый юридический субъект (напирмер, некоммерческий фонд) для обеспечения проекта, если этот корпоративный спонсор заинтересован в том, чтобы сообщество отдавало проекту своё время и свой код. Эта организация должна руководиться советом директоров, не подконтрольным корпоративному спонсору. Эта независимая организация должна иметь права контролировать не только будущие пути развития проекта, но также и связанные с проектом торговые марки. Таким образом, если спонсор захочет прибегнуть к законному праву на форк проекта, то форк будет носить другое название.
Ричард Столлман несколько десятков лет назад обеспечил независимость проектов GNU, создав фонд Free Software Foundation, которому принадлежат авторские права и торговый знак GNU. Воздвигнуть эту защиту можно довольно просто, дёшево и быстро. Сообществу необходимо настоять на том, чтобы корпоративные спонсоры либо сделали проект независимым юридическим лицом или же основали новый проект (а также и управляющий им совет) под легальным крылом уже существующей независимой организации. Только после этого сообщество должно давать согласие на участие в проекте. В противном случае разработчики-правообладатели из сообщества проекта так и останутся уязвимыми перед непредвиденными нарушениями своих законных прав.
© OpenNet
