В чём разница между популярными Open Source лицензиями Объясняет Github


Оглавление (нажмите, чтобы открыть):

В чем разница между Free Software и Open Source.

Объясните, пожалуйста, в чем разница между Free Software и Open Source.

Re: В чем разница между Free Software и Open Source.

Re: В чем разница между Free Software и Open Source.

Я же вроде спрашивал по-русски?

Re: В чем разница между Free Software и Open Source.

OpenSource — открытые исходники.
Freeware — бесплатно, т.е. исходники могут быть и закрыты.

Re: В чем разница между Free Software и Open Source.

Ага, а Free Software — Cвободно-распространяемое программное обеспечение.

Re: В чем разница между Free Software и Open Source.

Free software means software that respects the users’ freedom. The philosophy of the movement is that users of software should be free to run it, study it, change it, redistribute it and publish modified versions.

Re: В чем разница между Free Software и Open Source.

> Freeware — бесплатно, т.е. исходники могут быть и закрыты.

Free Software <> Freeware. Это совершенно разные вещи.

Столман говорит, что у пользователя нормально, когда имеются четыре свободы:

Свобода запускать программу для любых целей (свобода 0)

Свобода изучать устройство программы и приспосабливать ее к своим потребностям (свобода 1). Это предполагает доступ к исходному коду программы.

Свобода распространять программу, имея возможность помочь другим (свобода 2).

Свобода улучшать программу и публиковать улучшения, в пользу всего сообщества (свобода 3). Это предполагает доступ к исходному коду программы.

Цитата из Столлмана:

RMS: Закрытое ПО неэтично, потому что оно лишает пользователя базовых свобод – контролировать свой собственный компьютер и сотрудничать с другими пользователями. Оно может быть также низкокачественным или небезопасным, но это вторичные вопросы. Я откажусь от него, даже если оно лучшее в мире, попросту потому, что я слишком высоко ценю свою свободу, чтобы отказаться от нее ради такого ПО.

Re: В чем разница между Free Software и Open Source.

Free Software — это GNU. Open Source — GNU, BSD, MPL и множество других лицензий открытого кода, которые в чём-то могут и противоречить GPL. Например, BSD позволяет использовать код под этой лицензией в закрытых программах.

Сравнительный анализ основных лицензий Open Source: GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license

Тезисы доклада на семинаре «Открытые системы: философия, технология, бизнес» (проведенного 30 января 2002 г. Институтом Логики и ALT Linux): Все шесть лицензий, которые будут рассматриваться в настоящем докладе, являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом. Эти же лицензии называются «лицензиями на свободное ПО» (free software licenses) на сайте проекта GNU Free software foundation (FSF).

1. Различие между категориями «free software» и «Open source».

Все шесть лицензий, которые будут рассматриваться в настоящем докладе, являются лицензиями, одобренными Open Source Initiative для распространения ПО с открытым исходным текстом. Эти же лицензии называются «лицензиями на свободное ПО» (free software licenses) на сайте проекта GNU Free software foundation (FSF). При этом совместимыми с лицензией GPL из указанных лицензий являются только три: LGPL, BSD и лицензия MIT. Лицензии Apache (версии 1.0 и 1.1), и Mozilla (версии 1.0 и 1.1) — лицензии на свободное ПО, несовместимые с GPL. В связи с этим хотелось бы кратко остановиться на различиях между концепциями «свободного ПО» (free software) и «ПО с открытыми исходными текстами».

Представители «Open Source Initiative», в частности г-н Давид Уилер (David A. Wheeler) употребляет эти термины, как синонимы, определяющие одно и то же понятие, однако указывает на их различное содержание. В своей статье он пишет: «Те, кто использует термин «ПО с открытыми исходными текстами» хотят подчеркнуть технические преимущества такого ПО (например, большую надежность и безопасность), тогда как те, кто использует термин «свободное ПО», хотят подчеркнуть независимость от контроля со стороны третьих лиц за использованием ПО».

Как считают представители FSF, в настоящее время Free Software и Open Source являются двумя самостоятельными движениями. «Мы не против движения Open Source, но мы не хотим, чтобы нас путали с этим движением», — так так указано на сайте FSF. Представители FSF считают, что понятие «ПО с открытыми исходными текстами» более-менее соответствует понятию «свободного ПО», однако предпочитают использовать именно последнее определение и приводят для этого целый ряд аргументов:

  • определение «открытый исходный текст» является слишком узким;
  • некоторые компании, разработчики «обычного» ПО используют определение «открытый исходный текст» в своих целях и придают этому определению совсем другой смысл.

2. Названия и тексты лицензий.

Тексты лицензий на английском языке можно найти как на сайте Open Source Initiative, так и на сайте GNU. Очевидно, что текст GPL и LGPL, а также изменения к ним или новые версии этих лицензий, если они появятся, лучше всего брать с сайта GNU. Однако тексты остальных лицензий: MIT, BSD, Mozilla public license, Apache software license лучше всего взять с сайта Open Source. Если вы внимательно прочитаете список лицензий на сайте Open Source и сравните его со списком лицензий на сайте GNU, то убедитесь, что отдельные лицензии на сайте GNU называются иначе. В частности, лицензия MIT на сайте GNU называется Expat license. Текст этой лицензии почти полностью соответствует тексту лицензии BSD, за исключением одного условия. В русских компьютерных изданиях упоминается также лицензия X-консорциума, или X11 (так она называется на сайте GNU). Этой лицензии нет в списке лицензий на сайте Open Source, может быть потому, что она практически повторяет лицензию MIT.

Отдельно следует остановиться на тексте лицензии BSD. Как известно, существует два варианта ее текста: с оговоркой о рекламе и без этой оговорки. Лицензия, которая одобрена для применения как Open Source, так и FSF — это лицензия без оговорки о рекламе. Эта оговорка была официально отменена директором Департамента Технологического Лицензирования Калифорнийского университета 22 июля 1999г. Текст лицензии BSD лучше брать с сайта Open Source.

В 2001г. появился еще один вариант лицензии BSD — это лицензия корпорации Intel «BSD+Patent License». Она специально разработана для того, чтобы позволить модифицировать и распространять ПО, которое может защищаться патентами на программное обеспечение корпорации Intel.

3. Совместимость с GPL.

Как уже было сказано выше, совместимыми с GPL из остальных пяти указанных лицензий, являются только три: LGPL, BSD, MIT. Совместимость с GPL означает, что разработчик вправе объединить модуль, который распространяется на условиях совместимой с GPL лицензии с модулем, распространяемым на условиях GPL, чтобы получить одну программу. Дальнейшее распространение полученной программы должно осуществляться в соответствии с условиями GPL (так называемый «Copyleft virus»).

4. Сравнительная характеристика лицензий.

Для наглядности сравнительную характеристику условий лицензий лучше всего представить в виде таблицы, где будет указано о наличии или отсутствии в лицензии тех или иных требований.

Лицензия GPL BSD MIT Mozilla public license Apache software license
Требуется указывать имя автора Да Да Измененные файлы должны быть помечены Нет Да Наименование производного ПО должно отличаться от наименования продукта создателей лицензии Нет Нет
Производные произведения должны распространяться на условиях первоначальной лицензии Нет Да ** Указана территория, на которую предоставляется лицензия Нет Да Отсутствие гарантий на ПО Да Да Предоставляется право применить другую лицензию не указано Да

Отдельно следует сказать о лицензии LGPL. Эта лицензия носит ограниченное применение:

  • она может применяться только к библиотеке;
  • произведение, производное от первоначальной библиотеки, также должно быть библиотекой.

Если создатель библиотеки решит заменить лицензию LGPL на GPL, то такая замена будет окончательной и повлечет за собой применение GPL ко всем последующим копиям данного экземпляра библиотеки и произведениям, производным от нее. LGPL содержит ряд специфических условий, в частности в отношении произведений, возникающих в результате связывания ПО, использующего библиотеку, с библиотекой. Такие произведения могут распространяться на любых условиях с соблюдением определенных требований LGPL.

* Если нет письменного разрешения об использовании наименования продукта создателей лицензии.
** В данном случае речь идет об исходном тексте.

GitHub и GitLab 2020

Сегодня служба управления репозиториями является одним из фундаментальных элементов совместной разработки программного обеспечения. Успешные атрибуты доставки для комбинации компонентов с открытым исходным кодом и сторонних компонентов, используемых совместно для создания цепочки поставок программного обеспечения. Эта цепочка поставок, которая вписывается в жизненный цикл разработки программного обеспечения, называется репозиторием. Выбор соответствующего репозитория для вашего проекта ускоряет ваши инициативы по разработке программного обеспечения, одновременно повышая эффективность для более быстрой и надежной сборки. Git — самая популярная система управления версиями, используемая для обеспечения плавного и эффективного процесса разработки программного обеспечения через репозитории Git. GitHub и GitLab являются двумя известными именами в сервисах хостинга репозитория Git. Мы кратко представляем и сравниваем два самых популярных сервиса Git-репозитория GitHub и GitLab.

Что такое GitHub?

GitHub — это веб-служба управления репозиторием и самый большой репозиторий исходного кода в мире, который объединяет самое большое сообщество разработчиков под одной крышей для совместной работы над проектами разработки программного обеспечения. Первоначально запущенный в качестве веб-сайта в 2008 году, GitHub вырос, чтобы стать крупнейшим в мире представителем репозитория Git с сообществом более 27 миллионов разработчиков со всего мира, сотрудничающим более чем с 80 миллионами проектов. Это самый большой в мире репозиторий кода, который позволяет пользователям разрабатывать, делиться и вносить вклад в проекты с открытым исходным кодом, написанные на более чем 300 уникальных языках программирования. Это центральное место для создания программного обеспечения и совместной работы над миллионами проектов с открытым исходным кодом вместе в команде и обмена идеями для лучшего рабочего процесса разработки программного обеспечения.

