Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Ну собственно я тоже с этим согласен, но вот цитата из... 13.04.13 10:47 Число просмотров: 4233
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> ты же не запускаешь из проприетарной проги в этом же
> процессе GPLv3, иными словами - не используешь GPLv3 код
> внутри процесса проприетарной проги (не заимствуешь чужой
> код в бинарном или исходном виде)
Ну собственно я тоже с этим согласен, но вот цитата из GPL-FAQ "Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking".
|
|
<law>
|
Поставьте мне мозг на место: GPLv3 + shared memory 12.04.13 19:03
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 12.04.13 19:08 Количество правок: 1
|
Было:
- есть код под GPLv3 (например вычисления);
- есть еще код под GPLv3 (различный транспорт);
- к этому добавлен main-модуль под GPLv3;
= тут все ясно и понятно, имеем проект под GPLv3.
Стало:
- к указанному GPLv3 проекту добавили код, реализующий транспорт через разделяемую память;
- координаты и формат данных в разделяемой памяти задаются в настройках/опциях, можно считать что работает интерпретатор или компилятор;
- все изменения исходников доступны;
= ну тоже понятно, имеем проект под GPLv3, в который внесены изменения, нарушений нет.
Туплю:
- есть проприетарная прога, которая создает именованный регион разделяемой памяти и производит с ним обмен;
- настройками двух проектов их можно "подружить", таким образом GPLv3 и не-GPL в каком-то смысле объединяются;
= вопрос, это нарушение GPLv3 или нет?
| Да - нарушение, так как происходит частичное объединение в одно адресное пространство.
|  | 0 | (0%) |
| Нет - не нарушение, это взаимодействие "стандартными средствами". | | 2 | (100%) |
| Всего: | | 2 | (100%) |
Для участия в голосовании необходимо зарегистрироваться |
|
ты же не запускаешь из проприетарной проги в этом же... [upd] 13.04.13 06:24
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 13.04.13 06:38 Количество правок: 1
|
ты же не запускаешь из проприетарной проги в этом же процессе GPLv3, иными словами - не используешь GPLv3 код внутри процесса проприетарной проги (не заимствуешь чужой код в бинарном или исходном виде)
Свободное программное обеспечение с точки зрения российского права
|
| |
Ну собственно я тоже с этим согласен, но вот цитата из... 13.04.13 10:47
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> ты же не запускаешь из проприетарной проги в этом же
> процессе GPLv3, иными словами - не используешь GPLv3 код
> внутри процесса проприетарной проги (не заимствуешь чужой
> код в бинарном или исходном виде)
Ну собственно я тоже с этим согласен, но вот цитата из GPL-FAQ "Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking".
|
| | | |
Нет там никаких ясных ответов. 13.04.13 16:55
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Нет там никаких ясных ответов.
Есть две программы GPL и не-GPL, насколько легальны способы их взаимодействия:
1) одна вызывает другую (посредством exec) = ДА
2) через pipe и перенаправление ввода-вывода (write + read) = ДА
3) через сокеты (connect/send/write/read/) = ДА
4) через сокеты с маршалингом (thrift, corba, protobuffers) = ДА
5) через MPI = ДА
6) через MPI с маршалингом (thrift, protobuffers) = ДА
7) через MPI с хранением сообщений в разделяемой памяти = да?
8) через MPI с маршалингом (thrift, protobuffers) и хранением сообщений в разделяемой памяти = нет?
9) с хранением плоских данных в разделяемой памяти = да?
10) через стандартные системные вызовы ядра = ДА
11) с эмуляцией pipe через разделяемую память и фьютексы = нет?
12) через системные вызовы реализованные в модуле ядра = ДА
13) с эмуляцией pipe в разделяемой памяти силами модуля ядра = да?
14) через разделяемую память с маршалингом (thrift, protobuffers) = нет?
15) через MPI с маршалингом (thrift, protobuffers) и хранением сообщений в буфере разделяемой памяти, который предоставил модуль ядра = да?
16) с хранением сообщений сложной структуры в буфере разделяемой памяти, который предоставил модуль ядра = нет?
17) с хранением сообщений сложной структуры, которую определяет драйвер модуль ядра как часть интерфейса, в буфере разделяемой памяти который предоставил модуль ядра = да?
18) с хранением сообщений сложной структуры, которую определяет драйвер модуль ядра как часть интерфейса, в буфере разделяемой памяти который предоставлен одной из сторон = нет?
Короче, копирастия какая-то.
IMHO логичны такие требования:
- должно быть два разных процесса (два pid-а), которые можно запустить независимо через два exec-вызова;
- интерфейс взаимодействия и структура сообщений/данных должна быть открыты (воспроизводимы на основе прилагаемых исходников);
|
| | | | |
На сколько я понимаю, нельзя использовать доступ из... 13.04.13 22:53
Автор: Den <Денис Т.> Статус: The Elderman
|
На сколько я понимаю, нельзя использовать доступ из проприетарной программы напрямую к структурам данных процесса GPLv3. Но если проприетарная программа запрашивает у ОС некоторый блок памяти, который используется как shared memory для обоих процессов и посредством системных вызовов просит процесс GPLv3 поместить в эту память некоторый результат работы в опереденной структуре, то это уже взаимодействие через интерфейс.
Обычный стек, по сути, тоже shared memory. ;)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
