Европейское отделение Фонда свободного ПО опубликовало (http://fsfe.org/news/2010/news-20100719-01.en.html) результаты оценки особенности связывания GPLv2-кода с сторонними проприетарными и открытыми проектами. Документ (https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument) призван упростить разработчикам выбор подходящей для своего продукта лицензии. Рассмотрено динамическое и статическое связывание, межпроцессное взаимодействие (RPC), обращение к системным вызовам, макроподстановки, подключение плагинов и использование интерпретируемых языков.

URL: http://fsfe.org/news/2010/news-20100719-01.en.html
Новость: http://www.opennet.me/opennews/art.shtml?num=27354

• Юридические аспекты связывания GPLv2-проектов и стороннего к...,iZEN, 23:39 , 19-Июл-10
  • Юридические аспекты связывания GPLv2-проектов и стороннего к...,nuclight, 13:24 , 20-Июл-10

Лучше подумать, прежде чем совмещать что-то с чем-то. А иначе можно нарваться на "слоистый" пат с vendor lock-in со стороны коммерческого вендора по отношению к опенсурсу (или наоборот), и тогда совместный проект просто остановится на месте и будет висеть в мёртвых объятиях лицензионных соглашений всю жизнь.

"<...>
только разделение по функционалу обладает высокой сцепленностью, высокой модульностью и низкой степенью связи между пакетам.
<...>
идея разделения кода по функционалу предполагает что один пакет не может использовать объекты, принадлежащие другому пакету. Предпочтительно, область видимости по-умолчанию определять, чтобы объекты были доступны только внутри пакета (package-private), и увеличивать область видимости объектов до public только для тех объектов для которых это необходимо.
<...>
Разработчикам, сопровождающим код, требуется намного меньше действий для поиска объектов, так как все объекты, которые требуются, обычно располагаются в одном папке. Некоторые инструменты, поддерживающие разделение по слоям, используют специальные соглашения о наименовании пакетов, чтобы облегчить навигацию по коду. Однако, при разделении кода по функционалу нет необходимости для подобных соглашений в первую очередь благодаря отсутствию самой необходимости навигации между папками.
<...>
Разбивка по слоям не эффективна и в других областях

По аналогии, видно что разбивка по слоям приводит к плохим результатам. Например, представим автомобиль. На высоком уровне, "реализация" автомобиля делится следующим образом (разбивка по функционалу):

- безопасность;
- двигатель;
- управление;
- система топлива;
- и т.п.

Теперь представим автомобиль реализация которого разделена на низкоуровневые элементы (разбивка по слоям):

- электроника;
- механика;
- гидравлика

В этом случае проблему коробки передач, например, вы можете исправлять во всех трех компонентах. Это означает переход от одной части к другой - совершенно другой части автомобиля. Несмотря на то, что в этих разных частях, вы бы видели элементы совершенно не относящиеся к проблеме которую вы пытаетесь решить. Они просто мешают и постоянно отвлекают от действительной задачи. Было бы проще если бы это было одно место с именно тем что вам требуется и ничем иным?
<...>
По видимому разделение по слоям просто плохая традиция, которую давно пора отменить." © "Package by feature, not layer"

А где там вообще текст документа? И откуда эим цитаты?
Пошел по ссылке, на первой странице не нашел, на второй не нашел и забил.