Что такое GitLab?

GitLab — это веб-менеджер Git-репозитория, разработанный GitLab Inc. для разработки современных проектов разработки программного обеспечения. Это простой, но современный полнофункциональный сервер Git, используемый крупными организациями, такими как Sony, IBM, Alibaba, NASA, O’Reilly Media, SpaceX, CERN и т. Д. В отличие от GitHub, он бесплатный и с открытым исходным кодом. GitLab предоставляет гибкие инструменты управления проектами, такие как «Отслеживание проблем», «Вехи групп», «Советы по выпуску», «Дорожные карты», «Отслеживание времени» и т. Д., Чтобы упростить совместные рабочие процессы для полного жизненного цикла разработки программного обеспечения. Это самый эффективный способ хранения репозиториев Git на централизованном сервере, что позволяет пользователям осуществлять полный доступ к своим репозиториям Git и контролировать их. Он очень похож на GitHub, но с дополнительными функциями, такими как легкий импорт из других популярных репозиториев Git, таких как GitHub, Google Code, Bitbucket и т. Д.

Разница между GitHub и GitLab

основной

Оба GitHub и GitLab — это веб-сервис Git-репозитория, который отслеживает изменения в проектах разработки программного обеспечения и его файлах с течением времени, что позволяет разработчикам совместно работать над веб-проектами под одной крышей. Как и GitHub, GitLab является менеджером хранилища для коллективного сотрудничества, но с более интуитивно понятным интерфейсом и его защитой, разрешениями и аутентификацией филиалов, что делает GitLab выдающимся.

популярность

GitHub, вероятно, первое имя, которое бросается в глаза, когда дело доходит до хостинга репозитория управления версиями, который объединяет крупнейшее сообщество разработчиков в мире для совместной работы над веб-проектами и делится своими идеями по процессу разработки программного обеспечения. Как крупнейший сервис хостинга репозитория, его популярность явно предшествует GitLab, который является гораздо более новой платформой, запущенной в 2011 году.

Открытый исходный код

Одним из ключевых различий между ними является то, что GitHub не является открытым исходным кодом, но он предлагает платные планы для частных репозиториев, которые обычно используются для размещения веб-проектов с открытым исходным кодом. Хостинг-сервис на самом деле бесплатный для проектов с открытым исходным кодом, но программное обеспечение, на котором оно основано, не является открытым исходным кодом. С другой стороны, GitLab является бесплатным и открытым источником для Community Edition, тогда как Enterprise Edition является закрытым исходным кодом.

Уровень аутентификации

Это относится к авторизации на основе уровней доступа. В GitHub владельцы или команды организации могут добавлять репозитории Git, а также изменять доступ к этим репозиториям для чтения, записи и администрирования. Вы также можете приглашать пользователей для совместной работы в вашем личном репозитории в качестве соавторов. В GitLab пользователи имеют разные уровни доступа в определенной группе или проекте на основе их соответствующих ролей. Администраторы GitLab в основном получают все разрешения.

Встроенный CI / CD

Одно из главных отличий между ними заключается в том, что GitLab предлагает собственный встроенный встроенный модуль Continuous Integration / Delivery (CI / CD), который вам не нужно устанавливать отдельно. Это поможет командам сократить ошибки в коде и обеспечить более быстрые результаты, придерживаясь стандартов качества вашей команды. Напротив, он не интегрируется с GitHub; на самом деле, для этого есть несколько инструментов.

GitHub против GitLab: Сравнительная таблица

Резюме

Оба GitHub и GitLab являются двумя наиболее популярными и широко используемыми услугами хостинга репозитория, используемыми для эффективного управления рабочим процессом разработки программного обеспечения. Оба они пригождаются большому сообществу разработчиков, особенно при работе в командах, но на многих фронтах они совершенно разные. Во-первых, GitHub не является открытым исходным кодом, тогда как GitLab Community Edition является бесплатным и открытым. Кроме того, GitLab имеет свою собственную непрерывную интеграцию и непрерывную доставку, уже встроенную, чтобы пользователям не приходилось устанавливать их отдельно.GitHub, с другой стороны, предлагает сторонние интеграции для работы CI / CD. GitHub существует уже более десяти лет, и это явно предшествует GitLab, когда дело доходит до популярности среди более крупных групп разработчиков и организаций.

Как выбрать Open Source лицензию для RAD фреймворка на GitHub

В этой статье мы немного поговорим об авторском праве, но в основном о выборе свободной лицензии для RAD фреймворка IONDV. Framework и для опенсорсных продуктов на его основе. Мы расскажем о разрешительной лицензии Apache 2.0, о том, что привело нас к ней и с какими решениями мы столкнулись в процессе.

Процесс выбора лицензии достаточно трудоемкий и к нему следует подходить уже изрядно начитанным и если вы не счастливый обладатель юридического образования, то перед вами открывается непаханое поле информации о разнообразных свободных лицензиях. Основное, что следует сделать это составить ряд ограничивающих критериев. В процессе обсуждения и осмысления, вы с командой сможете понять, что хотите разрешить пользователям вашего продукта, а что запретить. Когда на руках у вас уже есть некое описание, необходимо наложить его на существующие лицензии и выделить ту, где наибольшее количество пунктов совпало. Звучит конечно просто, но в реальности обычно даже после обсуждения остаются вопросы.

Сперва — ссылка на choosealicense.com, полезный сайт, которым мы активно пользовались. Особенно обратите внимание на сравнительную таблицу лицензий по 13 основным критериям. Да прибудет с вами английский и терпение.

Муки выбора

Начнем с общих признаков лицензий для свободного программного обеспечения. СПО подразумевает исключительно свободную лицензию, которая не ограничивает коммерческое и некоммерческое распространение по модели Open Core. Соответственно, выкладывая в сеть ПО под свободной лицензией нельзя полностью ограничить его передачу, распространение и продажу третьими лицами и к этому надо лишь морально подготовиться.

Свободная лицензия даёт пользователю право самому участвовать в обратной разработке ПО или изменять его другими доступными способами. Большинство лицензий не позволяет переименовывать продукт или проводить с ним любые манипуляции, изменяя права автора или/и владельца системы.

Основные интересовавшие нас вопросы о свободных лицензиях заключались в:

  1. Внесенные изменения в ПО должны быть зафиксированы и не имеют никакого отношения к правообладателю системы?
  2. Имя производного ПО не должно совпадать с именем ПО правообладателя?
  3. Можно ли изменить лицензию для любых новых версий на другую, в том числе и на проприетарную?

Внимательно посмотрев список самых распространенных лицензий, мы выбрали несколько, которые рассматривали более подробно. Потенциальные лицензии для IONDV. Framwork были: GNU GPLv3, Apache 2.0, MIT и MРL. MIT практически сразу исключили, это разрешительная некопилефтная лицензия, которая разрешает использование, модифицирование и распространение кода практически как угодно, а нас такой вариант не устраивал, мы все таки хотели чтобы лицензия регулировала отношения правообладателя и пользователя. Большинство не самых крупных проектов на GitHub выложено именно под лицензией MIT или ее различных вариаций. Сама лицензия очень короткая, и из запретов только указание авторства создателя ПО.

Следующей была лицензия MPL 2.0. Признаться мы не сразу к ней пришли, но изучив более подробно быстро исключили, так как основной недостаток такой — лицензия применяется не для всего проекта, а для отдельных файлов. Кроме того, если пользователь изменяет файл, то лицензию он изменить не может. По факту, как бы старательно ты не менял Open source проект, ты так и не сможешь его монетизировать, из-за подобной лицензии. Это кстати не касается правообладателя.

Подобная проблема сохраняется и у лицензии GNU GPLv3, она требует чтобы любой файл оставался под ней же. GNU GPL это копилефтная лицензия, которая требует, чтобы исходные коды производных работ были открытыми и оставались под этой же лицензией, то есть переписав две строчки кода, вы будете вынуждены зафиксировать свои изменения и при дальнейшем использовании или распространении сохранять код под GNU GPL. В данном случаю, это ограничивающий фактор для пользователя нашего проекта, а не для нас. Но смена GPL на любую другую лицензию запрещена, даже внутри версий GPL. Например если поменять LGPL (надстройка над GPL) на GPL, то обратной дороги к LGPL уже не будет. И этот пункт был решающим в голосовании против.

В целом наш выбор изначально склонялся к GPL3 именно по причине распространения модифицированного кода под той же лицензией. Мы думали, что тем самым сможем обезопасить свой продукт, но мы увидели меньше рисков в Apache 2.0. Cогласно Free Software Foundation, GPLv3 совместима с Apache License v2.0., то есть всегда есть возможность сменить лицензию с Apache License v2.0 на GPL v3.0.

Apache 2.0


Apache 2.0 — сбалансированная разрешительная лицензия с акцентом на авторские права. Вот какие ответы она дала на интересующие нас вопросы. Внесенные изменения в ПО должны быть зафиксированы и не имеют никакого отношения к правообладателю системы? Да, все изменения должны быть задокументированы и мы не несем ответственность не за исходный код, не за измененный. Файл с изменениями должен прикладываться к коду в который вы эти изменения внесли. Имя производного ПО не должно совпадать с именем ПО правообладателя? Да, производное ПО должно выходить под другим именем и под другим товарным знаком, но с указанием авторства правообладателя. Можно ли изменить лицензию для любых новых версий на другую, в том числе и на проприетарную? Да, можно выпускать под разными лицензиями, Apache 2.0 не ограничивает применения любых некоммерческих и коммерческих лицензий.

Также выпуская новые продукты на основе открытого под Apache 2.0 кода или продукты дополнительной функциональности не обязательно использовать ту же лицензию. Ниже можно посмотреть изображение с условиями и ограничениями лицензии Apache 2.0.

