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

В настоящее время я занимаюсь своими аспирантурами с акцентом на анализе данных/информатике в контексте исследований и разработке полезных инструментов для глобального исследовательского сообщества, причем подавляющее большинство моих предполагаемых пользователей являются скорее компьютерными новичками. Другими словами, большинство моих пользователей не будут беспокоиться (или быть в состоянии) собирать необходимые зависимости и помещать их в свои пути к классам. Чтобы люди не игнорировали мое программное обеспечение, я распространял его как "жир-банку" со всеми зависимостями, содержащимися в одном исполняемом файле.

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

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

  • Пока вы не перераспределяете свои зависимости, на самом деле не имеет значения, какие у них лицензии, по сравнению с той лицензией, которую вы выбрали для своего проекта. [К сожалению, этот путь также означал бы, что я буду отчуждать/запугивать значительную часть моей базы данных]

  • Если вы перераспределяете все свои зависимости, тогда ваша проектная лицензия должна быть совместима с вашими зависимостями. [Таким образом, я как разработчик должен знать детали лицензий для каждой зависимости?]

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

  • Предполагая, что мой проект находится под GPL, тот факт, что проект является некоммерческим, не имеет значения, он также должен быть открытым исходным кодом. [Это довольно сложно в моей ситуации, поскольку алгоритмы и вычислительные методы должны быть "новыми" для публикации]

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

Литература:

Должен ли я быть связан с большим количеством зависимостей?

Какие лицензии совместимы друг с другом?

Где я могу найти авторитетный обзор лицензий с открытым исходным кодом?

Как выбрать лицензию с открытым исходным кодом?

Поиск некоммерческой лицензии на исходный код

Является ли законным способом использовать код GPL в приложении с закрытым исходным кодом через плагин?

Как узнать, могу ли я повторно использовать бесплатную библиотеку программного обеспечения в коммерческом приложении? [Закрытыми]

Правильное применение лицензии с открытым исходным кодом (в частности этот ответ by @Michael Aaron Safyan)

Как найти лицензию с открытым исходным кодом, подходящую для моего проекта?

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

Как выбрать лицензию с открытым исходным кодом?

ОТВЕТЫ

Ответ 1

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

Да, это правда... для зависимостей с открытым исходным кодом с основными лицензиями. Но:

  • Это заставляет пользователей загружать все зависимости, которые являются плохими идеями.
  • Для зависимых от зависимостей (и зависимостей с открытым исходным кодом с "сумасшедшими" лицензиями) возможно, что лицензия запрещает это или затрудняет (-er) для ваших пользователей, запрещая им делать что-то.

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

Да. Но это обычно не сложно. Там можно найти, какие лицензии совместимы с другими; например страницы GPL FSF.

[Таким образом, я как разработчик должен знать детали лицензий для каждой зависимости?]

Да. Но вы можете упростить это, только используя зависимости с безопасными лицензиями. (И большинство лицензий с открытым исходным кодом.)

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

Да. Однако обратите внимание, что существует большая разница между GPL и LGPL. LGPL не имеет этого ограничения.

... что теоретически может противоречить лицензии какой-либо другой зависимости.

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

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

Это правильно.

[Это довольно сложно в моей ситуации, поскольку алгоритмы и вычислительные методы должны быть "новыми" для публикации]

Я думаю, что вы делаете большую проблему из чего-то, что не должно быть проблемой:

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

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

... можно ли избежать проблем с лицензиями для моих зависимостей?

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

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

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

Но вы не можете игнорировать проблему.

Суть в том, что вы получаете что-то бесплатно, когда вы создаете свой код с зависимостями с открытым исходным кодом, но quid pro quo - это то, что вам нужно играть по правилам взамен. Если вам не нравятся правила, найдите другой способ, который не связан с открытым исходным кодом.

Ответ 2

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

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

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

GPL, как вы сказали, самый строгий, но большинство лицензий OSS совместимы с GPLv3. Apache, BSD, MIT, MPL, X11/MIT.

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

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

Но, сводилось к 3 понятиям:

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

  • Если вы используете GPL-библиотеку, вам также следует GPL ваше программное обеспечение.

  • Если ничего из вышеперечисленного, просто не беспокойтесь об этом.

Ответ 3

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

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

  • если вы используете коммерческие librairies, получите лицензию (у многих из них есть бесплатные распространяемые лицензии для проектов с открытым исходным кодом)

  • Если вы используете GPL librairies, сделайте свой проект GPL (это то, что вы делаете в любом случае)

Ответ 4

Я думаю, вы правильно поняли свои четыре точки.

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

Ответ 5

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

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

Есть несколько подобных случаев, недавно Java Oracle в Linux..

Проблема GPL:

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