Многие разработчики и дизайнеры хотят выпускать свою продукцию в мир как проекты с открытым кодом. Они хотят, чтобы другие могли брать их коды за основу для своей работы и делились ими, поэтому сообщество в поддержку открытых кодов такое энергичное. Практически для любых целей, которые вы только назовете, существует ПО с открытым кодом. Большинство дизайнеров постоянно использует программы с открытым кодом (WordPress, Drupal и многие другие CMS – все это ПО с открытым кодом).
Но многие разработчики и дизайнеры не совсем ясно представляют себе, что, собственно, означают разные типы лицензий для ПО с открытым кодом. От каких прав они отказываются, когда выбирают лицензию с открытым кодом (Open-Source license)? Без четкого понимания того, что именно означает тот или иной вид лицензии и как ее правильно применять, разработчик не может принять взвешенное решение относительно того, какую из лицензий применить для своей работы.
Что такое лицензирование?
Много путаницы происходит от того, что мы не вполне понимаем, что такое лицензирование вообще. Когда вы лицензируете свою работу, вы не отдаете ни одного из своих прав. Вы все еще владеете оригинальными авторскими правами (или патентом, если он у вас есть) на эту работу. Что делает лицензия? Она гарантирует другим специальные разрешения для использования этой работы.
Он вам не Open Source / Тайная империя свободного ПО
Лицензирование это прекрасная альтернатива тому, чтобы просто опубликовать свою работу на публичном домене или время от времени давать разрешение на пользование ею. Публикуя работу на публичном домене, вы отказываетесь от всех авторских прав, и никто не обязан указывать вас в списке оригинальных авторов или участников разработки. В последнем случае, дело может дойти до того, что вы будете тратить больше времени на выдачу индивидуальных разрешений, чем разработку дизайна или ПО.
Лицензии с открытым кодом (Open-Source лицензии) облегчают другим пользователям работу по участию в доработке проекта, без оформления специального разрешения. Она также разрешает вам, как оригинальному автору, быть уверенным в том, что вы получите за свою работу хотя бы репутацию. Она также помогает предотвратить случаи, когда другие люди выдают вашу работу за свою.
GNU, General Public License – Стандартная общественная лицензия
GNU, General Public License (GPL) , Стандартная общественная лицензия, наверное, используется для проектов с открытым кодом чаще всего. GPL гарантирует и предоставляет разработчикам, которые работают над проектами с открытым кодом, наиболее широкий спектр прав. В основном, она позволяет пользователям легально копировать, распространять и модифицировать ПО. Это означает, что вы можете:
* Копировать ПО
Копировать его на ваш собственный сервер, сервера ваших клиентов, ваш личный компьютер, в общем-то, куда вам угодно. Количество копий, которые вы можете сделать, не ограничено.
* Распространять ПО, как вы хотите
Предоставлять ссылку на загрузку ПО на своем сайте. Разместить ПО на множестве USB-хранителях и раздать их. Распечатать исходный код программы и выбрасывать его с крыш домов (хотя, не делайте этого, пожалуйста, потому что это будет бессмысленной тратой бумаги и создаст кучу мусора).
В чем смысл open source?
* Распространять ПО за плату
Если вы хотите получать деньги за предоставление этого ПО, разместить его на чьем-то сайте или сделать еще что-либо подобное, вы можете это сделать. Но вы должны дать им копию GNU GPL, в которой, вообще-то, указано, что они могут получить эту же копию в другом месте бесплатно. Лучше всего быть изначально честным насчет этого и иметь веские доводы, чтобы привести их в ответ на вопрос, почему вы просите денег за этот продукт.
* Делать любые модификации с этим ПО
Если вы хотите добавить или удалить какую-то часть функционала программы, вперед. Если вы хотите использовать часть кода в другом проекте, вы можете сделать и это. Единственный подвох состоит в том, что в таком случае тот, другой проект должен быть также выпущен под GPL лицензией.
Имейте в виду, очень важно понимать, что распространение исходного и двоичного кодов — это разные вещи. В некоторых лицензиях есть вопросы и ограничения, если лицензия используется с приложениями, которые выпускаются с другими лицензионными соглашениями. Узнать подробности вы можете, прочитав статью « Практическое руководство по соответствию GPL ». Чтобы воспользоваться GPL, вам следует включить определенную информацию в код программы, а также приложить копию лицензии.
GNU – Стандартная общественная лицензия с меньшими правами (Lesser General Public Licence)
Вы также должны знать о другой лицензии GNU: Стандартной общественной лицензии с меньшими правами ( Lesser General Public Licence (LGPL). Она дает меньше прав на работу, чем стандартная GPL. В общем, LGPL подходит для библиотек, которые хотят разрешить размещение ссылок на ПО, распространяющееся не по GPL, а также ПО с закрытым исходником. Из-за того, что GPL требует, чтобы другие программы, в которых использовались части кода, распространяющего по этой лицензии, также распространялись по лицензии GPL, разработчики не могут пользоваться GPL-лицензированным кодом для платных и патентованных программ. LGPL отрицает это условие, не требуя, чтобы другие проекты, использующие части этого кода, были лицензированы такой же лицензией.
Лицензия BSD
Лицензия BSD дает разрешение на предоставление ряда бесплатных лицензий на ПО, в которых оговорено меньше ограничений по распространению, по сравнению с другими бесплатными лицензиями, такими как GNU (General Public License – Стандартная общественная лицензия). Среди нескольких разных версий лицензии, особенно важны два из них: Новая лицензия BSD/Модифицированная BSD лицензия, и упрощенная BSD лицензия/лицензия FreeBSD. Обе были заявлены как GPL-совместимые лицензии на бесплатное ПО и приняты организацией Open Source Initiative, как лицензии с открытым кодом.
Новая BSD лицензия («лицензия из 3 пунктов») позволяет неограниченное распространение такого ПО для любых целей при условии соблюдения условий изложенных в уведомлении об авторских правах и учета прописанного отказа от гарантий. Лицензия также включает пункт, ограничивающий использование имен спонсоров для поддержки полученной работы без специального разрешения. Первичная разница между Новой BSD лицензией и Упрощенной BSD лицензией в том, что последняя не включает пункт относительно одобрения (передачи).
Лицензия MIT
Лицензия MIT – это самая короткая и, возможно, самая толерантная из всех популярных лицензий на ПО с открытым кодом. Её условия очень свободны и дают больше разрешений, чем большинство других лицензий. Основные условия этой лицензии (не считая информации, что она предоставляется без гарантий, что входит в последний ее параграф), таковы:
Данная лицензия разрешает пользователям, бесплатно получившим копию ПО и сопутствующей документации (в дальнейшем именуемых «Программное Обеспечение»), без ограничений использовать это ПО, включая неограниченное право на использование, копирование, модификацию, добавление, публикацию, распространение, сублицензирование и/или продажу его копий, также как и тем, кому предоставляется это ПО, при соблюдении следующих условий:
Авторские права и данные условия должны быть включены во все копии или значимые части данного ПО.
Это означает, что:
* Вы можете использовать, копировать и модифицировать ПО, как захотите. Никто не может запретить использовать его в каком-либо из ваших проектов, копировать его столько раз, сколько вы захотите и в любом формате, в котором вы захотите, или изменять его, как вы захотите.
* Вы можете отдавать данное ПО бесплатно или продавать. У вас нет никаких ограничений на способ распространения ПО, защищенного такой лицензией.
* Единственное ограничение состоит в том, что ПО должно поставляться в комплекте с лицензионным соглашением.
Лицензия MIT – наименее строгая из всех лицензий. В ней, в общем, говорится, что каждый может делать все, что он хочет с лицензированным материалом, при условии, что продукт будет сопровождаться лицензией.
Лицензия Apache
Лицензия Apache , версия 2.0, предоставляет пользователям ПО несколько прав. Эти права можно применить как к авторским правам, так и к патентам. Из-за того, что некоторые лицензии применяются только к авторским правам, но не к патентам, гибкость этой лицензии станет явным доводом в ее пользу для разработчика с патентом, при выборе лицензии (прочитайте эту статью на How Stuff Works, там дается объяснение разницы).
Вот несколько подробностей относительно того, что позволяет делать лицензия Apache:
* Права вечны
Как только вы их получили, вы можете пользоваться ими всегда.
* Права распространяются по всему миру
Если вы получили права в одной стране, они работают во всех странах. Например, если вы живете в США, а оригинальная лицензия была получена в Индии, согласно этой лицензии, вам не могут запретить использовать программный код.
* Права даются совершенно бесплатно и без каких-либо комиссионных выплат
Вас не только не попросят заплатить авансом за использование ПО, но у вас также не попросят никакой платы, ни во время использования ПО, ни когда-либо еще.
* Эти права неисключительны
Вы можете пользоваться этой лицензированной работой, но также может и кто угодно.
* Эти права окончательны (безвозвратны)
Никто не может забрать у вас права, как только вы их получили. Другими словами, вам не нужно волноваться, что в дальнейшем, когда вы создадите на основе лицензированного кода какой-то потрясающий продукт, кто-то заберет его и скажет: «Извините, вы не можете больше пользоваться этим кодом». (Пункт в лицензионном соглашении утверждает, что если вы подадите на кого-то в суд за нарушение патента по кому-либо продукту, распространяемому по этой лицензии, ваша лицензия будет аннулирована. Но это касается только патентованных работ, и, если вы не собираетесь подавать на кого-то в суд из-за этой работы, вам не нужно переживать об этом.)
При перераспределении кода также действуют особые требования, большей частью относительно создания хорошего имиджа и репутации людям, которые работали над созданием кода и поддержке той же лицензии.
Creative Commons
Лицензии Creative Commons (CC) – это не совсем лицензии на открытый код, но они обычно используются для дизайнерских проектов. Среди СС – большое разнообразие лицензий, каждая и которых предоставляет определенные права. Лицензия CC имеет четыре основные части, каждая их которых может быть установлена индивидуально или в комбинации с другими. Вот краткий обзор этих частей:
* Attributed – С указанием авторства
Автор должен быть указан как создатель работы. Помимо этого, работа может быть модифицирована, она может распространяться, копироваться, а также использоваться любыми другими способами.
* Share Alike – С указанием авторства — Копилефт
Эта лицензия позволяет другим перерабатывать, исправлять и развивать работу даже в коммерческих целях при условии указания авторства и лицензирования производных работ по лицензии СС.
* Non-Commercial – Некоммерческая
Работа может быть модифицирована, она может распространяться и т.д., но не для коммерческих целей. Что до определения «коммерческие цели», то оно тут немного неопределенное (ясного определения там не приводится), так что вы можете прояснить его для использования с вашими собственными проектами. Например, некоторые могут интерпретировать фразу «некоммерческое использование», как просто означающее, что вы не можете продавать работу. Другие могут понять его, как условие, что вы не можете даже размещать эту работу на веб-странице, где есть реклама. Еще кто-то может счесть что-либо «коммерческим», только если это приносит прибыль.
* No Derivative Works – Без производной работы
Это означает, что вы можете копировать и распространять лицензированную работу, но вы не можете ее ни коим образом изменять или создавать работу на основе оригинала.
Как мы уже говорили, эти части CC лицензии можно комбинировать. Наиболее строгая лицензия – лицензия «Attribution, Non-Commercial, No Derivatives», что означает, что вы можете свободно распространять работу, но не можете вносить никаких изменений в работе или дорабатывать ее, и вы должны указывать создателя оригинала. Это хорошая лицензия для того, чтобы показать свою работу, но сохранять более или менее полный контроль над тем, как она используется. Наименее ограниченная – это лицензия «Attribution», которая означает, что, пока люди упоминают вас как автора, они могут делать с работой все, что захотят.
Лицензии CC используются чаще всего для дизайнерской работы, чем для разработки ПО, но ничто не мешает вам использоваться ее для разработки ПО в будущем. Просто внимательно изучите что защищает каждая ее часть.
Обнаружили ошибку или мёртвую ссылку?
Выделите проблемный фрагмент мышкой и нажмите CTRL+ENTER.
В появившемся окне опишите проблему и отправьте уведомление Администрации ресурса.
Нужна органическая вечная ссылка из данной статьи? Постовой?
Подробности здесь
Вам понравился материал? Поблагодарить легко!
Будем весьма признательны, если поделитесь этой статьей в социальных сетях:
Источник: www.coolwebmasters.com
Скрытые траты на открытое ПО. Какие риски стоят денег?
Все больше компаний используют в своей практике open source. Чем он привлекает бизнес? Казалось бы, ответ в названии: свободой использования и бесплатностью. Но опытные приверженцы знают, что с открытым ПО не так все просто. И согласие иметь дело с ним означает необходимость погружаться в глубины технологий, тратить деньги и время команд.
Как к этой особенности адаптировались компании?
Идея открытого и бесплатного софта к 2021 г. изменилась окончательно. В мире ИТ осталось мало проектов, которые не имели бы за спиной компаний, выполняющих роль основного коммитера. Изначально свободные решения сегодня покупаются корпорациями и становятся частью корпоративных экосистем. Бесплатность open source — практики это подтверждают, — условна. Получается, что открытое бесплатное программное обеспечение и не свободное, и платное?
Почему все хотят open source?
Open source пришел к нам из мира интернета. Небольшие интернет-компании не могли позволить себе дорогие коммерческие продукты и брали open source, вкладываясь в собственную разработку. Скорость изменений была и остается для них культом и способом выживания.
Когда эту ценность стал разделять enterprise-сегмент, он тоже начал пользоваться инструментами свободного ПО. «Главными проводниками и двигателями open source в ИТ являются разработчики. И это понятно: многие продукты со свободным кодом созданы в парадигме unix way, когда каждый продукт отлично справляется с одной задачей.
ИТ-ландшафт сегодня компаний усложняется, он состоит из небольших компонентов, которые в совокупности дают наиболее эффективное решение, — рассказывает Александр Краснов, руководитель лаборатории DevSecOps «Инфосистемы Джет». — Кроме того, сила open source-проектов — в постоянном улучшении. Например, с одним только Kubernetes работают больше 3 тысяч контрибьюторов.
Не каждому вендору по силам иметь такой многочисленный штат специалистов, вкладывающихся в один-единственный продукт. Соответственно, производитель ПО не может обеспечить такую же космическую динамику развития того или иного софта». Получается, что тысячи заинтересованных людей создают новые продукты и фичи в ответ на вызовы конкретного бизнеса. Это делает open source инструменты максимально близкими к эталонным решениям самых насущных задач.
Свежее исследование «Положение открытого ПО в крупных коммерческих компаниях» от Red Hat говорит, что сегодня 90% лидеров ИТ-индустрии используют open source, применяя его для модернизации ИТ-инфраструктуры (64%), разработки приложений (54%) и цифровой трансформации (53%). Пандемия только подстегнула эту тенденцию.
Переход к удаленной работе вынудил многие организации увеличить усилия по цифровой трансформации, а значит, и усилил проникновение открытого ПО на предприятиях. Например, растет использование условно-бесплатного Kubernetes, так как бизнес все чаще использует технологии контейнеризации. В Red Hat считают, что инфраструктура, основанная на контейнерах и Kubernetes, является основой новой волны разработки приложений и ключом к цифровой трансформации. Этот тезис подтверждает и опыт Сбербанка в Казахстане. «Наш мобильный банк уже много раз признавался лучшим в Казахстане. Переход на приложение с микросервисной архитектурой — еще один шаг на пути кардинального развития мобильного банкинга, — говорит Нурсултан Таскаранов, заместитель председателя правления ДБ Сбербанка. — Это открывает для нас перспективы по выводу нового функционала: мы ускорим Time-To-Market, не повлияв при этом на взаимодействие клиентов с банком».
Проприетарное ПО начинает и проигрывает?
У «Леруа Мерлен» сегодня имеется серьезная экспертиза в вопросе адаптации свободного ПО. Почти все инфраструктурное и APLM commodity ПО построено именно на базе открытого софта. Это и базы данных (Mongo, PostgreSQL, Kassandra и пр.), и BPM Kamunda, и системы обмена сообщениями, и PaaS, и ПО для оркестрации микросервисов (OpenStack, K8S).
Как ритейлер выбирает, какие задачи решать с помощью open source, а какие ПО от вендора? Все корпоративные системы этой компании можно разделить на группы в соответствии с тем, каким образом они отвечают на вызовы бизнеса. Одни автоматизируют уникальные процессы, являющиеся конкурентным преимуществом и ноу-хау, и их разработка происходит, как правило, на открытом стеке.
И есть системы, которые поддерживают обслуживающие функции бизнеса. Самый распространенный пример последних — это бухгалтерия и финансовый учет. «Большинство проприетарных бизнес-приложений удобны тем, что уже адаптированы к быстро меняющемуся законодательству. Но если целевые процессы компании не ложатся в логику покупаемых систем, то начинаются масштабные проекты по скрещиванию «ужа с ежом». В итоге тратятся деньги и время, а еще появляются риски, связанные с поддержкой и обновлениями, — объясняет Александр Бондарик, руководитель интеграционной и low-code платформ «Леруа Мерлен». — В этом случае значительная ценность проприетарного ПО (поддержка и сильная внешняя экспертиза) — просто теряется».
Реальная стоимость чистого open source
Выгоды и факторы, определяющие интерес к свободному софту понятны. Например, в «Российском союзе автостраховщиков» при создании АИС ОСАГО обращение к open source имело экономические цели. Евгений Уфимцев, исполнительный директор РСА отмечает: «При разработке платформы стоял вопрос экономии бюджета и в будущем мы хотели быть максимально независимыми от конкретного разработчика. Именно поэтому мы и выбрали open source».
Но важно держать в голове простой факт: такие продукты не бесплатны. Нужны адаптация, интеграция, поддержка — и тут начинаются траты. Компания платит своим временем. Требуется собственная экспертиза, чтобы разобраться с продуктом. Специалисты на рынке тоже не самый доступный ресурс. «Находить высококвалифицированных инженеров сейчас непросто.
Рынок перегрет, и пока что становится только хуже», — отмечает Александр Бондарик.
Возникают сложности не только с интеграцией, но и с эксплуатацией. Технологии open source и крупный бизнес — это две разные идеологии.
И основные трудности возникают из-за конфликта возможностей open source и требований крупного бизнеса к надежности. «Приведу пример из проекта построения ИТ-инфраструктуры под новую АИС ОСАГО, — делится опытом Александр Краснов. — Разработчики запросили СУБД PostgreSQL. А нам нужно гарантировать отказоустойчивость, а значит, создать кластер.
Но в составе этой СУБД нет средств по организации кластера высокой доступности. Тогда в ход пошли сторонние ИТ-инструменты. Из этого возникла вторая задача, продиктованная высокими стандартами надежности, — защита от логических сбоев кластера. И это тоже вызов, потому как возможности резервного копирования в СУБД не отвечают требованиям эксплуатации крупных компаний».
При этом проверенные временем корпоративные системы резервного копирования ограниченно поддерживают резервное копирование и восстановление кластерных конфигураций БД, для управления которыми используется кластер PostgreSQL. В итоге появилось решение на основе ПО Patroni и Commvault.
Бесплатное открытое ПО имеет свою не всегда проявленную стоимость. Она складывается из затрат на обучение специалистов, которые будут разрабатывать новый функционал и поддерживать ПО.
Кроме того, нужно помнить: если с опенсорсным внедрением что-то случится, то просить о помощи будет не у кого и ИТ-команде придется разбираться с проблемами самостоятельно. «У нас использовалась СУБД с открытым кодом Cassandra в архитектуре сложного нагруженного real-time аналитического решения, — вспоминает Александр Бондарик. — Внутренние ресурсы не справились с операциями и оптимизацией системы. После определенного порога нагрузки стало сложно поддерживать высокую доступность системы. На рынке не оказалось доступных компетенций, приглашенные интеграторы также не смогли решить задачу. Пришлось менять архитектуру и решение уже на поздних этапах — эксплуатации зрелого продукта».
По мнению Андрея Пономарева, начальника управления IaaS Росбанка, структура затрат при использовании open source может быть иной — в банке используется Red Hat Openshift: «Можно сказать, что разработчики полностью перестали тратить время на инсталляцию и конфигурирование платформы. Да, состав команд вырос за счет появления в каждой из них DevOps-инженера. Но в результате весь пласт работы с операционными системами, их обновлением, настройкой ПО просто исчез. Все, о чем необходимо заботиться, — это написание скриптов выкладки, тестирования и прохождения CI/CD-конвейера. Все остальные задачи выпали из обязанностей проектной команды и о них не надо задумываться».
«Мы опросили 108 крупных компаний о сложностях покорения технологий контейнеризации. 44% наших респондента имеют дело с «ванильным» Kubernetes, — говорит Александр Краснов. — И когда они говорили о трудностях, отмечали проблемы надежности (27%), обеспечение безопасности (25%), и далее по убыванию: сложности с сетевым взаимодействием, хранением, масштабированием, отказоустойчивостью».
Открытое ПО необходимо тестировать на совместимость с другими приложениями и системами компании. В «Леруа Мерлен» это происходит в рамках регрессионного тестирования на стейджинге приложений. Выравнивание и совместимость — ресурсозатратная, но необходимая активность. На такие процессы ритейлер выделяет время команд.
Поддержка стека open source также становится нетривиальной задачей. Александр Краснов из «Инфосистемы Джет» отмечает: «Продуктов с открытым исходным кодом крайне много, в случае проблем и вопросов компании остаются с ними наедине. Получается, поддержка требует экспертизы по каждому из используемых продуктов. Накапливать ее у себя? Это дорого.
Поэтому часто логичным шагом для бизнеса становится передача обслуживания open source во вне. Это яркий тренд, потому что по сравнению с 2019 г. это направление бизнеса в нашей компании выросло на 25%».
Планы насмарку
Открытое ПО может сработать отлично, а может и не взлететь. Иногда получается очень удачно. «Один из успешных примеров — замена проприетарной системы API менеджмента на Open Source based, — рассказывает Александр Бондарик. — Это оказалось дешевле в полтора раза с точки зрения расходов на персонал и лицензии. Появились возможности коллаборации и доступ к бэклогу продукта. Проблемы отсутствия критически важного для нас функционала не было. Кроме того, удалось избежать рисков из-за изменения вендором курса развития софта».
Сложность же заключается в том, что спланировать все траты на старте не выходит. Затраты очень зависят от продукта — где-то получается «дешево отделаться», а местами использование open source выходит значительно дороже, чем покупка проприетарного ПО. «Посчитать затраты не так-то просто.
Применение инструментов open source мало похоже на внедрение, скорее это новая культура плавного изменения инструментария и ландшафта предприятия, — подтверждает Александр Бондарик. — Для себя мы поняли, что за гибкость и свободу приходится расплачиваться большей ответственностью и усилиями. При использовании open source нужно принимать риски отказа систем из-за не обнаруженных вовремя проблем, возможную нехватку внешних ресурсов, готовых оперативно устранить инцидент, думать о сложностях при обновлении ПО и об уязвимостях. Рассчитывать приходится в основном на себя. Надо иметь экспертизу внутри компании или надежного партнера, быть готовыми тратить большую часть бюджета на Rhttps://www.cnews.ru/articles/2021-08-02_skrytye_traty_na_otkrytoe_pokakie» target=»_blank»]www.cnews.ru[/mask_link]
Open-source лицензии: как с ними дела обстоят в России?
Несмотря на малочисленную практику, в ходе разработки важно проверять, соблюдены ли все условия open-source лицензий.
В США правообладатели open-source ПО тщательно следят за соблюдением условий лицензий. Даже незначительное нарушение может стать поводом для судебного разбирательства. В России открытые лицензии официально появились лишь в 2014 году. Юристы Versus.legal предлагают посмотреть, возникали ли за это время какие-либо споры по открытым лицензиям в российских судах.
В теории
Открытая лицензия – это вид лицензионного договора, на основании которого пользователь получает простую лицензию на использование произведения, в том числе ПО. Она заключается в упрощенном порядке: пользователь акцептует условия оферты, когда скачивает ПО, ставит галочку или совершает другие действия.
Открытая лицензия не обязательно должна быть безвозмездной. Но если в ней не написано иного, то она признается таковой. Также в лицензии может быть срок. Если он не указан, то она действует 5 лет.
Раз открытая лицензия – это обычный лицензионный договор, то правообладатель может прописать в нем любые условия. Например, разрешить модификацию своей программы, но только при условии, что её результат будет предоставляться всем желающим безвозмездно.
Есть множество популярных разновидностей открытых лицензий, которые используется по всему миру: GNU General Public License, MIT License, Apache License, Creative Commons и другие. Каждая из них содержит свои нюансы, а ряд лицензий несовместимы между собой.
Как со спорами в Америке?
Западные правообладатели open-source ПО следят за тем, как исполняются условия открытых лицензий. А в случае нарушений подают иск в суд.
Например, компания Free Software Foundation (FSF) подала иск против технологической корпорации Cisco Systems. FSF утверждала, что в прошивках Wi-Fi роутеров Cisco был использован исходный код, принадлежащий FSF и распространяемый на условиях GNU General Public License. Cisco не раскрыла исходный код прошивки, как этого требовали условия GNU GPL. Поэтому истец потребовал запретить распространение прошивки.
По результатам спора стороны пришли к мировому соглашению. Оно предполагало, что Cisco назначит специального директора, который должен проверить соблюдение условий открытых лицензий и отчитаться о результатах FSF. Кроме того, Cisco согласилась опубликовать на своем сайте исходных код ПО, используемого в Wi-Fi роутерах, а также выплатить компенсацию в пользу FSF.
Это не единственное дело в США, где за соблюдением условий открытых ПО следят специальные организации.
А как в России?
Мы посмотрели российскую судебную практику, и за 7 лет официального признания открытых лицензий в России споров, которые касаются софта и приложений, не обнаружили. В отличие от США, в России не было споров, когда IT компания нарушила условия open-source лицензии. Возможно, они возникали, но стороны урегулировали их до суда.
Зато большая часть споров по открытым лицензиям касается использования фотографий с нарушением условий открытых лицензий. Среди них есть несколько примечательных и полезных для разработчиков ПО.
Дело «Уральского авторского общества»
Уральское авторское общество подало иск против компании «Центр недвижимости «Северная Казна», утверждая, что ответчик незаконно разместил фотографию на своем сайте. Авторское общество требовало 600 000 рублей компенсации.
Сначала суд удовлетворил иск, но после длительного обжалования в различных инстанциях отказал. Суд указал, что автор фотографии разместил её на сайте «Википедия», а значит принял условия открытой лицензии «Википедии». Регистрируясь на сайте, автор согласился с условиями открытой лицензии.
На сайте ответчика была указана гиперссылка на страницу Википедии, где имелась информация об авторе. Поэтому Центр недвижимости не нарушил условия лицензии, а истец не вправе требовать компенсацию, т.к. фотография распространялась на условиях открытой лицензии.
Хотя дело касалось фотографии, выводы из него полезны для разработчиков ПО:
- Для принятия условий открытой лицензии достаточно совершения определенных действий: например, регистрации на сайте. Если из действий явно следует, что пользователь согласился с условиями лицензии, то никаких дополнительных документальных подтверждений не нужно.
- Если разработчик использует произведения (ПО, изображения, музыку), которые попадают под открытые лицензии, то должен проверить, чтобы соблюдались все её условия. Если нет, то правообладатель может взыскать компенсацию.
Дело ФПК
Есть противоположное дело. Фотограф обратился с иском к дочке «РЖД» – компании «ФПК». В одном из поездов фотограф увидел расписание с фотографией собора, которую он сделал, а затем разместил на «Викискладе».
Суд взыскал компенсацию с ФПК, поскольку компания нарушила условия открытой лицензии Creative Commons:
- На фотографии не было указано, кто является автором;
- Не было ссылки на лицензию;
- Внесенные в фотографию изменения не были обозначены.
- Важно, что суд проверил соблюдение условий открытой лицензии. Поэтому в случае возникновения спора вокруг приложения или софта, суд аналогичным образом будет проверять соблюдение условий открытой лицензии.
Что в итоге?
- Пока в российских судах не было споров о нарушении условий open-source лицензий при разработке ПО.
- Большинство споров по открытым лицензиям касаются использования фотографий с нарушением условий. И даже таких споров не очень много.
- Несмотря на малочисленную практику, в ходе разработки важно проверять, соблюдены ли все условия open-source лицензий. Особенно, если вы планируете продвигать ПО на зарубежных рынках (США, ЕС). Там за этим следят более строго.
- Если разработчик не проверит соблюдение условий открытых лицензий при создании ПО, и это приведет к нарушению, то он не только заплатит компенсацию, но и не сможет распространять свое ПО в будущем. В таком случае разработчик несёт существенные риски в рамках реализации своего проекта.
Источник: apptractor.ru
Home
В жизни многих разработчиков и большого количества IT-компаний настаёт момент, когда создание open source-проектов становится не менее важным, чем написание кода для внутренней разработки. По просьбе «Лаборатории Касперского» Евгений Мацюк, один из создателей open source-фреймворка для автотестов Kaspresso, делится своими рассуждениями, почему это решение оказалось полезно как для сообщества, так и для самой компании.
Что такое современный open source
Сейчас любой проект, любую свою разработку можно легко выложить в свободный доступ в онлайн-репозиторий. Самый популярный, конечно, GitHub, там крупное и активное коммьюнити из СНГ, а зарубежных пользователей ещё больше. Но есть и альтернативные платформы, их несложно найти.
Ещё до работы в «Лаборатории Касперского» я выкладывал на GitHub свои open source-проекты, например архитектурный CookBook по оформлению Android-проектов. Kaspresso мы с командой тоже выложили на GitHub.
Как зарождался Kaspresso
В 2018 году в «Лаборатории Касперского» уже был отдел автотестирования. Перед коллегами стояла задача — сделать круто работающие интеграционные и E2E-автотесты, которые позволят значительно сократить релизный цикл. На одной конференции мы услышали доклад про автотестирование, из которого узнали несколько важных фактов.
Во-первых, у коллег из компании-докладчика тестирование не просто работало, а сильно сокращало релизный цикл. Во-вторых, они основывали свои автотесты на нативных инструментах, например Espresso. Там был ряд преимуществ по сравнению с использовавшимся у нас на тот момент Appium, который позволял писать E2E-тесты, но не давал, например, разрабатывать более быстрые и стабильные функциональные и интеграционные тесты.
Я до этой конференции вообще не был причастен к теме автотестов, занимался в компании мобильной разработкой. Но после доклада и пары выпусков подкаста AndroidDev Podcast загорелся. Где-то полгода изучал вопрос, а потом постепенно убедил менеджмент, что будущее именно за нативными автотестами и что нам нужно выделить людей на такой проект. Мы начали разрабатывать Kaspresso с начала 2019 года.
Почему мы решили сделать Kaspresso опенсорсным
В ходе разработки мы довольно быстро начали оформлять все наши наработки в полноценный фреймворк. Сперва объединили их в библиотеку, потом допиливали к ней фасад, прихорашивали, чтобы другие разработчики внутри «Лаборатории Касперского» тоже могли пользоваться автотестами. Уже на этом этапе и у меня, и у коллег появилась мысль, что выходит хорошо и проект надо бы сделать опенсорсным.
Сначала мы решили оценить, насколько вообще сообществу нужен Kaspresso. На крупной конференции в 2019 году представили доклад о том, как идёт работа, какие получены результаты. После этого выступления нам начали активно писать: «Ребята, очень круто, а опенсорс планируется?». Кроме того, я пообщался на тему автотестирования с руководителем Android-разработки HeadHunter.
У их команды были похожие идеи и результаты. Мы поняли, что сообщество заинтересовано, есть другие команды, с которыми можно объединить усилия, значит, нужно опенсорсить. Я, как руководитель проекта, пошёл к менеджменту и предложил сделать разработку по Kaspresso открытой.
Почему менеджмент иногда выступает против open source
Зададимся простым вопросом: о чём больше всего заботится бизнес? Очевидно, что о финансовом благополучии. О том, чтобы разрабатываемые продукты приносили прибыль.
Первая причина, почему опенсорс пугает бизнес, тоже простая и понятная: как заработать на опенсорсной разработке? Её, очевидно, не всегда можно монетизировать, ведь она не повышает напрямую показатели и метрики продукта. Её зачастую сложно конвертировать в деньги.
Дело, конечно, не только в прибыли. Каждая разработка в идеале — это в том числе конкурентное преимущество для компании. Например, компания создала уникальный проект с крутыми фичами и теперь может делать что-то, что недоступно другим игрокам на рынке. Уступать подобные преимущества, отдавать их даром всем, в том числе и конкурентам, бизнес тоже зачастую не готов.
Наконец, стоит помнить, что на любую разработку уходят время и человеческие ресурсы. Когда менеджмент решает, что лучше: сделать новую фичу для уже существующей внутренней разработки или направить разработчиков на трудоёмкий open source-проект — выбор практически всегда очевиден.
Аргументы в защиту open source перед менеджментом
Разумеется, диалог о старте Open source-разработки или переводе туда уже существующего проекта будет в каждой компании разным. С Kaspresso нам повезло. Виктор Яблоков, руководитель мобильной разработки в «Лаборатории Касперского», поддерживает open source-проекты, так что отчасти менеджмент сразу был на нашей стороне. В другой компании руководство может быть идеологически против, и тогда никакие аргументы не помогут.
Чтобы убедить оппонента в споре, нужно приводить аргументы с его позиции. Бизнесу зачастую всё равно, почему open source — это хорошо для вас, команды и мира в целом. Но если донесёте, что это выгодно именно для самого бизнеса, тогда он заинтересуется.
Первый и самый важный довод: да, open source не конвертируется напрямую в деньги. Зато отлично конвертируется в таланты, которые будут эти деньги зарабатывать для компании в будущем. Сейчас в IT-сегменте идёт бескомпромиссная война за крутых специалистов. Одними деньгами её не выиграть: все крупные компании сейчас предлагают примерно одинаковые по уровню зарплаты.
Поэтому разработчик смотрит не только на деньги и условия, но и на сам бренд. Чего за последнее время добилась компания? Хорошие ли у неё продукты? Сильная ли команда? В этой ситуации open source для бизнеса — возможность «прорекламировать» бренд всем потенциальным соискателям.
К нам с момента запуска Kaspresso пришло немало ребят, которые на собеседовании честно говорили: «Да, впечатлился. Крутая разработка, пользуюсь сам, здорово, что такой open source-проект. Возьмёте поработать?».
То, насколько силён бренд с технической точки зрения, играет важную роль в долгосрочной перспективе. Да, выкладывая разработку в свободный доступ, бизнес может лишиться определённой части прибыли и в какой-то степени уникального технического преимущества перед конкурентами. Но зато узнаваемость бренда в сообществе при этом растёт, как и доверие рынка.
Ведь open source нельзя выложить сырым и костыльным. Сообщество не оценит. В СНГ люди не стесняются честно и жёстко говорить, что думают о подобных продуктах, поэтому команда, которая занимается такой разработкой, должна приложить все усилия, чтобы на выходе пользователи, внешние и внутренние, получили понятное и работающее решение. Если компания в состоянии сделать крутой open source-продукт, на который переходят конкуренты, это показатель того, что она лидирует в своей сфере. IT-гиганты вроде Google и Apple регулярно делятся с сообществом своими открытыми наработками, в том числе ради вот такого технического престижа.
С open source-продуктом проще подсветить свой бренд на международном рынке, а это тоже дорогого стоит. Нужно только организовать хорошую поддержку как минимум на английском. Если решение классное, то его начнут использовать люди из разных стран. Сейчас Kaspresso чаще всего скачивают американские пользователи, на втором месте немецкие и только на третьем — российские.
Перед выпуском Kaspresso мы провели большое количество исследований, постоянно общались с коллегами из других команд «Лаборатории Касперского», которые использовали автотесты в работе. По их отзывам многое меняли, прихорашивали.
Мы встречались с коллегами из Авито и HeadHunter, у которых тоже был опыт в разработке подобных проектов, чтобы с ними обсудить возможные ошибки и способы их обойти. Затем мы написали подробные и понятные гайды по использованию. В итоге получилось, что наши коллеги из других подразделений сразу получили мощный и при этом доступный набор инструментов, который после запуска не требовал никаких заплат и дополнений. Таким образом мы сохранили для бизнеса немало потенциальных человеко-часов.
Подытоживая, можно сказать, что open source дает бренду возможность привлечь к созданию решения специалистов извне, собрать профессиональное комьюнити вокруг себя, что может упростить решение многих проблем.
Почему разработчики должны быть заинтересованы в open source-проекте не меньше менеджмента
По опыту могу сказать, что классный open source рождается только у команд, которые готовы работать упорно, долго и с большой самоотдачей. Понятно, что если потребовать open source-продукт с новичков, которые пока не научились качественно делать фичи, то ничего толкового не выйдет. Но неужели что-то может пойти не так у опытной команды, которая просто будет работать без огонька?
Да, но далеко не сразу. Специалисты могут дотянуть продукт до релиза, и это будет хороший продукт. Но жизнь проекта в опенсорсе с версии 1.0 только начинается. Впереди годы более-менее активной поддержки и дорожная карта обновлений. Если самим разработчикам продукт не интересен (а менеджмент, как мы помним, в нём заинтересован далеко не в первую очередь), его не будут поддерживать должным образом, и со временем он зачахнет и забудется.
Вот почему важно, чтобы инициатива создания open source-проекта исходила в том числе и от разработчиков. Разберемся, чем могут быть полезны такие проекты им самим.
Преимущества, которые опыт создания open source проектов даёт разработчикам
Когда я присмотрелся к сфере автотестов, они меня очень заинтересовали. Я увидел в них настоящий «голубой океан», то самое решение, на которое ещё нет особого спроса только потому, что никто не создал должного предложения. Мне очень захотелось окунуться в воды этого океана. Плюс open source в том, что в таком проекте каждый может попробовать раскрыть себя с новой стороны.
Если человек найдёт какую-то боль своей компании и грамотно предложит менеджменту найти решение для неё с помощью open source-разработки, он будет решать крутые необычные проблемы. Будет непросто, но очень интересно. Если непросто, значит, качаются навыки: уникальные в зависимости от проекта hard skills и универсальные soft skills. Я, например, пока занимался Kaspresso, сильно прокачал владение Kotlin.
Ранее почти на нём не писал, так что в процессе многое узнал. Что касается мягких навыков, то при работе над open source-проектом учишься организовывать команду, общаться с людьми, с которыми до этого не работал, делать исследования, потому что в open source их действительно много.
Есть возможность попробовать себя в разных ролях. Я на проекте Kaspresso почувствовал себя в роли одновременно разработчика, продакта, проджекта, аналитика и техсаппорта. Это такой отрезвляющий опыт, сразу понимаешь, сколько задач стоит перед командой, кто чем занят, пока ты пишешь код, а также куда можно расти в будущем.
Признаем, что иногда, в том числе для роста, работу приходится менять. Так вот, очень скудно смотрится, когда просто пишешь в резюме:
— Четыре года занимался внутренней разработкой для
Даже если компания крутая. Занимался и занимался. По этой строчке совершенно непонятно, что именно ты там делал. Даже если расписать подробнее, работодателю будет очень сложно это проверить и увидеть твой уровень. Не зря же разработка внутренняя
Другое дело, когда пишешь:
— Разрабатывал фреймворк Android-автотестов Kaspresso: .
Если проект, которым ты занимался, выложен в open source и у него две тысячи звёздочек от пользователей на GitHub, то любой работодатель поймёт — ты умеешь нащупывать волнующие людей проблемы и придумывать крутые решения этих проблем. Значит, к тебе нужно присмотреться.
К тому же, по проекту сразу ясно, насколько ты владеешь теми hard skills, которые в своём резюме заявляешь. Это всё работает на твой личный бренд.
Open source — это полезно и интересно, как для компаний, так и для разработчиков. Более того, если подходить к такой разработке с умом, она сыграет свою роль в узнаваемости бренда, поднимет престиж компании и принесёт немало преимуществ, пусть порой и не таких мгновенно осязаемых, как разработка внутренняя.
Надеюсь, мои рассуждения помогут тем, кто сейчас готовится или только начинает разрабатывать open source проект. Призываю разработчиков в комментариях делиться собственным опытом и рассказывать свои истории о свободной разработке.
Источник: www.software-testing.ru