Вот когда в ваших темах не будет вызовов функций WP, тогда и делайте любую лицензию, а в темах Thesis, как ясно из топика вызовы GPL-кода движка есть и они не заменены на собственный коммерческий код.
с точки зрения программной логики, модули и темы WP (и Drupal) это куски кода, которые включаются внутрь GPL-кода движка и исполняются в едином потоке выполнения программы. Модули и темы WP не могут быть исполнены иным образом и специально созданы с включением кучи вызовов подпрограмм самого WP (так что не надо так категорично заявлять, что нет GPL-кода в них)
В том и загвоздка, что Tesis не снабжает WP своими темами, а только пользуется работой сообщества для легкости создания и распространения собственного коммерческого продукта.
Исходя из такой логики я вообще не могу создать закрытую прогу под ОС Linux, потому что прога эта по-любому будет работать в окружении ОС
Это не так. Просто ваша программа не должна содержать GPL-кода. Или покупайте коммерческие/BSD библиотеки, или пишите их сами вместе с остальным своим кодом.
Права разработчиков в контексте ваших слов ущемляет их собственная лень. Каждый имеет 100% право только на принадлежащий ему код. Код модулей и тем не имеет смысла без самого движка, а использовать движок можно только под GPL. Таким образом у разработчиков есть право только либо писать свое под GPL, либо покупать коммерческий движок, либо писать 100% кода движка, модулей и тем.
Советую спросить у разработчиков под WP как реализован механизм взаимодействия движка с модулями и темами, а не рассуждать абстрактно. Они вам ответят то же самое, что написано в топике — тема и модуль исполняются в контексте движка, а не через периферийное API. Это и создает лицензионную коллизию. Не будь в этом конкретном случае такого плотного взаимодействия кодов, я бы тоже был на вашей стороне.
Разработчикам WP от этого ни холодно ни жарко. Они в любом случае не участвуют в коммерческой схеме Thesis, так зачем заботиться о спросе на чужой коммерческий продукт?
Нет, согласие разработчиков это ключевой вопрос. Они разрешили добавлять к своему коду другой код и на этом начали зарабатывать такие как Thesis. Но коммерсанты решили не исполнять ту часть лицензии, которая им не понравилась. В таких условиях они обязаны либо разрешить распространение кода своими покупателями, либо отказаться от взаимодействия с WP, то есть полностью лишить смысла свой продукт.
Это не так. Вы делаете сайт взяв за основу движок под GPL, вносите в него модификацию модулями и темами (это главный нюанс данного конфликта, который вы и не поняли), продаете получившийся продукт, в нарушение лицензии на его часть. WP выступает для модулей и тем библиотекой, а согласно GPL (и в отличие от LGPL) код, использующий такую библиотеку сам обязан быть под GPL.
Вот по отношению к другим продуктам модули часто не попадут в такую коллизию. Например, если модуль работает через внешний (!) API. Но это совершенно другая ситуация — коммерческая компания пытается заработать на нарушении GPL. Как она должна поступить правильно в подобном случае? Например написать собственный, полностью коммерческий движок с api WP и продавать его под коммерческой лицензией вместе со своими темами. Тогда 100% кода будет под их лицензионным контролем, как у того же Битрикса.
конкретно модули и темы WP исполняются как инструкции для внутренних механизмов этого движка и определяют его поведение далеко за пределами внешних рюшечек, вроде css и javascript. Нет сомнений, что любой модуль wp это модификация основного движка. Просто у движка есть механизмы для удобной модификации. Это не имеет ничего общего с работой по внешнему API
А вы будьте честны с этим заказчиком. Вы взяли часть чужого кода, который не имеете права закрывать и продали вместе со своим кодом, лишив заказчика права продавать конечный продукт под закрытой лицензией. Кстати раздавать код GPL не требование. Требование в том, чтобы тот, кому вы его дали/продали имел исходный код для последующих модификаций без вашей помощи. Это совсем не то же что «раздать всему интернету»
не переходит. GPL однозначно разрешает использовать код, модифицировать и включать в состав собственного продукта. Только на условиях такого же разрешения для других. Деньги вообще в этой схеме не участвуют — можешь продавать свой продукт с GPL-вставками, но не забудь предоставить исходный код для возможных улучшений.
еще как должен. хочешь полной независимости от GPL — пиши весь код сам или пользуйся коммерческими библиотеками. Под линуксом такая независимость равносильна самоубийству — у GPL-разработчиков до 90% кода уже написано сообществом.
Струйники изначально пользуются стохастическим, а не амплитудным растрированием. Детализация краев при этом способе может достигать половины разрешения принтера. Разумеется 300dpi принтера это не много, но при классическом амплитудном растрировании картинка была бы намного хуже.
Среднее разрешение у печати 300 dpi — это сродни монитору с 25 dpi :)
1. Это не так. И точка монитора имеет 32 бита оттенков и точка исходного изображения. Так что соотношение между ними 1:1
Так вот хорошая печать получается с 200lpi и выше.
Линеатура более 200 не имеет смысла. Там, где требуется такая проработка используется стохастическое растрирование. На практике мало кто печатает более 150 — ведь это существенно усложняет настройку станков для качественной цветопередачи. Редко какой печатный цех может гарантировать точную цветопередачу при линеатуре выше 175.
минимально необходимое для изображений, но выводиться на фотонабор они все равно будут с 2400+ dpi
Фотонаборы с 2400 dpi это не серьезно. Не смотря на математическую достаточность, на практике минимум двукратный запас разрешения желателен для выравнимания краев красочного пятна, ведь это пятно редко имеет круглую форму и проще всего печатникам «удержать» цвет при других формах — например больше всего распространен овал.
Эта путаница многих сбивает с толку
Уверяю вас — в этом может запутаться только невежда. Разобраться с этим можно за час.
Если я правильно понял под разрешением вы имеете в виду dpi исходного полноцветного растра, а не dpi фотонабора (про который вам уже ответили). Дело в том, что амплитудное растрирование требует создания матрицы таких кластеров, как указано на иллюстрации выше. Но между рядами исходного изображения и тонального растра есть расхождение по углу наклона. Это расхождение есть всегда, вне зависимости от того, как вы повернете цифровую картинку. Потому, что для печати обычной триадой (CMYK) приходится накладывать тональные растровые сетки друг на дружку. Если они будут иметь близкий угол наклона, то результирующее изображение будет покрыто муаром. Чтобы избежать этого нежелательного эффекта сетки всех цветов поворачивают относительно друг друга. Теоретически желтая краска имеет наклон сетки 0, голубая и пурпурная по +15 и -15 градусов, а черная — 45. Но как бы там ни было на практике, худшее соотношение сеток по отношению к исходному изображению соответствует 45 градусов. Если представить себе это графически, то пиксель исходного изображения это катет условного прямоугольного треугольника, а кластер тонального растра (lpi) это его гипотенуза. таким образом худшее соотношение между ними это по теореме Пифагора — корень из двух. вот вам и 1.41
Это не так. Просто ваша программа не должна содержать GPL-кода. Или покупайте коммерческие/BSD библиотеки, или пишите их сами вместе с остальным своим кодом.
Вот по отношению к другим продуктам модули часто не попадут в такую коллизию. Например, если модуль работает через внешний (!) API. Но это совершенно другая ситуация — коммерческая компания пытается заработать на нарушении GPL. Как она должна поступить правильно в подобном случае? Например написать собственный, полностью коммерческий движок с api WP и продавать его под коммерческой лицензией вместе со своими темами. Тогда 100% кода будет под их лицензионным контролем, как у того же Битрикса.
1. Это не так. И точка монитора имеет 32 бита оттенков и точка исходного изображения. Так что соотношение между ними 1:1
Линеатура более 200 не имеет смысла. Там, где требуется такая проработка используется стохастическое растрирование. На практике мало кто печатает более 150 — ведь это существенно усложняет настройку станков для качественной цветопередачи. Редко какой печатный цех может гарантировать точную цветопередачу при линеатуре выше 175.
Фотонаборы с 2400 dpi это не серьезно. Не смотря на математическую достаточность, на практике минимум двукратный запас разрешения желателен для выравнимания краев красочного пятна, ведь это пятно редко имеет круглую форму и проще всего печатникам «удержать» цвет при других формах — например больше всего распространен овал.
Уверяю вас — в этом может запутаться только невежда. Разобраться с этим можно за час.