GPL - що таке розподіл?

22

Цікавим моментом виникла інша тема про нібито присвоєння проекту GPL. У цьому випадку корпоративне програмне забезпечення використовувалося деякими великими компаніями, які по суті взяли код, змінили назву, видалили повідомлення GPL та використали результат.

Сенс полягав у тому, що - якщо компанія зробила це і використовувала лише програмне забезпечення всередині країни, то дистрибуції не існує, і це абсолютно законно згідно GPL. Можливі також зміни власних службовців для внутрішнього використання.

Отже, в який момент він стає розподілом?
Імовірно, якби вони залучали сторонніх підрядників під "роботу за наймом", їх модифікації також були б внутрішніми, а отже, не розповсюдженнями.

Якби вони найняли зовнішнє програмне забезпечення для внесення змін і ці зміни використовувались лише внутрішніми компаніями - чи будуть ці зміни поширюватися? Чи GPL застосовується до клієнта чи до зовнішніх розробників?

Якщо компанія потім дасть результат в інший відділ, інший підрозділ, іншу компанію? Що робити, якщо інша компанія є повністю дочірньою компанією?

пс. так, я знаю, що відповідь запитайте у юриста. Але вся дискусія, яку я бачив над розподілом GPL2 / GPL3, стосувалася веб- служб, а не внутрішнього використання.

legal gpl

— Мартін Беккет
джерело

GPL3 використовує терміни "Передати" та "Поширити", а не поширювати.

— Крейг

Питання веб-сервісу: programmers.stackexchange.com/questions/131264/…

— Ciro Santilli 新疆改造中心法轮功六四事件

Я розмістив дещо пов’язане запитання до закону SE на випадок, якщо хтось зацікавлений у відповіді: Чи потрібно дотримуватися ліцензії GPL під час оренди обладнання?

— Козуч

11

Суть GPL полягає в тому, що він не обмежує те, що ви можете зробити з програмним забезпеченням - він пред'являє до вас вимоги, коли ви передаєте або розповсюджуєте роботу, що охоплюється. Щоб цитувати GPLv3 :

"Поширювати" твір означає робити що-небудь з ним, що без дозволу притягуватиме вас до прямої чи вторинної відповідальності за порушення відповідно до чинного законодавства про авторські права, за винятком його виконання на комп'ютері чи зміни приватної копії . [наголос додано]

Тож якщо ви користуєтесь лише приватною копією, ви не розповсюджуєте та не передаєте роботу, тому умови, які дозволяють передати роботу, не є актуальними.

Дивіться це поширене запитання :

Чи GPL вимагає, щоб вихідний код модифікованих версій був розміщений для загального користування?

GPL не вимагає, щоб ви звільняли модифіковану версію чи будь-яку її частину. Ви можете внести зміни та використовувати їх приватно, не випускаючи їх ніколи. Це стосується і організацій (включаючи компанії); організація може виготовити модифіковану версію та використовувати її всередині країни, не випускаючи її за межі організації.

— Крейг
джерело

6

Тож зробити похідну із закритого джерела та лише розповсюдити її в межах моєї "організації" здається нормальним. Але що робити, якщо я дозволю комусь стати членом моєї організації? Зайняти їх на цент? Або навіть поставити двійковий файл на своєму веб-сайті і сказати «завантажуючи це, я надаю вам членство в моїй організації»? Цікаво, де ти міг би провести лінію.

— jdm

2

IANAL, але я думаю, це не так просто. Вам знадобиться якась юридична особа, яка є вашою організацією. Без юридичної особи це лише купа фізичних осіб, і ви насправді пропагуєте або передаєте роботу. Зрозуміти, хто є, а не є "членом", ймовірно, договірне чи трудове право. І, як завжди, тому, що те, що ви робите, є законним, і ви виграєте судовий процес, не означає, що вас не пред'являть позов.

— Крейг

2

Випадково заборонено і тепер голосування заблоковано :(

— whatsisname

Я підтримав це для вас;)

— axel22

Ви пропускаєте суть. Якщо ви поширюєте двійковий файл кому-небудь (всередині або поза вашою "організацією", однак ви вирішите це визначити), ви також повинні зробити доступним вихідний код для цього одержувача. Причина "організації" з'являється, чи вважається, що ви не проти давати людям доступ до вихідного коду, оскільки вони у вашій "організації".

— Роб

5

Подивіться на це так. Не важливо, чи є різні відділи чи дочірні компанії. Важливо лише, якщо ви збираєтеся поширювати бінарні файли іншій стороні, а не надавати їм джерело.

Якщо є інший відділ, який буде використовувати модифікації, вони отримають джерело для роботи над ним. Немає нічого. Ви дотримуєтесь усього, що міститься в ліцензії. Кожен, хто може отримати розповсюдження, потребує джерела.

Послуги по мережі не вважаються розповсюдженням.

Ось спроба простого пояснення GPL:

Якщо проект GPL виробляє , також має існувати awesomeProduct.jarбудь-яке місце, яке awesomeProduct.jarіснує awesomeProduct_src.jar. Якщо когось немає, awesomeProduct.jarвони не отримуютьawesemeProduct_src.jar

— Ендрю Т Фіннелл
джерело

Юридично я припускаю, що питання - "інша партія". наприклад, для такого гігантського багатонаціонального корпусу, як Samsung або Mitsubishi, може бути багато організацій, які не вважаються "іншою партією". Моя думка полягала в тому, що мегакорпус може взяти Linux, змінити його, продати 1000 тисячам користувачів у 100-х дочірніх компаніях і все ще бути в GPL

— Мартін Бекетт

@MartinBeckett Не має значення. Якщо ви не припускаєте, що Департамент А виробляє продукт із джерела GPL і не надасть Департаменту B джерело.

— Ендрю Т Фіннелл

Якщо я модифікую GPL-код і надаю його вам, вам також доведеться перерозподілити його. Якщо ви платите мені, щоб я його змінив - чи все-таки потрібно поширювати? Якщо ви Ford і даєте йому Jaguar, чи не так? Здавалося, цікавий момент!

— Мартін Бекетт

- Я думаю, що цей момент з’явився в Android. Чи розповсюджувала Google модифіковане ядро Linux лише виробнику телефону або кожному кінцевому користувачеві телефону? Не пам'ятаю, чи був висновок.

— Мартін Бекетт

1

насправді, якщо бізнес орієнтований на абсолютно різні дочірні компанії, вони не будуть частиною однієї компанії. У них будуть різні акаунти і подібні. Поширювати їх буде інша компанія. Це досить легко сказати, чи є у вас той же генеральний директор? Чи публікують вони різні акаунти? Якщо, наприклад, Google UK є абсолютно іншою юридичною особою, ніж Google US, і вони сплачують Google US (або Google TaxHaven, тобто) ліцензійну плату за свої продукти, вони не зможуть розповсюджувати продукт GPL без джерела.

— gbjbaanb

3

Якщо це хоче зробити компанія, то існує дуже простий метод уникнути всіх зобов’язань та всіх юридичних проблем: Щоразу, коли ви даєте копію програмного забезпечення працівнику, надайте їм повний вихідний код одночасно. Це один із трьох способів виконання своїх зобов’язань відповідно до GPL.

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

— gnasher729
джерело

На жаль, безпосередньо суперечить GPL, оскільки GPL означає, що при повторному розповсюдженні ви не можете змінити ліцензію. Це означає, що зобов’язання одержувача вихідного коду не повторно поширювати його під GPL явно забороняється. "Ви не можете поширювати чи змінювати охоплені роботи, за винятком випадків, передбачених цією Ліцензією." (GPLv3, Sect.8) І далі: "Ви не можете встановлювати будь-які додаткові обмеження щодо здійснення прав, наданих або підтверджених відповідно до цієї Ліцензії." (там же, розділ 10)

— Унапіедра

@Unapiedra Ви впевнені? Наскільки я це розумію, це те, що роботодавець все ще поширює його на службовців у рамках GPL. Вони мають законне право, як це гарантується ліцензією, поширювати код. Але компанія все ще потребує їх, щоб вони не користувались цим правом, тому, якщо вони будуть, вони будуть звільнені. Це все, що станеться, хоча; роботодавець не понесе юридичної відповідальності за його витік, оскільки їм спеціально надана юридична ліцензія на це. Хоча ризик для компанії - якщо працівник покидає компанію, компанія не може зупинити їх розповсюдження коду.

— flarn2006

@ flarn2006, чи не відповідає цим питанням FSF, що роботодавець може обмежити працівника від витоку коду?

— csrowell

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

— csrowell

Крім того, є питання щодо крадіжок , яке, на мою думку, підпадало б, якби працівник випустив код: "... Якщо розглянутий варіант не опублікований і компанія вважається його комерційною таємницею, то публікація може бути порушення закону про комерційну таємницю, залежно від інших обставин. GPL цього не змінює. Якщо компанія спробує випустити свою версію і досі розглядає її як комерційну таємницю, це порушило б GPL, але якщо компанія не випустила у цій версії такого порушення не сталося ».

— csrowell

0

Я б переглянув цю цитату з їх веб-сайту

Якщо ви комерційно поширюєте бінарні файли, не супроводжувані вихідним кодом, GPL каже, що ви повинні надати письмову пропозицію поширити вихідний код пізніше. Коли користувачі, комерційно перерозподіляючи бінарні файли, отримані від вас, вони повинні передати копію цієї письмової пропозиції. Це означає, що люди, які не отримували бінарні файли безпосередньо від вас, все одно можуть отримувати копії вихідного коду разом з письмовою пропозицією.

Ви повинні пройти джерело всю дорогу вниз по ланцюгу, просто подивіться на це, як ваша зовнішня api є замовником внутрішньої api. Вимога забезпечити джерело успадковується зовнішнім використанням api внутрішнього api.

— icirellik
джерело