Лицензия выдвигает требование сохранения и упоминания авторских прав и лицензии под которой выпускается ПО. Обязательное наличие copyright notice с именем правообладателя и лицензией защищает права первоначального автора ПО, так как даже если оно будет переименовано, отдано или продано под другой лицензией, то знак автора все равно останется. Для этого также можно использовать файл NOTICE и приложить его либо в исходный код или в документацию к проекту.

Мастер Йода рекомендует:  Автоматические санкции Google нельзя отменить «вручную»

Мы выпускаем в открытый доступ на GitHub все наши продукты под лицензией Apache 2.0, кроме IONDV. War archive, исходный код которого в апреле этого года был опубликован под лицензией GPLv3 на GitHub Дальневосточным центром социальных технологий. На данный момент, помимо самого фреймворка и его модулей опубликованы приложения сделанные на фремворке. На хабре мы уже рассказывали про Систему управления проектами и про Реестр связи.

IONDV. Framework – опенсорс фреймворк на node.js по созданию высокоуровневых веб-приложений на основе метаданных, что не требует серьезных навыков программирования.

Основу функциональности приложения составляет реестр данных — модуль Регистри. Это ключевой модуль, предназначенный непосредственно для работы с данными на основе структур метаданных – в том числе по ведению проектов, программ, мероприятий и др. Также в проекте используется модуль портала для отображения произвольных шаблонов данных – на нем реализован фронт реестра архивных дел.

Для СУБД используется MongoDb — в ней хранятся и настройки приложения, метаданные и сами данные.

Как применить лицензию к своему проекту?

Дабавьте файл LICENSE с текстом лицензии в репозиторий своего проекта и voilà, проект под защитой Apache 2.0. Нужно указать правообладателя, это и есть copiright notice. Сделать это можно в исходном коде или в файле NOTICE (текстовый файл, перечисляющий все библиотеки, лицензированные под лицензией Apache вместе с именами их создателей). Cам файл положить в либо в исходные коды или документацию, распространяемую вместе с работой. У нас это выглядит вот так:

Copyright © 2020 LLC «ION DV».
Licensed under the Apache License, Version 2.0

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

«License» shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.

«Licensor» shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.

«Legal Entity» shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
«control» means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.

«You» (or «Your») shall mean an individual or Legal Entity
exercising permissions granted by this License.

«Source» form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.

«Object» form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.

«Work» shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).

«Derivative Works» shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.

«Contribution» shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, «submitted»
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as «Not a Contribution.»

«Contributor» shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.

Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.

Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:

(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and

© You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and

(d) If the Work includes a «NOTICE» text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.

You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.

Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.

Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.

Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an «AS IS» BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.

Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.

Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets «[]»
replaced with your own identifying information. (Don’t include
the brackets!) The text should be enclosed in the appropriate
syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same «printed page» as the copyright notice for easier
identification within third-party archives.

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the «License»);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an «AS IS» BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

Лицензия = договор


Свободная лицензия, она хоть и свободная, но не допускает вседозволенности и мы уже привели примеры ограничений. Выбирайте лицензию учитывая как свои интересы, так и пользователя, потому что открытое ПО рассчитано именно на него. Пользователю проекта следует воспринимать лицензию как своеобразный договор между ним и правообладателем, поэтому прежде чем проводить какие-либо действие над исходным кодом, внимательно изучите ограничения, накладываемые на вас лицензией проекта.

Надеемся, что мы пролили немного света на тему лицензий и несмотря на сложность вопроса, он не должен стать препятствием на вашем пути в Open Source. Развивайте свой проект и не забывайте о правах, своих и чужих.

Полезные ссылки

Напоследок немного полезных ресурсов которые нам помогли при поиске информации о существующих лицензиях и подборе наиболее подходящей под наши цели:

Код доступа: зачем Microsoft купил GitHub за $7,5 млрд

Компания Microsoft начала процедуру покупки за $7,5 млрд платформы для разработчиков GitHub. Возможно, для стороннего наблюдателя это странное приобретение. Но с точки зрения бизнеса кажется, что по-другому и быть не могло.

Ситуация на IT-рынке

Аналитики Gartner оценили глобальный IT-рынок в 2020 году в $3,8 трлн. Лидеры сегмента среди публичных корпораций входят в топ-20 самых крупных компаний планеты с оценкой в сотни миллиардов долларов. Но структура доходов интернет-гигантов выглядит абсолютно по-разному:

Что мы видим? Большинство IT-компаний строят свою финансовую экосистему вокруг своих топ-продуктов:

— Facebook и Alphabet (Google) получают 97% и 88% своей прибыли от рекламы;

— Apple зарабатывает 63% всего оборота от продажи айфонов;

— Amazon выручает 72% от онлайн-торговли товарами.

Только Microsoft видит свою стратегию в сбалансированной диверсификации бизнесов:

— Microsoft Office — 28% доходов;

— Azure и Windows Server — 22%;

— другие проекты — 18%.

Концепция проста: в долгосрочной перспективе ставка на один продукт может быть опасна для всей стратегии развития корпорации. Это их видение бизнеса.

Рыночное положение GitHub

У бесплатных онлайн-проектов с многомиллионной аудиторией, как правило, одна главная проблема — монетизация. Да, GitHub — это самое большое хранилище программного кода и самое большое комьюнити программистов на планете. Но этому суперстартапу пришлось привлечь инвестиции в $100 млн в 2012 году и еще $250 млн в 2015 году.

Чаще всего сверхпопулярный проект с армией пользователей просто продается IT-гиганту за огромную сумму. Так было уже неоднократно:

WhatsApp — Facebook, 2014 год / $19,3 млрд.

Instagram — Facebook, 2012 год / $1 млрд.

Skype — Microsoft, 2011 год / $8,5 млрд.

YouTube — Google, 2006 год / $1,65 млрд.

Так произошло и с GitHub. Да, это нишевый проект. Но в этой нише аудитория в 20 млн человек. И эта аудитория была нужна Microsoft в их стратегии «равной прибыли» между проектами в своем портфеле.

Сделка

Основная аудитория GitHub — это разработчики решений в открытых исходных кодах (Open Source). Их первая реакция на новость о продаже проекта — скепсис. Более того, за сутки с момента сделки пользователи уже перенесли около 40 000 проектов к прямому конкуренту — на платформу Gitlab.

Отчасти причина такого негатива в «айтишной» традиции отвергать большинство новинок индустрии: гаджеты, интерфейсы, тарифные планы. Отчасти — в глобальном имидже Microsoft как «корпорации зла» и «убийцы креативных разработок».

Как бы там ни было, GitHub получил $7,5 млрд и ресурсы одной из самых мощных компаний в мире. Плюсы продавца и его основателей понятны: трое основателей стали миллиардерами по подсчетам американского Forbes.

Зачем эта сделка Microsoft?

В первую очередь это «покупка» огромной аудитории разработчиков. Инвестиция в их внимание. Именно аудитория, а не код, идея, инфраструктура или команда разработчиков является ценнейшим активом в современной IT-индустрии.

Facebook купил WhatsApp и приобрел не просто еще один мессенджер. У Марка Цукерберга был свой. Facebook купил больше 1 млрд новых пользователей.

У Microsoft была собственная платформа для разработчиков — CodePlex. Но она так и не «взлетела», несмотря на огромные ресурсы корпорации, рычаги для привлечения разработчиков, поддержку различных систем контроля версий — Subversion, Mercurial, Git. В итоге CodePlex был закрыт. И теперь Microsoft покупает самого сильного конкурента собственного проекта — GitHub.

Какие еще цели есть у новых владельцев GitHub помимо «покупки» новой аудитории?

Сильнейший tech-PR. В долгой перспективе сотрудничество с GitHub и поддержка сообщества разработчиков может очень сильно помочь Microsoft в переходе с имиджа «корпорации зла» на образ «хороших парней» в профессиональной среде. Эту цель поддержал глава Microsoft, когда заявил, что корпорация продолжит поддерживать проекты с открытым исходным кодом. А ведь именно продукты Open Source, для которых GitHub является бесплатным, помогли этой платформе стать самой популярной в среде разработчиков.

Прибыль от платных сервисов. Microsoft будет продолжать стратегию основателей GitHub — зарабатывать на подписке и других опциях сервиса. Это отлично пересекается со стратегией Сатьи Наделлы по диверсификации сервисов корпорации. IT-гигант уже давно зарабатывает не только и не столько на Windows.

Очень любопытной и перспективной выглядит интеграция GitHub с инструментами разработки от Microsoft — Visual Studio, а также с облачной платформой Microsoft Azure. Разработчики смогут получить доступ к репозиториям кода прямо из среды разработки, быстрое разворачивание проектов, масштабирование под высокую нагрузку, построение отказоустойчивой архитектуры в облаке Azure.

Дополнительные бонусы. Microsoft, с одной стороны, усилит свои позиции в конкуренции с облаками Amazon и Google, а с другой — сильнее «привяжет» разработчиков к подписке на свои продукты. Например, сервис OneDrive из набора Office 365 позволяет хранить данные пользователей в облаке и стимулирует пользователей к постоянному продлению подписки на весь офисный пакет. Так и репозиторий кода GitHub в дуэте с облачным сервисом Azure может стать сильнейшим драйвером подписной модели для профессиональных разработчиков.

Выводы

Microsoft обладает гигантским опытом по покупке IT-проектов — и с аналогичной бизнес-моделью, и с абсолютно противоположной. По какому сценарию может развиваться покупка GitHub?


Худший вариант. Microsoft подтвердит опасения критиков, «испортит» самое популярное хранилище программного кода на планете и в целом не добавит платформе никаких экстрасильных сторон. На взгляд автора, так уже произошло с приобретением Skype.

Неплохой вариант. Microsoft попробует объединить GitHub со своими продуктами и сервисами в новую гибридную модель, глубокой интеграции не получится, и платформа продолжит «жить» как независимый проект. Как тот же LinkedIn или, не столь удачный пример, Yammer.

