> > > Если Вы не хотите в нем жить, то не пишите ничего под GPL --
> > > делая это, вы работаете против себя.
> > А если приходится делать смешанные проекты?
> > Когда у меня GPL'ed core и non-free гуи и какие-то модули?
> > Где провести грань? Где можно смешивать gpl и non-free а где нет?
> Модуль Вы можете присоединять к GPL'ed core свободно (пример -- ядро). Вы
> можете также линковать GPL-код с не-GPL библиотеками, если они являются
Просто запрещая использование run-time библиотек от
компилаторов/интерпретаторов мы можем прийти к тому что gcc нельзя
использовать для компиляции non-free софта
> > Я ведя эту дисскуссию пытаюсь определиться - как можно открывать большую
> > часть кода под gpl, не внося патентных и иных проблем фирме которая
> > финансирует эти разработки. И не попадая под необходимость открывать код
> > который заказчики требуют сохранять закрытым.
>
> Если заказчик не собирается распространять софт, который Вам заказан, то он
> может быть под GPL. Вы подписываете торжественное обязательство не
> распространять его, а заказчик и так не собирается. GPL есть только
> обязательство открыть код и предоставить свои свободы при передаче
> продукта.
А как квалифицирутся взаимодействие gnu и non-free софта как корба
компонентшов?
То есть немодифицированные GPL продукты или GPL'ed модифицированные...
И внешний GUI который взаимодействует с ними черезь какойто внешний
механизм (corba/expect/socket/etc)?
> Если же заказчик хочет распространять Вашу программу, то Вы сильно
> ограничены в выборе средств разработки.
Собирается - вместе со своим железками (как firmware), но не как
програмный продукт...
И последний вопрос - может ли GPL'ed интерпретатор (librep конкретно)
использоваться для исполнения non-free скриптов/bytecompiled code?
(Как я понял нарушением будет подключение non-gpl интерфейсов как плагинов
этой библиотеки если из них вызываются функции ее рантайма?)
--
With best regards,
Alexander V. Nikolaev
