информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Google прикрыл domain fronting 
 Opera VPN закрывается 
 13 уязвимостей в процессорах AMD 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / law
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Поставьте мне мозг на место: 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 <Denis> Статус: 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:17  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Не очень понятно, как конкретно происходит взаимодействие компонент вашего проекта, но думаю, что исчерпывающий ответ с пояснениями ты найдешь здесь:
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

Могу я выпустить несвободную программу, составленную так, чтобы подгружать внешний модуль под GPL?
Нет там никаких ясных ответов. 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 <Denis> Статус: The Elderman
<"чистая" ссылка>
На сколько я понимаю, нельзя использовать доступ из проприетарной программы напрямую к структурам данных процесса GPLv3. Но если проприетарная программа запрашивает у ОС некоторый блок памяти, который используется как shared memory для обоих процессов и посредством системных вызовов просит процесс GPLv3 поместить в эту память некоторый результат работы в опереденной структуре, то это уже взаимодействие через интерфейс.
Обычный стек, по сути, тоже shared memory. ;)
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2018 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach