Открытое программное обеспечение (Open Source Software, OSS) уже давно стало неотъемлемой частью современной IT-индустрии. От крупных коммуникационных платформ до небольших стартапов — многие компании строят свои продукты на базе открытого кода. Однако в последние годы наметилась тревожная тенденция: некоторые крупные проекты, изначально распространявшиеся под свободными лицензиями, начали переходить на проприетарные или source-available лицензии. Этот сдвиг породил волну дискуссий в профессиональном сообществе и стал поводом задуматься — почему до сих пор не существует механизма, гарантирующего постоянство открытости исходного кода проекта? Почему мы не имеем «постоянной» лицензии для OSS? Для ответа на этот вопрос необходимо сначала рассмотреть причины смены лицензий и бизнес-мотивации, стоящие за этими решениями. Отказ от открытой лицензии в пользу проприетарной или source-available связан в первую очередь с тем, что коммерческие проекты хотят защитить себя от крупных облачных провайдеров и конкурентов, которые используют открытый код для создания собственных управляемых сервисов без отдачи обратно в сообщество.
Такие компании, как Elastic, MongoDB и HashiCorp, переосмыслили свои бизнес-модели, чтобы избежать ситуации, когда облачные гиганты извлекают прибыль из их проектов, не поддерживая их в должной мере. В результате возникает конфликт между принципом открытости, заложенным в OSS, и прагматизмом ведения бизнеса. Общественная реакция на эти изменения неоднозначна. С одной стороны, многие понимают экономическую логику, стоящую за такими решениями. С другой — существует чувство предательства, когда казалось бы открытый и доступный проект внезапно закрывается.
Это подрывает доверие к идее открытого программного обеспечения как концепции и как инструмента построения сообществ и экосистем. Пользователи и разработчики осознают, что, несмотря на возможность форкать код, сделать полноценную альтернативу зачастую сложно из-за ресурсов и органичной поддержки, которыми располагает оригинальный проект. Пример с OpenSearch, форком Elasticsearch, демонстрирует, что форк чаще всего не достигает успеха оригинала, даже если за ним стоит крупная компания. Это отражает проблему масштабирования и поддержания жизнеспособности проектов после отказа основателей от первоначальной лицензионной политики. Таким образом, существует очевидная нехватка столь необходимой уверенности: что OSS останется таким навсегда, а лицензия не будет изменена в дальнейшем.
Идея «постоянного открытого программного обеспечения» (Permanent Open Source Software, POSS) пытается решить именно эту проблему. Но что это означает на практике? Как можно юридически закрепить обязательство сохранять проект открытым вне зависимости от дальнейших изменений? Одно из предложений заключается в передаче прав собственности на проект доверенному публичному институту. Такой подход уже реализуется на примере различных фондов: Apache Software Foundation, Linux Foundation и других организаций, которые обладают правами собственности на проекты и их бренды, что обеспечивает стабильность и защиту от произвольных изменений. В рамках POSS подобный доверенный публичный институт мог бы владеть авторскими правами, знаками и другими материальными элементами проекта, при этом команда разработчиков сохраняла бы управление и развитие кода. Это разделение собственности и разработки призвано создать долговечность и исключить возможность внезапного перехода на закрытую лицензию со стороны бизнеса.
Важным моментом является то, что компании все еще могут предлагать коммерческие услуги, основанные на проекте, включая платные функции и облачные сервисы — открытый код при этом остается доступным для сообщества без ограничений. Что если компания решит отказаться от проекта? По условиям POSS, она сможет сделать форк и выпустить код под иной лицензией, но при этом придется отказаться от бренда и постоянной аудитории, которая связана с оригинальным проектом. Такая мера вводит существенные барьеры и стимулирует бизнес придерживаться открытой модели, если только не возникнут чрезвычайные обстоятельства. Оппоненты могут возразить, что существующие сильные копилефт-лицензии, такие как GNU GPL, уже обеспечивают подобную защиту, требуя, чтобы все производные работы оставались открытыми. Но на практике многие коммерческие проекты избегают строгих копилефт-лицензий, поскольку они ограничивают возможности включения проприетарных функций и затрудняют гибридные бизнес-модели.
Легковесные лицензии, вроде MIT, наоборот, предоставляют максимальную свободу, но не гарантируют неприкосновенность открытости. Возможность закрепить пожизненную открытость в рамках «легкой» лицензии могла бы стать идеальным компромиссом. Попытка внедрить POSS связана с юридическими и социальными трудностями. Многие компании могут опасаться потери гибкости в лицензировании, опасаясь невозможности переключиться на закрытую модель, что ограничит выбор стратегий развития и монетизации. Тем не менее встречаются основатели и проекты, искренне приверженные открытости как фундаментальному принципу, для которых POSS мог бы стать мощным инструментом для создания доверия и сообщества.
Появление POSS могло бы изменить подход к OSS и в целом IT-индустрию. Это стало бы сигналом для разработчиков и пользователей о серьезности намерений бизнеса. По мере роста популярности такой лицензии, компании, в противном случае выбравшие закрытые решения, могли бы рассмотреть возможности создания продуктов с гарантиями постоянной открытости. Подобный подход создаст экосистему, где долгосрочное развитие и сотрудничество становятся основной ценностью. В итоге, отсутствие постоянной лицензии для OSS объясняется сложностью балансирования интересов различных сторон — бизнеса, сообщества, конечных пользователей.