Оптимальный вариант. Microsoft сделает хорошую тесную интеграцию GitHub как со своей облачной платформой, так и с инструментами разработки Visual Studio. Если интеграция получится удачной, от этого выиграют все, потому что IT-гигант сможет сделать разработчикам выгодное предложение «3 в 1»: среда разработки + репозиторий кода + облачная платформа.

Разница между различными типами открытых лицензий

Несмотря на то, что GitHub — крупнейший в мире сервис для совместной работы над открытым кодом, значительная часть размещённых там проектов формально не имеют никакого отношения к Open Source. Причём вовсе не потому, что их авторы предпочитают проприетарные решения. На сервере опубликована масса ПО, не имеющего никакой лицензии.

По всей видимости, существует достаточно много разработчиков, считающих вопрос лицензирования если не совсем несущественным, то наверняка второстепенным. Например, в опубликованной на сайте Fossbytes.com статье, посвящённой этой проблеме, скрывающийся под псевдонимом gdad-s-river автор сообщает, что он выбирает лицензию случайным образом. Но вовсе не по причине правового нигилизма — он уверен, что его проект не особенно интересен другим людям и его код не будет использован для создания других инструментов.

Но его пример не может быть показательным. Если разработчик планирует создать продукт, который в перспективе может быть использован другими для построения собственных оригинальных версий, вопрос выбора лицензии для него чрезвычайно важен. Вариантов тут может быть много:

  • Apache License 2.0;
  • BSD 3 (New BSD);
  • BSD 2 (FreeBSD);
  • GNU General Public License (GPL) v3.0;
  • GNU Lesser General Public License (LGPL);
  • MIT License;
  • Mozilla Public License 2.0;
  • Common Development and Distribution License;
  • Eclipse Public License;
  • Creative Commons License.

Наверняка профессиональному юристу такой список покажется небольшим, и он без труда разберётся в особенностях той или иной лицензии. Однако техническому специалисту непросто понять смысл, скрывающийся за явно перегруженными с его точки зрения формулировками. Более того, даже не все разработчики понимают, зачем нужно лицензирование, и искренне считают, что свободное ПО предполагает отсутствие каких бы то ни было ограничений.

В действительности, у всех открытых лицензий есть только одна прагматичная цель. В них сформулированы правила, которыми должны руководствоваться другие разработчики, если они заходят как-то использовать чужой код. Это может быть как создание производного продукта, так и вклад в развитие оригинального.

Открытые лицензии можно разделить на несколько больших категорий. У каждой их них есть свои особенности с точки зрения практического применения. Вероятнее всего, начинающим свои проекты разработчикам целесообразней ориентироваться именно на типы лицензий, выбирая наиболее подходящий для себя.

GNU General Public License

Этот тип лицензий позволяет копировать исходный код без каких-либо ограничений. Копии можно размещать на рабочих станциях и серверах, причём делать это неограниченное число раз.

Также GNU GPL не накладывает никаких ограничений на распространение программ ни по количеству, но по форме. Код можно переносить на специальных накопителях, можно дать ссылку для загрузки, можно даже распечатать его на бумаге и раздавать всем желающим.

Этот тип лицензий позволяет любому физическому или юридическому лицу брать деньги за услугу по распространению ПО. Правда, потенциальный покупатель должен быть предупреждён, что продавец не имеет каких-либо эксклюзивных прав, поэтому то же самое решение можно получить совершенно бесплатно. Это качество также даёт возможность объяснить, за что именно берётся плата.

Наконец, GNU GPL позволяет вносить в код любые изменения, удалять или добавлять любые функции. Правда только при условии, что полученный таким образом продукт также должен распространятся на условиях той же лицензии.

Мастер Йода рекомендует:  12 простых советов тем, кто самостоятельно учит математику

Разработчикам следует знать, что использование GNU GPL предполагает соответствие неким стандартам оформления кода. Внутри него в комментариях должны быть изложены лицензионные требования.

GNU Lesser General Public License

Ранее название этого типа лицензий — GNU Library General Public License. LGPL чаще всего применяется для библиотек ПО, поскольку позволяет использовать их не только в свободных, но и проприетарных приложениях.

В проприетарном ПО распространяемый на условиях LGPL код применяется в форме разделяемой библиотеки. Эта мера обеспечивает разграничение между закрытыми и открытыми компонентами в программе, сама же лицензия не требует открытия кода всего решения.

LGPL, в отличие от GPL, носит компромиссный характер. Она не гарантирует пользователю полную свободу всех производных продуктов, но позволяет использовать открытый код в проприетарных решениях, причём открытые модули должны оставаться открытыми.

BSD License

Некоторые программисты считают BSD истинно свободной лицензией, и в некотором смысле они правы. Действительно, BSD накладывает очень мало ограничений на использование кода по сравнению с другими лицензиями.

Выбирающий BSD разработчик по сути разрешает использование своего кода как в открытых, так и в проприетарных приложениях. Это свойство широко применяется на практике, в том числе в больших проектах. В частности, некоторые компоненты FreeBSD вошли в состав операционной системы Mac OS X.

Основная особенность BSD 3, которая часто называется BSD New, в том, что она ограничивает использование имён разработчиков в производных продуктах. На практике означает, что она по умолчанию запрещает применять имя автора для продвижения других программ — для этого требуется его специальное разрешение.

MIT License

Это самая короткая лицензия. Возможно, именно по этой причине она становится всё более популярной. По сути она разрешает всё.

В соответствии с лицензией MIT копию ПО и всю сопутствующую документацию можно изменять, улучшать, дополнять, применять в других проектах, продавать и распространять бесплатно при соблюдении всего одного условия — текст лицензии должен быть включён во все копии. Требование, очевидно, совершенно необременительное и выполнить его не составляет никакого труда.

Creative Commons

Эта группа лицензий предназначена не для ПО, а для «сопутствующих продуктов»: фотографий, рисунков, текстов, дизайнерских проектов и т. д. Прежде всего потому, что Creative Commons не требует включения в произведение текста лицензии, достаточно только указать соответствующее буквенное обозначение.

Для лицензий группы Creative Commons нет каких-то строгих обязательных для всех правил. Некоторые из них вообще могут взаимно исключать друг друга, и в этом нет ничего страшного, если принять во внимание область их применения.

В частности, Creative Commons может разрешать неограниченное копирование и распространение, но запрещать при этом любые изменения. Программистам это может показаться странным, а вот художник вероятнее всего сочтёт такое условие вполне разумным.

Apache License

У Apache License есть одна интересная для многих разработчиков особенность — она не ставит обязательным условием неизменность лицензии. Таким образом, правила распространения модифицированной версии какой-либо программы могут отличаться от исходных.

Эта лицензия в основном защищает права авторства. Например, в любой распространяемый пакет должен входить текстовый файл, в котором перечисляются все библиотеки, лицензированные на условиях Apache, и имена их разработчиков.

Разумеется, право на изменение лицензии не означает возможности её отзыва. Никто не имеет права менять условия, которые уже были однажды определены.

Обзор лицензионных соглашений, заключаемых нестандартными способами: сlick-wrap, browse-wrap, open-source и свободные лицензии в свете поправок в ГК РФ

Инна Паламарчук, ведущий юрист, группа компаний CUSTIS

В свете поправок в часть четвертую Гражданского кодекса Российской Федерации 1 тема свободных, открытых, а также, на первый взгляд, непривычных browse — wrap лицензий обрела новое звучание. Чтобы разобраться, что изменилось в регулировании, сначала необходимо определить, что же представляют из себя различные лицензии: shrink — wrap , click-wrap, browse-wrap, свободные и open — source лицензии, а также новые виды лицензий в том понимании, в котором они будут закреплены в части четвертой Гражданского кодекса Российской Федерации.

Прежде всего необходимо ознакомиться с историей развития правовых концепций использования программ для ЭВМ (далее по тексту для удобства будут использоваться термины «программа» и «ПО»). Проблема необходимости правового регулирования использования программ требовала решения, особенно после того как программы стали доступны огромному числу людей, а производители начали терпеть убытки из-за копирования программ, приобретенных пользователями. Для производителей в США это стало настоящей проблемой также ввиду существования так называемой доктрины первой продажи (first-sale doctrine), сформулированной Верховным Судом США в решении по делу Bobbs-Merill Co. v . Strauss 2 . Затем эта доктрина была закреплена в положениях закона об авторском праве 1909 г., а в законе об авторском праве 1976 г. (Copyright Act of 1976) (17 U.S.C. § 109 (а)) 3 она уже была оформлена в более совершенном виде, закрепляя положение о том, что законный владелец конкретной копии (то есть экземпляра результата интеллектуальной деятельности, охраняемого авторскими правами) или иное лицо, наделенное полномочиями, вправе продавать или распоряжаться данным экземпляром иным образом.


C появлением программ, широко распространяемых на CD (дистрибутивах), правообладатели стали опасаться, что такие дистрибутивы будут перепродаваться покупателями (на основании доктрины первой продажи). В связи с этим появилась идея размещать текст лицензионного соглашения (регламентирующего виды использования программы) на упаковках программных продуктов с условием, что потребитель, разрывая оберточную бумагу (обертку), выражает свое согласие с условиями этого соглашения и тем самым заключает договор с правообладателем ПО. Такой договор определяет правомочия сторон, а также ограничивает право покупателя на распоряжение программой (в части перепродажи). Эти соглашения получили название shrink-wrap agreements (дословно — соглашения на упаковке). По сути, американские производители ПО, ссылаясь на § 109 (d), предусматривающий невозможность применения доктрины первой продажи, если владение экземпляром осуществляется при отсутствии права собственности, указывали на оберточной бумаге виды разрешенного использования, подчеркивая, что программное обеспечение «лицензируется, а не продается» (licensed, not sold). Этот тезис о лицензировании был подтвержден в деле Timothy S. Vernor v. Autodesk, Inc 4 . Истец (Тимоти Вернор) выставил на продажу на eB ay купленные им диски с программой AutoCAD, за что стал получать предупреждения от правообладателя. После принудительного закрытия аккаунта на eB ay он обратился в суд, считая, что никакого правонарушения не совершал, ведь обертку не снимал, диск не устанавливал и ознакомиться с условиями лицензии не мог. Апелляционный суд девятого округа США указал, что приобретатель CD с программой приобретает право собственности на носитель, а не на программу как таковую, потому для определения прав покупателя нужно обращаться к тексту лицензии, в которой указано на исключительное право распространения программы, принадлежащее лишь организации-правообладателю или же организации, наделенной полномочиями по продаже 5 .

