Какие виды лицензий с открытым исходным кодом НЕ подходят для внутреннего использования в корпорации? [закрыто]

Закрыто . Этот вопрос основан на мнении . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы ответить на него фактами и цитатами, отредактировав этот пост .

Закрыто 4 года назад .

Недавно я узнал о нескольких классных дополнительных инструментах и библиотеках с открытым исходным кодом для Microsoft Visual Studio. Инструменты просто помогают вам быть более продуктивным; библиотеки будут связаны с корпоративной кодовой базой.

Я перечислил все эти классные инструменты и библиотеки в электронной таблице, и я собираюсь указать тип лицензии, на которую распространяется каждая из них. Пока что среди моих классных библиотек я вижу MIT , BSD , Apache License Version 2.0 . Однако в будущем их может быть больше.

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

Я хочу быть готовым объяснить, почему использование разрешенных лицензий - это нормально.

licensing open-source

— toddmo
источник

Вы бы действительно хотели обсудить это с кем-то из вашей компании. Как правило, использование чего-либо GPL в проприетарном программном обеспечении является нарушением. Лицензия GPL является вирусной , что означает, что если ваша компания использует код, лицензированный по лицензии GPL, им, по сути, придется открывать исходный код всего проекта. Однако большинство лицензий с открытым исходным кодом не являются вирусными. Некоторые, такие как Общественная лицензия Mozilla, требуют, чтобы вы свободно публиковали изменения, которые вы вносите в саму кодовую базу MPL , но это требование не распространяется на ваш собственный код. Но это действительно слишком широкий вопрос, чтобы легко ответить здесь.

— Мейсон Уилер

@MasonWheeler: такие положения, как copyleft, касаются распространения; если программа будет использоваться только для внутренних целей, это не имеет значения.

— Роберт Харви

@toddmo: кажется, Мейсон Уилер, когда писал о GPL, полностью проигнорировал ваш вопрос «не распространяться за пределами компании»? См. Stackoverflow.com/questions/1492687/…

— Док Браун,

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

— Брандин

@BasileStarynkevitch Вопросы о лицензиях с точки зрения разработчика программного обеспечения (например, использование, какая лицензия, понимание и т. Д.) Являются темой ON, если они не обращаются за специальными юридическими консультациями. У меня сложилось впечатление, что с этим вопросом все в порядке, так как ОП ищет руководство по выбору соответствующей лицензии на программное обеспечение, над которым он работает.

— maple_shaft

Ответы:

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

Коммерческое использование и
Распространение.

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

Коммерческое использование (или другие произвольные ограничения) - это другое дело. Просто внимательно прочитайте лицензию и определите, распространяется ли какое-либо из этих ограничений на вашу организацию. В частности, разрешительные лицензии, такие как Apache, MIT и BSD, имеют несколько ограничительных условий, если таковые имеются; эти лицензии идеально подходят для «внутреннего использования».

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

— Роберт Харви
источник

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

— Роберт Харви

Большинство компаний просто не будут касаться «авторских» лицензий, и на то есть веские причины; невозможно полностью «изолировать» систему и гарантировать, что ничто никогда не коснется кода GPL / AGPL. Некоторые явно «разрешительные» лицензии, такие как WTFPL, также не помогают, потому что они слишком расплывчаты по таким важным юридическим вопросам, как авторское право. Даже если вы думаете, что могли бы успешно защититься от судебного процесса, вы действительно хотите пройти через это? (Подсказка: ваши адвокаты, вероятно, нет.) Придерживайтесь Apache и MIT. Я думаю, что BSD также в порядке.

— Aaronaught

@Aaronaught Есть ли у вас какой-либо уважаемый источник, подтверждающий ваше утверждение о том, что WTFPL имеет неопределенные авторские права? FSF принимает его как GPL-совместимый. Основные дистрибутивы Linux принимают его как бесплатный. Я могу найти утверждение, что OSI отклонил его как слишком расплывчатый, но это неверно, OSI отклонил его как избыточный, поскольку быстрый поиск в Google по запросу "wtfpl osi" подтвердит. Конечно, я могу думать о проблемах с WTFPL, но когда речь идет об авторских правах, неопределенность не является одной из этих проблем.

— HVd

@hvd: Вас может шокировать то, что корпоративные юристы не заботятся о таких вещах, как «бесплатный» или «несвободный». Они заботятся о том, «можем ли мы использовать это без предъявления иска?». Вы на самом деле читали WTFPL ? Это ничего вам не говорит. Прочтите раздел 2 Лицензии Apache, чтобы увидеть, как выглядит правильное положение об авторском праве. WTFPL явно не предоставляет лицензию на авторское право и не делает указанную лицензию безотзывной. Вам не нужно читать оценку FSF - просто посмотрите на лицензию самостоятельно!

— Aaronaught

Мы все еще говорим об этом?

— Роберт Харви

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

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

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

— gnasher729
источник

Во втором примере это будет чья-то проблема

— whatsisname

@whatsisname Скажи это оригинальному автору, когда она подаст на тебя в суд.

— Сапи

@whatsisname Если A написал программное обеспечение и владеет авторскими правами, B распространяет его по какой-то лицензии без разрешения, а C получает программное обеспечение от B и использует и, возможно, изменяет или распространяет его, тогда, если A ловит C, делая это, A не имеет никаких обязательств, морально или законно, чтобы преследовать B. A, возможно, даже не подозревает о B. C - тот, кто пойман, используя, изменяя, перераспределяя, поэтому C - тот, кто должен остановиться и выплатить убытки. В аду ни за что не дадут продолжить. В лучшем случае C может затем пойти за B в суде, но это только в том случае, если C действительно может найти B. Удачи, если это какой-то парень, например, в Китае.

— HVd

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

— Брандин

Второй абзац самый опасный. Я лично столкнулся с этим сам, когда разработчик упомянул, что часть кода была «чем-то, что он нашел на каком-то сайте» довольно близко к релизу. Не смешно. Урок № 412 в разделе «почему вы должны все пересматривать в коде».

— Gort the Robot

Это во многом зависит от контекста.

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

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

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

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

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

— Дамиан Никодем
источник