>для части случаев методы подружить закрытое и открытое придуманы давно - вы
>просто пишете "переходник", т.е. реализуете интерфейс к открытому решению. Дальше ваше
>интерфейсное приложение открывается, как имеющий GPL включения, а основной коммерческий софт
>использует внешние вызовы интерфейса (например, передача данных в поток вызываемому интерфейсному
>приложению и обработка ответа) Перехродник возможен только если ваше приложение не является ИСПОЛЬЗУЮЩИМ GPL код. К примеру закрытые драйвера nVidia не используют ядро. Они выступают "библиотекой". Но как только появится необходимость использовать ядро напрямую - сразу nVidia придется перелицензировать свой код под GPL.
Как можно использовать IoC контейнер под GPL в закрытом коде? или JDBC? если использован GPL, то сразу бизнес получает по лбу от "вирусности".
>конечно это применимо не везде, но вполне себе решение для части задач.
>Есть и другие варианты. ИМХО - вот пример ЧЕСТНОГО использования GPL
>кода, в отличие от "тыренья" и вставки в свои закрытые решения
Тыренье - не рассматриваем. Это не решение.
>поэтому тормоза на пути развития GPL кода зачастую надуманы. Согласитесь, что как
>то несправедливо, когда вы пишите код под BSD лицензией, а какой
>нибудь коммерсант продвигает его как свой продукт (типичный пример - Mac).
Согласен.
>С другой стороны, еси кто то выкладывает код под GPL, то
>это не влечет обязательств для других разработчиков делать то же
>вывод - GPL более справедливая лицензия (чем, например, BSD), и возможности дружить
>закрытый и открытый код вполне есть
Дружить с GPL - сложно. А APL намного проще. Поэтому *рекомендуют* использовать APL для кода.