Следующим этапом развития лицензирования ПО стали так называемые click — wrap agreements , то есть договоры, акцепт которых производится кликом. Если пользователь желает воспользоваться функционалом, предоставляемым онлайн, ему необходимо передвинуть курсор на окошко « I Accept » («Я соглашаюсь») и щелкнуть OK 6 . В США правомочность таких соглашений также была подтверждена в решении по делу Hughes v . McMenanon : «…Если суды признают действительными условия shrink — wrap лицензий, то условия click — wrap соглашений должны быть признаны таковыми тем более, поскольку согласие пользователя с ними является более выраженным» 7 .

В современном мире технологий все автоматизируется, совершенствуется и упрощается. Эта тенденция отразилась и на способах заключения лицензионных соглашений: появились browse — wrap лицензии, которые представляют собой помещенные на сайте кликабельные условия использования сайта, однако пользователь не выражает согласия с ними в явном виде (нет отдельного окна, в котором пользователь ставил бы «галку» о согласии с условиями использования). Сами же правила предусматривают, что просмотр или иное использование сайта предполагает выражение согласия с данными условиями.

А. И. Савельев указывает, что, как правило, все условия, предусмотренные правилами пользования сайтом, можно разделить на информационные и регулятивные. К примеру, условия использования сайта Amazon.com содержат также порядок подачи заявлений о нарушении авторских прав, порядок рецензирования товаров, запреты на коммерческое использование размещенной на сайте информации и использование роботов для сбора информации на сайте 8 .

Необходимо остановиться на рассмотрении вопроса, когда в случае использования click-wrap и browse-wrap лицензий договор считается заключенным. Требования к форме договора содержатся в ст. 434 ГК РФ, а подходящее обоснование способа заключения договора — в п. 3 ст. 438 ГК РФ: акцепт оферты конклюдентными действиями. С октября 2014 г. вступит в силу новая редакция п. 5 ст. 1286 ГК РФ, вводящая упрощенный порядок заключения лицензионного договора на использование программ для ЭВМ и баз данных. Лицензионный договор, заключаемый в упрощенном порядке, является договором присоединения, условия которого могут быть изложены на приобретаемом экземпляре программы для ЭВМ или базы данных либо на упаковке такого экземпляра, а также в электронном виде.

Существует еще один пласт лицензий, характеризующихся определенной спецификой, — это свободные лицензии. Большая часть программ с открытым исходным кодом (open-source) являются одновременно свободными. Чтобы понять, что представляют из себя свободные и открытые лицензии, необходимо обратиться к истории их развития. В середине 1980-х гг. развивались два параллельных идеологических движения: за свободное программное обеспечение (Free Software Foundation, FSF, во главе с Ричардом Столлманом) и за создание и распространение ПО с открытым исходным кодом ( OSI , идеологами которого были Брюс Перенс и Эрик Рэймонд).

Ричард Столлман, стоявший у истоков движения за свободное программное обеспечение, видел одной из задач разработчиков ПО сопротивление монополизму проприетарного (proprietary) ПО. В 1985 г. Столлман основал FSF, опубликовал «Манифест GNU» 10 (в нем изложена идея General Public L icense, GPL), а также разработал операционную систему GNU GPL. Основным посылом его философии было распространение ПО на условиях полной свободы (которая становится не привилегией, а, скорее, обязательством!). Лицензия GPL, которую принято называть «копилефтной лицензией» (что означает, что любая копия программы, созданная на основании программы, лицензируемой по условиям GPL, должна быть свободной), рассматривается в статье ниже.

Примерно в те же годы зародилось движение за интеграцию ПО с открытым исходным кодом в бизнес. В 1997 г. был опубликован доклад «Собор и Базар» 11 (The Cathedral and the Bazaar, сокращенно CatB) о методах разработки ПО, в котором анализировались «соборная» и «базарная» модели. «Соборная» модель подразумевает, что исходный код становится доступным после релиза программы, а в процессе разработки доступ к коду разрешен лишь разработчикам проекта. «Базарная» модель подразумевает разработку кода через Интернет «на виду» и при возможном участии общественности, что является более прогрессивным с точки зрения автора эссе, поскольку «при наличии достаточного количества глаз все ошибки всплывают» («given enough eyeballs, all bugs are shallow»). В 1998 г. Эрик Рэймонд и Брюс Перенс основали OSI ( Open Source Initiative ) 12 .

В настоящее время при упоминании свободных лицензий или свободного ПО имеют в виду ПО с открытым кодом, и наоборот. Однако разница все же существует, пусть и на уровне философии обоих движений. Свободное ПО — это обязательно открытый код, а вдобавок еще и четыре свободы 13 :

изучать и модифицировать;

распространять копии первоначальной программы;

распространять модифицированные версии.

У OSI есть свои критерии определения ПО с открытым исходным кодом, состоящие из десяти пунктов ( OS definition ) и изложенные на сайте организации:

программа должна свободно распространяться (лицензия не должна подразумевать какого-либо вознаграждения);

программа должна включать исходные тексты;

программа должна допускать модификации;

лицензия может требовать сохранения авторского ПО в неизменном виде (то есть может быть запрещена модификация, но разрешено распространение самой открытой программы-заплатки);

никакой дискриминации против лиц или групп;

никакой дискриминации в отношении областей деятельности (лицензия не должна запрещать использование программы в конкретной области деятельности);

права, связанные с программой, должны применяться ко всем, кому она будет распространена;

распространение программы в составе какого-либо программного продукта не должно зависеть от распространения самого программного продукта;

лицензия не должна ограничивать другое ПО;

лицензия должна быть технологически нейтральной.

OSI осуществляет сертификацию лицензий на предмет их соответствия указанным условиям. Только лицензии, удовлетворяющие перечисленным требованиям и сертифицированные OSI , могут именоваться open — source license . Перечень таких OSI — approved licenses указывается на сайте OSI .

Для любого пользователя ПО крайне необходимо точно понимать, на каких условиях его можно использовать. Поскольку ПО с открытым исходным кодом разрабатывается посредством распределенных совместных усилий многих участников, а впоследствии может быть использовано в коммерческих целях, то код выкладывается в общедоступные источники с указанием лицензий, которыми он регулируется. Большинство проектов по разработке ПО с открытым исходным кодом имеют «доверенные репозитории» (trusted repository), а именно — определенный веб-источник, где можно получить «официальную версию» программы. Изменять программу могут лишь создатели (creators). При этом пользователи могут направлять сообщения об ошибках в том числе напрямую в репозиторий. Однако основным отличием является то, что пользователь и сам может внести любые изменения. Опять же, получается некоторый цикл: чем более удобной (capable) становится программа, тем больше пользователей ее используют, и в итоге пользователь (или совокупность пользователей) становится разработчиком (user as developer).

Встает резонный вопрос: зачем вообще лицензия на свободное использование или зачем лицензия, которая очевидно разрешит делать с ПО все что угодно? Поскольку родина ПО — Америка, то в соответствии с требованиями о копирайте пользователи должны получить разрешение от правообладателя до того, как они запустят программу. Таким образом, любое ПО, предоставляемое в пользование неопределенному круг лиц, должно сопровождаться лицензией (то есть явно выраженными условиями последующего использования).

Наиболее известным хостингом свободных проектов является GitHub, команда которого в 2013 г. запустила новый сайт C hoose AL icense.com для упрощения принятия решения о выборе той или иной лицензии при создании репозитория с кодом. На сайте в краткой форме описаны особенности основных открытых лицензий. На главной странице регистрации нового репозитория в GitHub появилась форма выбора лицензии, позволяющая автоматически сформировать файл с выбранным типом лицензии, чтобы не приходилось копировать условия лицензии вручную. Такая автоматизация понадобилась еще и потому, что зачастую код размещался без явного указания лицензии, что формально не давало возможности без согласия автора использовать код в проектах 15 .

Несмотря на различия в философии FSF и OSI , в обеих идеологиях подход к open — source одинаков, потому границы между свободными лицензиями и ПО с открытым исходным кодом стираются. Широко используется FOSS и FLOS S (разница лишь в наличии буквы L ), что означает Free/Libre and Open-Source Software — свободное программное обеспечение с открытыми исходными кодами. Указанная категория включает в себя как свободное, так и открытое программное обеспечение. В английском языке слово Free означает как «свободный», так и «бесплатный», поэтому в термин FOSS (Free and Open-Source Software) было включено слово Libre (фр. «свободный»), чтобы подчеркнуть, что речь идет именно о свободном ПО.

Определив, что различия в идеологии не влияют на общий смысл, порядок лицензирования и использования ПО, далее будем употреблять термин «свободные лицензии».

Лицензии подразделяются на две основные группы: разрешительные лицензии ( permissive licenses ), содержащие минимум условий ( BSD , MIT , Apache ), и взаимные лицензии ( reciprocal licenses , copyleft ), налагающие обязанность распространять модификации программы на тех же условиях, на которых распространялась исходная программа ( GPL , LGPL , MPL ). К признакам всех свободных лицензий можно отнести следующие:

лицензии стандартизированы ( GNU , CC , Apache , Mozilla );

наименование договора или соглашения, к условиям которого присоединяется пользователь, содержит указание на сам предмет ( GNU GPL , LGPL );

