Поставьте мне мозг на место: GPLv3 + shared memory

Ну обмен же прозрачен для gpl части, то есть ее можно менять, вроде в этом случае все нормально.

Если не ошибаюсь похожая схема для модулей ядра: http://stackoverflow.com/questions/2721290/propietary-modules-within-gpl-and-...

а блин, пардон, не уверен

Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

http://www.gnu.org/licenses/gpl-faq.html

А когда туда сокеты пропишут линуксом нельзя будет пользоваться даже в качестве SaaS ? Столлман слишком многого хочет. Реализация API даже через shm это тяжкий труд, который достоин быть отвязанным от GPL.

Ну короче, я пока предложил два варианта:

1) «сделать пользу» = реализовать shared-memory транспорт посредством модуля ядра, в идеале как backend для MPI, благо есть futex-ы;

2) «спасибо кэп» = отказаться от использования GPL-компонентов;

Всё, пришел пятницо и swarm arrives...

Все же есть стандартная лазейка - через lgpl. Пишешь либу, а к ней пишешь свою закрытую софтину. Т.к. оба продукта твоего авторства, то GPL не запрещает пойти таким путем.

Хм, ну это лазейка работает до тех пор пока собственная LGPL не касается GPL. А после сумма автоматически переходит в GPL.

Там же дальше:

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

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

- вопрос, это нарушение GPLv3 или нет?

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

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

Я не написал, но конечно предполагается все это дело распространять.

Хм, ну это лазейка работает до тех пор пока собственная LGPL не касается GPL. А после сумма автоматически переходит в GPL.

В общем случае LGPL линкуется с GPL, не теряя LGPL. Условие: LGPL - это не просто обёртка, а что-то обобщающее и имеющее пользу для других.

Т.е. если удастся обобщить этот код

к указанному GPLv3 проекту добавили код, реализующий транспорт через разделяемую память;

так что будет очевидность необходимости LGPL-библиотечки, то проблема решена, а вот если нет...

IMHO логичны такие требования:

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

но конечно предполагается все это дело распространять.

Тогда следи за руками.

Как уже говорилось GPL-ный код может использовать несвободный, если тот удовлетворяет критерию системности. Что бы распространять сумму из свободного и несвободного можно сделать их сборник под совокупной лицензией не ущемляющей свободню часть, т. е. нужно объяснить что вот эта часть свободная и с ней можно все что согласно свободам имени FSF. А вот та часть несвободная и с ней нужно аккуратно, в перчатках, и согласно букве EULA. А также написать что несвободная часть поставляется отдельно от свободной и желательно еще один метод получения отличный от этого сборника, что бы удовлетворять критерию системности. Затем что бы полностью отвязать свободную часть потребуется третий компонет заботящийся о правильном размещении на диске, бибилиотеках, установке канала связи между открытой и закрытой частями. Для примера, в дистрах линукса эту роль выполняют инсталятор и система управления пакетами. Сам по себе код канала связи лучше оформить под LGPL, но это для удобства взаимодействия. Сама по себе LGPL, не является обязательной и не гарнтирует легальность распространения без соблюденя условий перечисленых выше. Вот по такой схеме в линксуовом дистре появляется опакеченый плагин флэша и может быть использован в GPL-ном браузере.

Не о том думаешь. GPL-ную библиотеку нельзя включать в несвободный проект не потому что pid будет один на всё, а потому что при распространении такая смесь не будет обспечивать свобод заявляныз для GPL. И в этом смысле абсолютно безсмыслено считать количество процессов или выяснять как и через что они были запущены.

интерфейс взаимодействия и структура сообщений/данных должны быть открыты и воспроизводимы на основе прилагаемых исходников

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

Что-то мы про разные вещи говорим :)

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

pid-ы были помянуты как пояснения для способа отличать две разные программы взаимодействующие через некий системный интерфейс (shared memory), от одной программы взаимодействующей со своими плагинами.

Конечно спорный вопрос считать ли shared memory системным интерфейсом. Вот в этом контексте было упомянуто о выпуске кода описывающего структуру данных под LGPL.

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

Вот в этом направлении и предполагается идти. :)

Конечно спорный вопрос считать ли shared memory системным интерфейсом.

Сам по себе кусок общей памяти и интерфейс вобще не обладает системностью в терминах GPL. Системным или нет, будет несвободный код который с ней работает. Если этот код появился и запустился «святым духом» независимо от распространяемого свободного, то он объявляется системным и вопрос закрыт. Если же он распространятся вместе с свободным и даже исключителбго с ним и для него, то читай с начала.

Сам по себе кусок общей памяти и интерфейс вобще не обладает системностью в терминах GPL. Системным или нет, будет несвободный код который с ней работает. Если этот код появился и запустился «святым духом» независимо от распространяемого свободного, то он объявляется системным и вопрос закрыт. Если же он распространятся вместе с свободным и даже исключителбго с ним и для него, то читай с начала.

Все рано есть неоднозначности, ну или я туплю.

Вот например:

1. есть GPL-либа, могу ли я сделать на её основе GPL-прогу? = да.
2. могу ли я из этой проги сделать сервер с соблюдением GPL, принимающий TCP-соединения по сети? = да.
3. могу ли я обращаться к этому серверу из «несвободной проги»? = да?
4. могу ли я отдельно сделать LGPL-либу и модуль ядра, который будет эмулировать интерфейс сокетов через shared momory = да.
5. ВОПРОС: могу ли я обращаться из «несвободной проги» к GPL-серверу через LGPL-эмулятор сокетов в shared memory? = ???