Управление и лицензирование не являются привлекательными, но их правильное выполнение жизненно важно для долгосрочного здоровья программного обеспечения с открытым исходным кодом.
Развитие программного обеспечения с открытым исходным кодом не всегда проходит гладко, особенно когда разработка программного обеспечения связана с более широкими корпоративными стратегиями.
Действительно, сложная история и неразбериха при разработке OpenOffice, скачать русскую версию OpenOffice можно на сайте https://openoffice-pc.ru/, а также разногласия между LibreOffice и Apache OpenOffice являются полезным уроком.
Они показывают, что какими бы прекрасными ни были намерения управляющей организации, такой как Sun Microsystems, последовательность и прозрачность управления и лицензирования жизненно важны для долгосрочного благополучия и успеха любого бесплатного проекта с открытым исходным кодом.
Когда Sun Microsystems в 2000 г. представила сообществу разработчиков ПО с открытым исходным кодом программный пакет StarOffice с открытым исходным кодом, компания пообещала создать самоуправляемый фонд и передать код под контроль сообщества. Но авторские права на код остались за Sun, а управление проектом оставалось за ней.OpenOffice.org (OO.o) можно было рассматривать как проект с открытым исходным кодом только в том смысле, что исходный код был видимым. Но ни лицензирование, ни управление не были прозрачными, и последующий прогресс никогда не соответствовал амбициям разработчиков.
Sun имеет давнюю традицию вносить вклад в проекты с открытым исходным кодом и извлекать из них выгоду, но всегда сохраняет за собой право собственности и жесткий контроль. Вначале Sun лицензировала код OO.o по двойной лицензии LGPL и Sun Industry Standards Source License (SISSL). SISSL была разрешающей лицензией и позволяла повторно использовать код в проприетарных продуктах третьими сторонами.
К сентябрю 2005 года Sun отказалась от SISSL, но авторские права на код всех участников по-прежнему принадлежали Sun. Право собственности на код позволило Sun перелицензировать программное обеспечение и добавлять компенсацию за патент.
Код, номинально переданный в дар проекту под лицензией с авторским левом, был передан IBM в качестве основы для Lotus Symphony, что не входило в планы разработчиков. IBM не вносила поправок в код.
Управление OO.o оставалось внутри компании. Исправление ошибки было медленным и трудоемким. Авторы разочаровались, приходили и уходили.
Novell создала свою собственную ветвь OO.o, go-oo.org, для поглощения изменений, отклоненных Sun по причинам лицензирования, и эта ветка стала установкой по умолчанию для всех дистрибутивов GNU/Linux.
Взносы сторонних разработчиков прекратились, и OO.o так и не добился того прогресса, которого от него ожидали.
Когда в 2010 году Sun вошла в состав Oracle, OpenOffice.org не входил в число приоритетов компании.
После нескольких месяцев уловок со стороны Oracle и StarDivision сообщество сделало радикальный шаг, основав Document Foundation, по-настоящему независимую некоммерческую организацию по модели, обещанной Sun в начале проекта, и разработало код для создания LibreOffice.
Document Foundation был шансом исправить некоторые недостатки прошлого и создать настоящее сообщество обмена кодами.
Через шесть месяцев после объявления о выходе из состава LibreOffice Oracle объявила о своем намерении передать авторские права и товарный знак OpenOffice.org Apache Software Foundation. Этот подход также представляет собой улучшение предыдущего режима.
IBM поддержала этот шаг и объявила о своем намерении в будущем выпустить «идентичный выпуск кода Apache OpenOffice под лицензией Apache», но опасность репликации кода под другой лицензией заключалась в том, что это настраивало сообщество против сообщества, лицензию против лицензии, и Apache OpenOffice против LibreOffice.
LibreOffice предложила участие как IBM, так и Oracle и была готова перелицензировать код под слабой лицензией с авторским левом, Mozilla Public License (MPL), чтобы упростить задачу.
Но ее достижения были отвергнуты, и ветвь Apache стала излюбленным маршрутом IBM. Теперь было два офисных пакета, и у обоих возникали все возрастающие проблемы с перелицензированием программного обеспечения.
Остаточная проблема LibreOffice заключается в том, что, хотя она предпочитает режим лицензирования с авторским левом, авторские права на код, унаследованный от Oracle-Sun, по-прежнему принадлежат Oracle.
Таким образом, разработчики LibreOffice рассматривают возможность переустановки кода LibreOffice на основе перелицензированного кода Apache, поскольку лицензия Apache позволяет повторно выпускать код под другими лицензиями.
С перелицензированием исходной базы кода OpenOffice.org на лицензию Apache License 2.0 компанией Oracle, — говорили они, — мы теперь можем постепенно переустанавливать наш собственный код поверх этого, чтобы предложить выбор лицензирования, который не только включают LGPLv3, но также любые из GPLv3.0 +, LGPLv3.0 + и AGPLv3.0 +, которые допускаются MPLv2 +.
«Это также позволит нам включать любые полезные улучшения, которые время от времени становятся доступными по этой лицензии».
Для этого есть веская причина, как заявляют разработчики: «Поскольку мы конкурируем с нашим собственным кодом, лицензированным по бесполезно разрешительной лицензии, MPL дает некоторые преимущества в привлечении коммерческих поставщиков, распространении в магазинах приложений Apple и Microsoft, а также по мере развития наших портов Android и iPhone на планшетах и мобильных устройствах «.
Двойное лицензирование в рамках LGPLv3 + и Mplv2 + позволяет переносить LibreOffice в магазины приложений, которые по извращенным причинам разрешают код под лицензией MPL с авторским левом, но не допускают код под лицензией GPL с авторским левом.
Однако у Apache OpenOffice есть свои особенности: текущий выпуск Apache OpenOffice основан на последнем выпуске Oracle OpenOffice.org. Но с тех пор IBM пожертвовала код Lotus Symphony для Apache с намерением интегрировать Apache OpenOffice и Lotus Symphony, который основан на более старых версиях OpenOffice.org и включает несколько лет адаптации IBM.
Следующая версия Apache OpenOffice, вероятно, будет сильно отличаться от текущей версии Apache OpenOffice, и различия, вероятно, будут касаться самого кода, потому что Lotus Symphony никогда не был открытым исходным кодом, и код никогда не выпускался в апстриме.
По сути, и Apache OpenOffice, и LibreOffice имеют одну и ту же проблему — перебазирование кода, чтобы исправить унаследованную амбивалентность в лицензировании.
Последний поворот в наследстве OpenOffice.org заключается в том, что текущий выпуск Unbreakable Linux от Oracle, который является клоном Red Hat Enterprise Linux, включает LibreOffice, ответвление сообщества OpenOffice.org , в качестве предпочтительного офиса. пакет повышения производительности, а не Apache OpenOffice, официальная версия кода, которым он когда-то владел.
(2 оценок, среднее: 5,00 из 5)
Загрузка...
Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!
Спасибо! Ваша заявка принята
Спасибо! Ваша заявка принята