в условия использования нельзя внести изменения, можно принять их как есть ( as is );

лицензия является безотзывной.

Для более наглядного представления о наиболее известных лицензиях, под которыми распространяется код, необходимо ознакомиться с их условиями.

Самая простая и исторически первая из ныне используемых свободных лицензий — лицензия операционной системы BSD ( Berkley Software Distribution License ) — появилась в начале 1980-х гг. Существовало три версии лицензии. Исходная лицензия («старая BSD», или «4-пунктовая BSD») называется так потому, что она содержала помимо условий о сохранении уведомления об авторском праве и требования о выдаче бумажной лицензии еще и указание на необходимость упоминания об университете в случае публикации характеристик программы в рекламных материалах ( advertising clause ). «Новая BSD» («модифицированная BSD», или «3-пунктовая BSD») уже не содержит обременительного условия о рекламе. Лицензия предоставляет полную свободу распространения кода, на любых условиях, с исходными текстами или без них, и заботится только об охране честного имени организации-автора. Лицензии BSD -типа относятся к разрешительным лицензиям, поскольку не требуют использования той же лицензии для производных произведений ( downstream versions ). Лицензия содержит стандартный набор условий, предусматривающих предоставление программы «как есть» в отсутствие каких-либо гарантий, с исключением ответственности за любые убытки, которые могут быть причинены программой.

Лицензия MIT ( Massachusetts Institute of Technology ) по содержанию похожа на лицензию BSD , однако содержит формулировки, допускающие сублицензирование (то есть права каждому последующему пользователю предоставляются предыдущим, а не первоначальным) 16 .

Лицензия Apache 2.0 17 ( Apache Software Foundation ) разрешает распространять производные продукты под условиями иных лицензий, а также позволяет разработчикам самим решать, сохранять ли для итогового продукта статус бесплатного и открытого. Единственным условием, накладываемым лицензией Apache, является информирование получателя о факте использования исходного кода. Таким образом, в противоположность copyleft-лицензиям, получатель модифицированной версии не обязательно получает все права, изначально предоставляемые лицензией Apache.

При распространении программного обеспечения необходимо поместить следующие файлы в корневую директорию: license — файл, содержащий копию текста лицензии Apache; notice — текстовый файл, перечисляющий все библиотеки, лицензированные под Apache, с именами их создателей.

В процессе развития все эти лицензии претерпевали определенные изменения, которые в итоге сделали их универсально применимыми (удалялись лишние условия, добавлялись необходимые). Похожий путь прошла и лицензия Mozilla ( Mozilla Public License , MPL), однако, учитывая, что она изначально была составлена юристами, в ней все было сформулировано более логично. В случае если распространяется файл, содержащий первоначальный код или ранее сделанные модификации к нему, итоговые файлы лицензируются на условиях MPL . Целостный продукт при этом может распространяться под любой лицензией. В лицензии указаны два типа авторов: первоначальный автор и внесший вклад в доработку этого кода ( contributor ). Таким образом, лицензия не ограничивает использование ПО в различных продуктах и гарантирует дальнейшее развитие проекта.


История проекта GNU началась в 1984 г., когда Ричард Столлман решил создать ПО, которое бы свободно распространялось и дорабатывалось. В итоге все условия использования, которые Столлман считал необходимыми, нашли выражение в лицензии GPL ( General Public License ) 18 . Пользователь вправе копировать, модифицировать и распространять исходный код, распространять скомпилированные версии, содержащие в себе как доработанный, так и исходный код. При этом все распространяемые копии должны содержать уведомление об авторском праве и об отсутствии гарантий на ПО, все доработанные версии подчиняются условиям GPL , все компилятивные версии ( compiled versions ) должны сопровождаться исходным кодом или содержать указание на реальную доступность кода ( viable offer ). К примеру, указание на то, что код раскрывается любому лицу по первому его требованию. По условиям лицензии каждому новому лицензиату права предоставляются непосредственно от первого лицензиара, то есть все пользователи вступают в отношения непосредственно с Free Software Foundation ( FSF ).

GPL породила определенные мифы о жесткости применения. Считается, что если кто-то модифицировал ПО под GPL , то он обязан сделать ПО доступным. На самом деле если нет цели распространять ПО, то нет необходимости и обнародовать деривативное ПО.

В свое время поднимался вопрос о правомерности условия о необходимости подчинения программы, созданной на базе GPL , условиям этой же лицензии. Американские суды сошлись на том, что GPL не нарушает конкурентного права (anti-trust laws). В решении по делу Wallace v. FSF судья Даниэль Тиндер указал, что «GPL способствует, а не препятствует свободной конкуренции и распространению компьютерных программ» 19 . Истец обращался в суд целью установления судебного запрета на использование GPL в связи с тем, что условия лицензии накладывают ограничения на коммерческий оборот, якобы устанавливая фиксированные цены на программное обеспечение. Тем самым, по мнению истца, происходило нарушение антимонопольного законодательства (Sherman Act). В итоге же суд не нашел никаких нарушений и по сути лишь укрепил своим решением легитимность условий лицензии.

За рубежом свободные лицензии существуют давно, и, несмотря на это, все равно возникают судебные споры. В России же дискуссии на тему использования свободных лицензий, то набирая обороты, то затухая, велись несколько лет.

В 2011 г. в рамках круглого стола «“Свободные лицензии” или самоограничение права?» в Российской школе частного права (РШЧП) состоялось обсуждение судьбы свободных лицензий в России 20 . Круглый стол освещал предложенные на тот момент поправки в четвертую часть ГК РФ (озвученные на круглом столе членом рабочей группы В. Калятиным) и контраргументы юриста IBM А. Савельева, который стоял на позиции отсутствия необходимости особого регулирования свободных лицензий. По мнению А. Савельева (более подробно его взгляды изложены в монографии «Лицензирование программного обеспечения в России: законодательство и практика»), модель свободных лицензий вполне применима в рамках российского законодательства.

В конечном итоге поправки в четвертую часть ГК РФ были приняты Федеральным законом № 35 от 12 марта 2014 г. «О внесении изменений в части первую, вторую и четвертую Гражданского кодекса Российской Федерации и отдельные законодательные акты Российской Федерации». В контексте данной статьи ключевыми являются следующие изменения: пересмотр и дополнение положений об оберточных лицензиях (п. 5 ст. 1286 ГК РФ); введение положений об открытых лицензиях (ст. 1286.1 ГК РФ); введение нового способа распоряжения исключительным правом на произведение науки, литературы или искусства либо объект смежных прав — публичного заявления о предоставлении любым лицам возможности безвозмездно использовать результат интеллектуальных прав на определенных правообладателем условиях и в течение указанного им срока (п. 5 ст. 1233 ГК РФ).

Мастер Йода рекомендует:  Как найти человека по IP адресу

Необходимо проанализировать нововведения ГК РФ с целью их сопоставления с зарубежными институтами свободных лицензий. На настоящий момент п. 5 ст. 1286 ГК РФ говорит о том, что заключение лицензионных договоров о предоставлении права использования программы для ЭВМ или базы данных допускается путем заключения каждым пользователем с соответствующим правообладателем договора присоединения, условия которого изложены на приобретаемом экземпляре такой программы или базы данных либо на упаковке этого экземпляра. Начало использования таких программ или баз данных пользователем, как оно определяется этими условиями, означает его согласие на заключение договора. С 1 октября 2014 г. п. 5 ст. 1286 ГК РФ излагается в новой редакции. Редакция статьи предусматривает алгоритм заключения лицензионного договора в упрощенном порядке, расширяя перечень вариантов изложения условий и указывая на возможность существования условий в электронном виде.

Также с 1 октября 2014 г. вступает в силу ст. 1286.1, в п. 1 которой определено понятие открытой лицензии, которая презюмируется безвозмездной, если ею не предусмотрено иное. В случае если срок действия открытой лицензии не определен, в отношении программ для ЭВМ и баз данных договор считается заключенным на весь срок действия исключительного права, а в отношении других видов произведений — на пять лет. Кроме того, поправки в ГК РФ определяют ответственность за нарушение условий открытых лицензий, в том числе дают возможность автору требовать применения к нарушителю мер защиты исключительного права в соответствии со ст. 1252 ГК РФ.

С 1 января 2015 г. вступает в силу п. 5 ст. 1233 ГК РФ, предусматривающий публичное заявление о возможности безвозмездного использования произведения. По сути, вводится новый способ распоряжения исключительным правом. Правообладатель может публично сделать заявление о предоставлении любым лицам возможности безвозмездно использовать принадлежащее ему произведение науки, литературы или искусства либо объект смежных прав на определенных им условиях и в течение указанного им срока. Причем законодатель регламентирует и процедуру совершения заявления: путем размещения на официальном сайте федерального органа исполнительной власти. Пока не ясно, какой именно орган предоставит площадку и будет каким-то образом вести реестр. В любом случае для программ ЭВМ будет использоваться именно механизм ст. 1286.1 ГК РФ. Содержание понятия открытой лицензии по ГК РФ не идентично понятию open-source лицензии. Ст. 1286.1 ГК РФ распространяет свое действие на произведения науки, литературы или искусства, программы для ЭВМ и базы данных, в то время как open-source лицензии регулируют лишь сферу использования программ для ЭВМ. ГК называет в качестве сторон лицензиара и лицензиата, а в open-source лицензиях могут существовать первоначальный автор, автор производного продукта и пользователь. Важным вспомогательным механизмом, введенным поправками к ГК РФ, является п. 3 ст. 1266 ГК РФ, закрепляющий применительно к п. 2 ст. 1286.1 ГК РФ и п. 5 ст. 1233 ГК РФ возможность дать согласие на внесение в будущем изменений, сокращений и дополнений в свое произведение, на снабжение его иллюстрациями и пояснениями, если это вызвано необходимостью (исправление ошибок, уточнение или дополнение фактических сведений и т. п.), при условии, что этим не искажается замысел автора и не нарушается целостность восприятия произведения.

