Как создать лицензию для своей программы

Написал программу сортировки (версия сортировки слиянием с «маленькой» дополнительной памятью), исходный текст которой хочу опубликовать в сети. В частности обсудить ее здесь. Желательно, чтобы все могли ее использовать, переделывать и т.д. и никто не смог в дальнейшем запретить остальным делать это. В общем свободный source.

Читал (может не очень вдумчиво, слов всюду много) об этом, но так и на понял, какой комментарий надо поместить в начало файла с исходником и нужны ли какие-то еще действия с моей стороны. Прошу помощи. Желательно конкретный «шаблон», а не ссылки на общие указания. UPDATE 1 Всем спасибо за ответы. Как Вы считаете, следующий текст в начале исходника — это то что нужно ?

/* Copyright (C) 2012 Vasily Anishchenko This file is part of the Yamsort. (Yet Another Merge Sort Routines) Yamsort is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Yamsort is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with Yamsort.

If not, see . (Этот файл — часть Yamsort. Yamsort — свободная программа: вы можете перераспространять ее и/или изменять ее на условиях Стандартной общественной лицензии GNU в том виде, в каком она была опубликована Фондом свободного программного обеспечения; либо версии 3 лицензии, либо (по вашему выбору) любой более поздней версии.

Лицензионные программы бесплатно. Бесплатные лицензии.

Yamsort распространяется в надежде, что она будет полезной, но БЕЗО ВСЯКИХ ГАРАНТИЙ; даже без неявной гарантии ТОВАРНОГО ВИДА или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. Подробнее см. в Стандартной общественной лицензии GNU. Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой. Если это не так, см. .) */

Может быть еще что-либо нужно (и где ?) добавлять ?

Источник: ru.stackoverflow.com

Как создать лицензию для своей программы

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

• Получить отказ от авторских прав у своего работодателя или учебного заведения.
• Присоединить к каждому файлу соответствующие уведомления об авторских правах. Не забывайте ясно указывать, какие версии лицензии могут применять пользователи.
• Добавить файл COPYING с копией GNU GPL или GNU AGPL.
• Добавить также файл COPYING.LESSER с копией GNU LGPL, если вы применяете ее.
• Поместить в каждый файл уведомление о лицензии.
• (По желанию) сделать так, чтобы программа отображала уведомление в начале работы.
• (Если применяется AGPL) сделать так, чтобы программа предлагала копии своего исходного текста.

Процедура включает в себя добавление двух элементов в каждый файл исходного текста вашей программы: замечание об авторских правах (например, “Copyright 1999 Терри Джонс”) и заявление о разрешении копирования, в котором сказано, что программа распространяется на условиях Стандартной общественной лицензии GNU (или Меньшей GPL, или GPL Афферо).

Отказ от авторских прав

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

Вот пример отказа от авторских прав; поменяйте имена, название и описание программы соответствующим образом:

Данной справкой ЗАО “Чудо-Юдо” отказывается от всех претензий на авторские права на программу “Дятел” (которая деконструирует деревья), написанной Яковом Хакером.

подпись Кощея Бессмертного, 1 апреля 1989 года
Кощей Бессмертный, губернатор Тридевятого царства

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

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

Замечание об авторских правах

В замечание об авторском праве должен входить год, в который вы завершили подготовку выпуска (так что если вы завершили ее в 1998 году, но не выпускали до 1999 года, пишите “1998”). Вам следует добавлять соответствующий год для каждого выпуска; например, “Copyright 1998, 1999 Терри Джонс”, если некоторые выпуски были закончены в 1998 году, а другие — в 1999. Если несколько людей помогало писать программу, вписывайте все их имена.

Для программ с несколькими выпусками в течение многих лет допустимо писать диапазон (“2008—2010”) вместо перечисления отдельных лет (“2008, 2009, 2010”) тогда и только тогда, когда каждый год в диапазоне (включительно) в действительности является значимым с точки зрения авторского права и был бы перечислен отдельно; и когда вы заявляете об этом в явном виде в своей документации.

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

Файлы лицензий

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

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

Уведомления о лицензии

Объявление о разрешении копирования для каждого файла (называемое также уведомлением о лицензии) должно идти прямо после заявлений об авторских правах на него. Для программы, состоящей из одного файла, это объявление (для программ, выпущенных под “GPL версии 3 и более поздней”) должно выглядеть так:

Это свободная программа: вы можете перераспространять ее и/или изменять ее на условиях Стандартной общественной лицензии GNU в том виде, в каком она была опубликована Фондом свободного программного обеспечения; либо версии 3 лицензии, либо (по вашему выбору) любой более поздней версии.

Эта программа распространяется в надежде, что она будет полезной, но БЕЗО ВСЯКИХ ГАРАНТИЙ; даже без неявной гарантии ТОВАРНОГО ВИДА или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. Подробнее см. в Стандартной общественной лицензии GNU.

Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой. Если это не так, см. .

Для программ, состоящих более, чем из одного файла, лучше заменить слова “эта программа” на название программы и начать объявление со строки, в которой сказано: “Этот файл — часть НАЗВАНИЕ”. Например,

Этот файл — часть Foobar.

Foobar — свободная программа: вы можете перераспространять ее и/или изменять ее на условиях Стандартной общественной лицензии GNU в том виде, в каком она была опубликована Фондом свободного программного обеспечения; либо версии 3 лицензии, либо (по вашему выбору) любой более поздней версии.

Foobar распространяется в надежде, что она будет полезной, но БЕЗО ВСЯКИХ ГАРАНТИЙ; даже без неявной гарантии ТОВАРНОГО ВИДА или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. Подробнее см. в Стандартной общественной лицензии GNU.

Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой. Если это не так, см. .

