GPL на рабочем месте?


12

Однажды я брал интервью в консалтинговой компании, где в разговоре выяснилось, что они используют продукты с открытым исходным кодом (что здорово, я широко использовал Hibernate, JBoss и т. Д.). Меня удивило то, что, когда я спросил, они использовали лицензию GPL OSS при написании приложений для клиентов, они сказали: «Конечно, все время! Пока клиент получает то, что хочет, и счастлив». Я не юрист и не большой любитель лицензий, но у меня сложилось впечатление, что, используя код GPL (скажем, некоторую библиотеку, которую вы включаете), вы обязаны выпустить все приложение под той же лицензией. Когда я указал на это, мне дали быстрый ответ: «Ну, мы даем клиентам весь исходный код, когда мы закончим, так что это действительно не проблема».

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

Ответы:


15

Применяются стандартные заявления об отказе от ответственности: я не юрист, как и вы.

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

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

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


1
Вы правы, однако AGPL более строг в этом

@Pierre: правильно, в том смысле, что вы не можете получить доступ к источникам для своих пользователей, придерживаясь серверных приложений.
Shog9

1
Интересный. Итак, если в стандартном GPL вы пишете приложение SaaS, то вам не нужно указывать исходный код, поскольку вы технически не «распространяете» само приложение?
Райан Хейс

2
@ Райан: верно. Ну, вы не обязаны давать его своим пользователям . Любой, кто получает скомпилированный код, по-прежнему получает исходный код.
Shog9

7

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

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

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


2

Открытый источник не обязательно означает бесплатный.

IANAL тоже, но в целом требование для GPL - предоставить исходный код для вашего проекта. Вы, безусловно, можете продать товар кому-то еще. Тем не менее, я считаю, что вы не можете помешать им отдать его. Это, вероятно, то, что делает большинство программ GPL бесплатным, как в пиве. Я совершенно уверен, что вам не нужно публиковать свой код в world + dog только потому, что это GPL'd.

От преамбулы до v3 GPL (выделение мое):

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

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

( источник )

В этой ситуации право компании на использование кода GPL без ведома клиента? Достаточно ли просто «дать им источник»?

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


2
GPL не требует, чтобы вы активно публиковали исходный код, но он требует, чтобы вы опубликовали пользователю тот факт, что программа является GPL, и что вы предоставите исходный код по запросу (возможно, при условии справедливой и разумной платы за обработку). На практике последнее требование часто обрабатывается архивом или почтовым индексом по URL, который может быть выдан по запросу. Как консультант, вы обязаны сообщить своему клиенту, какое у него будет бремя, если он распространит вашу работу среди других, потому что он становится издателем в соответствии с GPL.
RBerteig

@RBerteig Спасибо за разъяснения. Прошло много времени с тех пор, как я перерыл условия лицензии.
Джордж Мариан

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

-5

Нет вы правы Вот почему:

Подумайте, есть ли у нас приложение под лицензией GPL. Теперь, тогда это не может быть использовано проприетарным кодом.

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

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


4
Это не имеет никакого смысла. В GPL не указано, что проприетарный код не может его использовать. GPL - все о распределении, как ясно говорит ответ г-на С. Короче говоря, вам не разрешается распространять программное обеспечение, использующее код GPL, если вы также не распространяете исходный код этого программного обеспечения по совместимой лицензии.
dash-tom-bang

1
Собственный код не может использовать код GPL. Это одна из причин существования лицензии.
альтернатива

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

@Г-н. С частным кодом я имею в виду код, который несовместим с GPL. А код будет распределен клиенту так ... Но да, я не юрист , так что я мог бы быть неправым.
альтернатива

2
-1, вводящий в заблуждение ответ. Это верно только для некоторых определений «использования» и «проприетарного». Например, я мог бы создать встраиваемый продукт Linux и выпускать только ядро ​​Linux и код, который напрямую связан с кодом ядра, но не мой пользовательский интерфейс или другие приложения, которые просто работают на ядре GPL. Существует много таких отношений. Неопределенность в этом использовании «проприетарного» уже покрыта. Кроме того, в большинстве юрисдикций «работа по найму», предоставляемая только той стороне, которая наняла разработчика для кодирования, отличается от распределения. IANAL и т. Д.
HedgeMage
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.