В заключение хотелось бы отметить, что нововведения в гражданском законодательстве оцениваются неоднозначно. Если новую редакцию ст. 1286 ГК РФ и введение ст. 1286.1 ГК РФ можно смело оценивать положительно, то для оценки п. 5 ст. 1233 ГК РФ потребуется время. Практика покажет, будет ли востребован предложенный способ распоряжения правом посредством публикации заявления или же эта конструкция останется лишь на бумаге.

1 Федеральный закон № 35-ФЗ от 12.03.2014 «О внесении изменений в части первую, вторую и четвертую Гражданского кодекса Российской Федерации и отдельные законодательные акты Российской Федерации» // СПС «Консультант Плюс».

10 альтернатив GitHub, который купила Microsoft

Если вы разработчик и ищете, куда теперь перенести свои проекты, присмотритесь к этим вариантам.

4 июня состоялась сделка Microsoft по покупке GitHub за 7,5 миллиарда долларов, о чём рассказали в блоге GitHub. GitHub — крупнейший в мире веб-сервис для хостинга и совместной разработки IT-проектов. Его покупка корпорацией Microsoft шокировала многих пользователей, особенно приверженцев и разработчиков Open Source.

У Microsoft есть одна неприятная особенность. Собственные разработки компании хороши, но когда Microsoft покупает какой-нибудь популярный проект вроде Skype, LinkedIn, Nokia или Wunderlist, то в лучшем случае его ожидает стагнация, в худшем — деградация. Пользователи GitHub перевели больше 40 тысяч проектов на другие веб-сервисы. Хештег #movingtogitlab на Twitter использовали почти 3 тысячи раз.

Если вы тоже задумались о «переезде», вот несколько альтернатив.

1. GitLab

GitLab — альтернатива GitHub номер один. GitLab предоставляет не только веб-сервис для совместной работы, но и программное обеспечение с открытым исходным кодом.

Многие проекты с открытым исходным кодом, такие как GNOME и GIMP, используют GitLab.

Расценки у сервиса GitLab не низкие. Впрочем, вы можете развернуть GitLab на любом другом хостинге или запросто установить GitLab на свой сервер.

Стоимость

  • Core — бесплатная версия GitLab. Для развёртывания на вашем собственном хостинге или сервере.
  • Starter — 4 доллара в месяц с каждого пользователя. Для небольших команд.
  • Premium — 19 долларов в месяц с каждого пользователя. Для организаций.
  • Ultimate — 99 долларов в месяц с каждого пользователя. Для крупных компаний.

2. BitBucket

BitBucket — это служба хостинга репозиториев и управления версиями от Atlassian. Она тесно интегрирована с другими инструментами Atlassian — Jira, HipChat и Confluence.

Это прекрасный выбор для крупных предприятий. Но и небольшие команды могут использовать BitBucket. Сервис бесплатен для проектов, в команде которых не больше пяти участников. Всё, что вам нужно сделать, — это подать заявку на получение лицензии сообщества в Atlassian.

Вы можете разместить BitBucket на собственном сервере или хостинге, но за это придётся заплатить.

Стоимость

  • Free — бесплатно для команд, в которых не больше пяти разработчиков.
  • Standart — 2 доллара в месяц с пользователя. Для небольших и средних команд. Неограниченное число пользователей.
  • Premium — 5 долларов в месяц. Для больших команд, которым нужны расширенные возможности.

3. SourceForge

SourceForge — ещё одна крупная альтернатива GitHub, сконцентрировавшаяся на Open Source. Многие дистрибутивы и приложения Linux обитают на SourceForge.

В своё время популярность сервиса упала под натиском более простого и интуитивно понятного GitHub. Однако SourceForge переработал свой интерфейс, став гораздо привлекательнее и, главное, удобнее.

Стоимость


SourceForge бесплатен. Но исходные коды, которые публикуются на нём, должны быть открытыми. Другие пользователи смогут создавать форки на основе ваших проектов.

4. Launchpad

Launchpad — платформа для совместной работы над программным обеспечением от Canonical, компании-разработчика Ubuntu. На ней размещены PPA-репозитории Ubuntu, откуда пользователи загружают приложения и обновления.

Сервис Launchpad существует уже много лет, но он не снискал такой популярности, как GitHub и другие его альтернативы. Однако это хороший выбор для разработчиков Open Source: неважно, создаёте ли вы софт для Ubuntu-подобных систем или других дистрибутивов Linux.

Стоимость

Вы можете размещать или импортировать репозитории Git на Launchpad совершенно бесплатно.

5. Apache Allura

Allura — это бесплатное решение от Apache. Сервис поддерживает отслеживание проблем в коде и комментарии кодов с разметкой. Apache Allura работает с Git, Hg и Subversion (SVN).

С Allura вы легко сможете создавать внутренние вики-страницы для документации.

Стоимость

Бесплатно. Но вам придётся разместить Allura на своём хостинге или сервере.

6. Cloud Source

Cloud Source — средство управления версиями Git от Google. Вы можете создавать любое количество частных репозиториев Git, позволяющих организовать код. Сервис интегрирован с инструментами облачной диагностики Google, такими как отладчик Stackdriver Debugger и Stackdriver Error Reporting. Так что вы без труда сможете отслеживать ошибки в коде.

Cloud Source позволяет подключать репозитории GitHub или Bitbucket. Вы можете использовать код из своих репозиториев в проектах Cloud Platform.

Стоимость

  • Up to 5 Users — 1 доллар в месяц с пользователя. До пяти пользователей в команде.
  • 50 GB Storage — 0,10 доллара в месяц за каждый использованный ГБ. Неограниченное количество пользователей.

7. AWS CodeCommit

Платформа для контроля версий от Amazon, масштабируемая и безопасная. На CodeCommit размещены защищённые и приватные хранилища Git. Платформа поддерживает подключение множества плагинов от партнёров AWS.

CodeCommit тесно интегрирован с другими сервисами Amazon, так что, если вы используете инфраструктуру этого облачного гиганта, CodeCommit — ваш выбор.

Стоимость

  • Бесплатно с ограничениями: до пяти активных пользователей, до 50 ГБ хранилища и до 10 000 запросов Git в месяц.
  • Платно — 1 доллар в месяц с каждого пользователя сверх пяти. 10 ГБ хранилища и 2 000 запросов Git в месяц для каждого активного пользователя.

8. FogCreek/DevHub

Платформа для управления кодом, которая основана на языке управления версиями Mercurial, но также поддерживает Git. FogCreek является частью более крупной платформы FogBugz DevHub, включающей в себя распределённый контроль версий и средства отслеживания ошибок и управления проектами.

Стоимость

Зависит от количества разработчиков в команде, начинается с 75 долларов в месяц за пять участников.

9. Beanstalk

Beanstalk — облачная платформа для управления кодом, которая позволяет вам писать и просматривать код прямо в браузере, так что вы сможете работать в любой точке мира. Beanstalk интегрируется с мессенджерами и электронной почтой, чтобы помочь вашей команде оставаться в курсе всех обновлений кода.

Beanstalk отличается высоким уровнем безопасности: с полным шифрованием, двухфакторной аутентификацией и надёжным обеспечением сохранности паролей. Вы можете опробовать Beanstalk в бесплатной пробной версии, но за постоянное использование придётся заплатить.

Стоимость

  • Bronze — 15 долларов в месяц, 3 ГБ хранилища, 10 репозиториев, до пяти пользователей.
  • Silver — 25 долларов в месяц, 6 ГБ хранилища, 25 репозиториев, до 20 пользователей.
  • Gold — 12 ГБ хранилища, 50 репозиториев, до 40 пользователей, а также расширенные возможности.
  • Platinum — 24 ГБ хранилища, 120 репозиториев, до 100 пользователей, расширенные возможности.

  • Diamond — 60 ГБ хранилища, 300 репозиториев, до 200 пользователей, расширенные возможности.

10. GitKraken

GitKraken обладает прекрасным интерфейсом. Он ориентирован на скорость и простоту использования Git. Цель платформы — экономить время на сборку и тестирование кода.

С GitKraken работают такие гиганты, как Blizzard, IBM, Google и Microsoft. GitKraken можно установить на компьютерах с Windows, Mac и Linux.

Может ли мой публичный проект github быть открытым?

У меня есть новый проект в github. Это публично. Однако я не помню, чтобы меня спрашивали, какую лицензию дать.

В коде google/sourceforge перед запуском нового репозитория я вспоминаю, что мне было предложено передать лицензию с открытым исходным кодом.

Конечно, существует разница между открытым и открытым исходным кодом. Могу ли я сказать, например, что вы можете свободно скачивать, читать и изучать код, но вам нужно заплатить $$$ за его запуск? Или вы не можете разветкить его? Или что-то вроде не-open-source-compatible-where-here?

У меня есть новый проект в github. Это публично. Однако я не помню, чтобы меня спрашивали, какую лицензию дать.

Код, размещенный в GitHub без какой-либо явной лицензии, в основном относится к статье «Все права защищены» (cf. Сообщение InfoWorld по этому вопросу). Ниже соответствующей выдержки из статьи:

«Каковы условия, по которым предоставляется код во всех этих проектах GitHub? Точный ответ зависит от вашей юрисдикции и требует совета адвоката, но, скорее всего, ответ для большинства людей» все права защищены «, — другими словами, у вас нет прав на использование этого кода. GitHub не содержит полезных условий лицензирования по умолчанию в своих условиях обслуживания, наиболее вероятным сценарием является то, что любое использование материалов, защищенных авторским правом, в одном из этих проектов без лицензии формально является нарушением авторских прав. Согласно закону об авторском праве код без лицензии не может быть разделен по закону, поскольку по умолчанию для материалов, защищенных авторским правом, является то, что все права зарезервированы.