Чтобы применить другой набор версий GPL, измените конец первого большого абзаца. Например, если программа под GPL версии 2 или более поздней, замените “3” на “2”.

Это объявление должно находиться вблизи начала каждого исходного файла, рядом с замечаниями об авторских правах. Когда используется Меньшая GPL, вставьте слово “Меньшая” перед словом “Стандартная” во всех трех местах. Когда используется GNU AGPL, вставьте слово “Афферо” перед словом “Стандартная” во всех трех местах.

Для чего нужны уведомления о лицензии?

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

Если у программы вместе с исходными файлами есть копия лицензии Л, но нет явного заявления, что “Эта программа выпущена по лицензии Л“, это оставляет возможность неопределенности того, распространяется ли лицензия Л на тексты этой программы.

Если в выпуске есть одно утверждение, что “Эта программа выпущена по лицензии Л”, в центральном месте, таком как файл README, это делает ситуацию ясной для этого выпуска. Однако программисты часто копируют исходные файлы из одной свободной программы в другую. Если исходный файл не содержит заявления о том, какая у него лицензия, то перемещение его в другой контекст устраняет все следы лицензии. Это приводит к путанице и заблуждениям.

Уведомление при запуске

Уведомление Афферо

Если вы выпускаете свою программу по GNU AGPL и она может взаимодействовать с пользователями по сети, программа должна предлагать этим пользователям свой исходный текст тем или иным образом. Например, если ваша программа является приложением для Интернета, то она могла бы показывать ссылку “исходный текст”, которая приводила бы пользователей к архиву исходного текста. GNU AGPL достаточно гибка, чтобы вы могли выбрать метод, подходящий для вашей конкретной программы — подробности см. в разделе 13.

Прочее

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

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

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

Источник: www.gnu.org

Что нужно знать про лицензии GitHub: как выбрать и добавить

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

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

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

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

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

Зачем нужно лицензирование Open Source проектов на GitHub

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

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

Какие виды лицензий существуют

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

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

На практике также принято применять мультилицензирование. Чаще всего в таких случаях используют одновременно две лицензии.

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

Лицензии, используемые на Git Hub чаще всего:

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

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

Как выбрать Github лицензию

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

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

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

1. https://choosealicense.com/. На этом сайте имеются наводящие вопросы для выбора подходящего варианта и подробные консультации, помогающие понять особенности использования.
2. Страница https://opensource.org/licenses посвящена рассмотрению различных свободных решений для программного обеспечения.
3. Сайт https://tldrlegal.com/ можно рассматривать в качестве энциклопедии для различных вариантов лицензий. Здесь имеются как точные юридические формулировки, так и подробные комментарии.

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

Как добавить лицензию на Github

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

Нужно перейти на главную страницу своего репозитория.

Подтвердив внесённые изменения, разработчик завершает процедуру внесения изменений в список лицензий на сервисе Git Hub.

Choose a license Github – примеры популярных лицензий на Git Hub

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

GPL

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

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

Самой поздней из них является третья. GPL была использована разработчиками таких программ, как система управления веб-контентом Drupal, система управления базами данных MariaDB, векторный графический редактор InkSkape и некоторых других.

Интересно отметить, что SQL использует не только GPL, но и коммерческую лицензию.

LGPL

Это название переводится как «Меньшая стандартная общественная лицензия GNU GPL». Некоторым разработчикам GPL не подходит, так как создаёт для них обязанность распространять модифицированные продукты под той же лицензией.

1. Когда библиотека обеспечивает выполнение новых функций, причём никакие коммерческие библиотеки не могут выполнить аналогичную задачу, то в этом случае оптимальным является применение GPL.
2. Разработчик в свободной библиотеке уже реализовал существующий стандарт. В этой сфере имеются коммерческие варианты с аналогичными функциями. Для этого случае будет удобно выбрать LGPL.
3. Когда речь идёт о новом стандарте, который фактически находится в конкуренции с коммерческим, здесь подойдёт применение лицензии Apache.

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

Eclipse Public License

Этот документ разрешает распространение под другими лицензиями, в том числе и коммерческими.

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

Mozilla Public License

Некоторые рассматривают этот документ как компромисс между GPL и коммерческими лицензиями. Требованием MPL является наличие открытого доступа к определённым файлам. В программном продукте могут быть одни файлы под этой лицензией, а другие — без неё.

После модификации разрешается поставить ту лицензию, которая нужна (например, речь может идти о коммерческой), однако это возможно только при условии, что доступ к файлам, выпущенным под MPL будет по-прежнему открытым.

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

Apache License Github

AL принято называть либеральной свободной лицензией. Эта особенность связана с тем, что здесь отсутствует требование выпускать производный продукт под теми же условиями, что и раньше. Этим документом активно пользуется компания Apache Software Foundation.

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

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

Это можно продемонстрировать, перечислив известные программные продукты, которые выпускаются под этим видом лицензии: операционная система Android, фреймворк, с помощью которого создаются корпоративные приложения на Java, веб-сервер Apache.

MIT Licence

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

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

Программными продуктами, которые используют этот документ являются: библиотека JavaScript под названием JQuiery, текстовый редактор Atom, AngularJS – фреймворк для разработки на JavaSсript.

Подводные камни

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

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

При распространении под MPL те, кто вносил изменения в код, не могут файлы под MPL предлагать под другой лицензией. Использование нового документа будет относиться к другим программным модулям.

Если вам понравилась статья, то подписывайтесь на мой телеграм канал.

Источник: articles.opexflow.com