Однако, чтобы четко изложить ваше намерение, возможно, было бы лучше четко добавить лицензию в вашем репо (в виде отдельного текстового файла (например, COPYING.txt ) и как часть файла README.txt .

Конечно, существует разница между открытым и открытым исходным кодом. Могу ли я сказать, например, что вы можете свободно скачивать, читать и изучать код, но вам нужно заплатить $$$ за его запуск?

Вы можете получить вдохновение из проекта RavenDb проекта двойного лицензирования, который ограничивает использование следующим образом:

  • Коммерческие издания могут использоваться в среде с закрытым исходным кодом и доступны по типу подписки или бессрочной ценовой политики. Цены указаны за один экземпляр. Пока подписка действительна, новые выпуски автоматически включаются.
  • Вы можете использовать Raven бесплатно, если ваш проект является Open Source.

Если вы согласны с запросами Pull, может быть хорошей идеей убедиться, что вкладчики соблюдают режим лицензирования и делают их явным образом согласуются с условиями интеллектуальной собственности и передачей права собственности на авторские права. В качестве примера вы можете обратиться к руководству RavenDb .

Я предлагаю переместить ваш проект в bitbucket (который также поддерживает git и mercurial).
Там вы можете бесплатно разместить частные репозитории. Наличие кода вашего коммерческого проекта в общественных местах не является хорошей практикой, даже если у вас есть соответствующие лицензии. Всего две мои пенни.

У меня есть новый проект в github. Это публично. Однако я не помню, чтобы меня спрашивали, какую лицензию дать.

Хорошо, вы хорошо помните, Гитуб не спрашивает вас об этом.

В коде google/sourceforge перед запуском нового репозитория я вспоминаю, что мне было предложено передать лицензию с открытым исходным кодом.

Да, они требуют этого для документации. Тем не менее, это не то же самое, что Github.

Конечно, существует разница между открытым и открытым исходным кодом. Могу ли я сказать, например, что вы можете свободно скачивать, читать и изучать код, но вам нужно заплатить $$$ за его запуск? Или вы не можете разветкить его? Или что-то вроде не-open-source-compatible-where-here?

Из того, что я знаю, Github требует от вас (для публичных и 0 $репозиториев) иметь его «с открытым исходным кодом» (без дальнейшего определения смысла этих двух слов), способного «развить» (без дальнейшее определение, какие права передаются с помощью вилки). Если вы напишете Github для поддержки электронной почты, они просто скажут вам что-то подобное со всеми подробностями.

До тех пор, пока вы являетесь автором, и вы заботитесь о том, чтобы полностью заполнить те самые свободные термины самого Github, вы можете делать все, что захотите, и вы можете определить правила, в которых ваше программное обеспечение может быть использовано. Например, вы можете сказать это с открытым исходным кодом в том смысле, что источник открыт и может быть прочитан, и что код может быть разветвлен, но когда разветвлено не все права передаются с разветвленной копией (что означает, что те, кто разветкил копию не лицензировали какие-либо права с помощью своей вилки — в принципе не могут ее использовать), но вы не можете запретить форкировку. Например. в прошлый раз, когда я спросил их, все, что они написали мне, было «тогда вам лучше сделать это видимым», однако нет необходимости.

Имейте в виду, что многие другие не будут разделять эту же точку зрения, поэтому лучше поговорите об этом с адвокатом от вашего имени, поэтому просто для случаев, когда разные мнения, вы знаете по закону, что такое только для вас, а что нет.

kirov-sud.ru

Лицензии на программное обеспечение: что, как и для чего

В этом предложении При этом получается ситуация, что портал зарабатывает на авторах сообщений, а сами авторы — зарабатывают т.к. смартмани, которые обменять на рубли — в общем-то, — никак не возможно. т.е. ничего, в общем то, не зарабатывают. я сделал ошибку. Имел ввиду авторов разработок и статей — а написал, про авторов сообщений.

Я извиняюсь. Но все же, отвечу на ваши замечания. Вы шутите? Многие пользователи ни рубля не заплатили, и прекрасно скачивают разработки.

Разница между разрешением и лицензией

> > То есть органы госавтоинспекции (ГИБДД) и другие соответствующие органы, исходя из правил, предусмотренных в указании МВД от 14 сентября 1995 г.

N 1/4377 «О реализации Закона РФ «О рекламе» (приложение «Требования к размещению рекламы на дорогах, улицах по условиям обеспечения безопасности дорожного движения»)*(87), выносили решение о даче разрешения на размещение рекламы. Так как дорожное движение является источником повышенной опасности, то разрешительный порядок размещения наружной рекламы нацелен на обеспечение безопасности движения.

НКО | Лицензии для открытых и бесплатных проектов.

Все что нужно знать о лицензировании, чтобы не нарушить закон

Вконтакте Twitter Facebook Telegram Вконтакте Twitter Facebook Telegram Вконтакте Twitter Facebook Telegram Выбрать лицен­зию для ваше­го про­ек­та, пере­ве­сти про­из­ве­де­ние в обще­ствен­ное досто­я­ние и пра­виль­но ука­зать copyright в исход­ни­ках – на сай­те Habrahabr опуб­ли­ко­ва­ли подроб­ный мате­ри­ал об автор­ском пра­ве и сво­бод­ных лицен­зи­ях на ПО.

Поделитесь этой статьей с друзьями и коллегами Что делать, если вы созда­ли про­дукт и хоти­те, что­бы им мог­ли поль­зо­вать­ся дру­гие? Как быть уве­рен­ным в том, что вы може­те легаль­но исполь­зо­вать чужой про­дукт в сво­их целях?

В чём разница между популярными Open Source лицензиями?

    18 марта 2020 в 21:47,

В сентябре Github на страницы проектов, которые используют стандартные Open Source лицензии, секцию, в которой эта лицензия указывается: После условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что — нет. Ниже мы приводим краткие описания лицензий и таблицы, которые содержат три колонки:Первая содержит информацию о том, что лицензия вам разрешает делать с проектом (авторское право или закрытые лицензии обычно, напротив, запрещают делать это)

Виды лицензирования

Лицензирование софта начинается с основного разделения на проприетарные лицензии и свободное программное обеспечение.Основным отличием является то, что издатель проприетарного программного продукта в лицензии даёт разрешение её получателю использовать копию (или указанное в лицензии количество копий) программы, тем не менее, сам остаётся правообладателем всех этих копий.

Могут быть запрещены даже те действия, которые официально разрешены в законе об авторском праве.Все правила и условия использования продукта прописываются в Лицензионном соглашении с конечным пользователем – EULA (End User License Agreement), и чаще всего

Исключительное право и исключительная лицензия

22.05.2013 © Depositphotos.com / balaikin На первый взгляд, чем могут отличаться словосочетания, содержание которых совпадают наполовину?

Исключительность есть и там, и там.Также сама лицензия — это своеобразное право или разрешение. Да и право собственно есть возможность.Получается, что в обоих случаях у нас примерно одно и тоже.К такому заблуждению можно прийти, если не быть внимательным к нормам законодательства об интеллектуальной собственности.

Итак. Постановление Федерального арбитражного суда Московского округа от 24 февраля 2011 г.

по делу N А40-106482/09-110-722. Фабула проста. Между истцом (пользователь) и ООО «Топ Фильм Дистрибьюшн» (правообладатель) был заключен договор от 23.04.2008, согласно которому правообладатель представляет пользователю исключительную лицензию на использование аудиовизуальных произведений.

Справочник по лицензированию

Бурное развитие сети Интернет в последние десятилетия обусловило появление новых подходов к созданию и распространению программного обеспечения. Одним из наиболее значительных событий в этой области является появление модели распространения программного обеспечения с открытым исходным кодом (free/open source software, FOSS или OSS), распространяемого на условиях лицензий, обычно именуемых в литературе и на практике «свободными лицензиями».

Ключевые признаки свободной лицензии содержатся в дефинициях, выработанных двумя основными организациями, которые координируют деятельность в сфере пропаганды и продвижения свободного ПО. К ним относится Фонд свободного программного обеспечения (Free Software Foundation), основанный в 1985 г. Ричардом Столлманом (далее – FSF) и Инициатива открытого исходного кода (Open Source Initiative), основанная в 1998 г.

Эриком Реймондом и Брюсом Перенсом (далее – OSI).

Лицензия для вашего open-source проекта

13 ноября 2014 в 11:36 В этой статье я хочу немного поговорить об авторском праве и свободных лицензиях на ПО. Текст является результатом самостоятельного выбора лицензий и их применения к своим проектам. Статья будет полезна тем, кто хочет: — в общих чертах понять, что такое авторское право (но лучше обратиться к юристу); — подобрать свободную лицензию для своего проекта; — разобраться, что нужно писать в шапке файла исходного кода.

Первым делом — ссылка на , очень полезный сайт с описанием лицензий и особенностей их применения (в том числе в России), который я умудрился не найти при подготовке статьи. Исправляюсь. Спасибо за ссылку. Для начала коротко о том, что вообще такое авторское право и лицензии.

Если вы в качестве результата интеллектуальной деятельности создали некое произведение (например, программу), то в этом случае вы — его автор(ы). Вы обладаете имущественными и неимущественными правами на это произведение.

Исключительная и неисключительная лицензия разница

Содержание В современном мире в последнее время много внимания уделяется интеллектуальному праву. В том числе и для защиты программного обеспечения.

В связи с ним даже внесли определенные акты в Гражданский кодекс. И это не мудрено, ведь выкрасть чужое произведение и попытаться выдать за свое может абсолютно любой человек.

Раньше нужно было добыть рукопись, различные черновики работы, а теперь достаточно взломать компьютер автора или облачное хранилище и скопировать чужое творение себе. Сегодня мы поговорим о таком понятии как неисключительное право, выясним, что это такое, чем исключительное право отличается от неисключительного, как защищается и т.

Добавить комментарий