Можно отказаться только от имущественных прав на разработки, но не от право авторства (это право называть себя автором по сути).
Но полностью чистой схемой в России является схема, когда подобные соглашения заключаются до создания чего либо и где в соглашениях указывается, что собственно необходимо будет создать.
1) Кандидатская диссертация это научно-квалификационная работа, а не научная работа. Квалификационность в том числе указывает на необходимость того, что «10. Диссертация должна быть написана автором самостоятельно, ..., и свидетельствовать о личном вкладе автора диссертации в науку.»
2) Как к.т.н. работающий в том числе и в науке могу сказать, что ваше видение ограничено лишь процессом написания диссертации в Вашем НИИ/вузе. Не зная Вашей темы трудно судить, но в естественно-научных и технических областях такая жесткая индивидуальность — это скорее минус ибо, а как и куда Вы ее внедрять будете (а это обязательное требование), если она не связана с другими работами лаборатории/кафедры?
3) Коллективные исследования это основной формат НИР в РФ. Не важно, госзадание ли это, гранты или коммерческие проекты, индивидуальных среди них доли процента (к сожалению такой публичной статистики по организациям нет, но Вы можете сами посмотреть, хотя бы какие из грантов РФФИ рассчитаны на индивидуальное участие).
А можно показать, на сколько часто серьезные исследования в любой области проводятся в одиночку? Обычно одиночные проекты заканчиваются на уровне выпускной квалификационной работы в вузе. Дальше, даже если у статьи, рассматривающей конкретный аспект работы, один автор, общий проект скорее всего коллективный. И в этом случае я не вижу здесь никакого противоречия.
Совсем не так. Сейчас междисциплинарность исследований в тренде и нередко даже поощряется.
Так же как к тебе будут вопросы если ты пойдешь писать работы по медицине будучи инженером.
Знаю штук 5 исследований, где совместную работу в области медицины вели не только медики, но и физики, математики, инженеры в том числе. И не припомню, чтобы у них были какие-то проблемы в исследованиях и публикациях совместных статей из-за наличия людей без медицинского образования.
Это откуда такой вывод, если даже в статье на РБК уровень зависимости прямо написан:
> Десять крупнейших налогоплательщиков, из которых семь представляют сектор нефтегазодобычи, перечисляют в казну 37,8% всех корпоративных налогов.
А если вычесть эти три компании из других секторов, то навскидку процентов 30-35 максимум будет, что в разы меньше Вашей оценки.
Ну и в топ50 компаний на нефтегаз приходится всего 9 компаний.
Кроме того, распределение налогов по компаниям — это зависимость с длинным хвостом, который содержит столько же платежей, сколько его высокое и короткое начало.
В статье написано, что 50 компаний платят 47% корпоративных налогов, значит остальные 3 958 731 коммерческие компании (из ведущих деятельность по состоянию на ноябрь 2016 года) платят оставшиеся 53%. Так что Ваш вывод противоречит статье, как фактически, так и по методике оценки, использованной Вами.
Да, если есть возможность хранить дополнительные индексы, то это хороший способ.
В нем даже не обязательно переставлять данные реально, если это не требуется, а можно использовать массив перестановок для получения реальных индексов данных.
P.S. Мне кажется или предложенный Вами алгоритм перестановки имеет квадратичную сложность?
Так я тоже не стал сам писать, а выдрал ее из уже не помню какой библиотеки с подходящей лицензией (выдрать сортировку из STL задача скорее нетривиальная из-за стилей написания стандартных библиотек).
Но, чтобы найти подходящую для модификации сортировку все-таки лучше иметь представления о существующих вариантах, чтобы случайно не взять пузырьковую :)
Кстати есть еще ситуации, когда понимание алгоритмов будет полезно. Есть алгоритмы не основанные на сравнениях — поразрядные сортировки (radix sort) и они могут работать за линейное время, что эффективнее традиционных сортировок на сравнениях (правда у них может быть больше константа, по этому на маленьких наборах данных поразрядная сортировка может проигрывать).
По этому, если мы имеем подходящие данные, то зная об этом можно попробовать взять поразрядную сортировку и получить прирост производительности ничего не меняя в основном алгоритме.
Это еще простые случаи. Хуже, когда необходимо переопределять swap.
Обычно, стандартные реализации такого не позволяют, а бывают случаи, когда необходимо сортировать несколько массивов, где ключи в одном массиве, а данные в нескольких других (такой вывернутый на изнанку формат хранения может очень упростить векторизацию кода и дать существенные преимущества по скорости). Общего то итератора у них, понятное дело, нету, как и тривиального swap, поэтому стандартные реализации тут не применимы.
Пожалуй, необходимость сортировки такой структуры — это единственный (из тех, что я помню) случай в моей практике, когда мне пришлось модифицировать код сортировки, а не использовать стандартный std::sort.
> По-моему непонимание происходит из-за того, что вы воспринимаете кафку как очередную message queue.
Не совсем.
На самом деле не обязательно рассматривать сквозную гарантию уровня producer-consumer, чтобы увидеть двойственность возможной трактовки.
Даже если рассмотреть связку producer-кафка отдельно, то возникает двоякая трактовка смысла exactly-once.
Первую описали Вы, а вторая возможная — это сквозной exactly-once для связки producer-кафка. Когда, если producer что-то отправил, то он либо данные у себя удаляет без риска потери, либо перепосылает их пока данные не придут в кафку, но в обоих случая данные приходят в кафку только один раз и producer не тратит лишние ресурсы на хранение у себя тех данных, которые отправлены, успешно доставлены, но подтверждение доставки от которых затерялось. С точки зрения кафки в этом случае exactly-once тоже соблюдается неотличимо от первой трактовки.
А ресурсы для хранения повторно пересылаемых данных на практике могут требоваться значительные и таких лишних ресурсов может просто не быть, а единственным решением проблемы отсутствия такой сквозной гарантии уровня producer-кафка будет ответ от аналитиков, как менее болезненно для целей всей задачи терять сообщения producerа.
> он просто перепошлёт сообщение в кафку с тем же ID и механизм exactly-once гарантирует, что event не будет продублирован.
А тогда понятно. exactly-once получается не сквозной на стыке producer-кафка, а только для кафки, которая всего лишь будет игнорировать дубли по ID за счет какой-либо внутренней «базы» прошедших ID.
С точки зрения producerа получается никакого exactly-once нет, так как он может перепосылать сообщения, которые далее будут отбрасываться, как дубли и в худшем случае будет делать это до бесконечности, так как гарантировано узнать факт доставки он не может.
> Полагаю что вопрос всё же был про consumer-ов.
> Здесь кафка не даёт гарантий exactly-once
Это логично, так как эта гарантия теоретически невозможна в распределенной системе.
Однако, тогда получается, что в статье есть одно обобщение, которое приводит к неправильному ее пониманию:
> Семантика exactly once («строго однократная доставка»).
> Даже при повторной попытке продюсера отправить сообщение, сообщение доставляется строго один раз.
Не указано, что есть доставка и кому оно доставляется. Скорее это утверждение понимается, как доставка конечному потребителю (consumerу) от источника (producerа), так как кафка и ее абстракции это по сути промежуточный буфер, а не часть бизнес логики и не цель доставки/обработки сообщений.
На самом же деле под доставкой понимается только доставка до кафки от источника, что совсем не одно и тоже и что гораздо более слабая гарантия, чем кажется на первый взгляд.
На сайте аэропорта Пулково (https://www.pulkovoairport.ru/passengers/security/customs/) приведены несколько другие сведения:
При вылете: — товары для личного пользования (за исключением этилового спирта и неделимых товаров), перемещаемые воздушным транспортом, таможенная стоимость которых превышает сумму 10 000 евро и (или) общий вес которых превышает 50 кг;
По прибытии: — 4. Товары, не относящиеся к товарам для личного пользования. Декларирование таких товаров производится в общем порядке, установленном для участников внешнеэкономической деятельности.
Те для вылета/прилета граница по сумме уже 10 000 евро и превысить ее ноутбуком и телефоном задача нетривиальная.
Скажите, пожалуйста, как реализация механизма exactly-once в Kafka обходит задачу двух генералов ( https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0_%D0%B4%D0%B2%D1%83%D1%85_%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D0%BE%D0%B2 ), которая неизбежно возникнет, если, например, ненадежна сеть? Или накладываются дополнительные требования к системе?
Как Kafka различит ситуации, что клиент умер до обработки сообщения и сообщение нужно переотправить и ситуацию, когда клиент обработал сообщение и умер в момент отправки подтверждения обработки, следовательно сообщение переотправлять нельзя? В обоих случаях Kafka уведомления не получает, но в одном случае для гарантии exactly-once сообщение необходимо отправить повторно, а в другом нет.
> GPL запрещает делать закрытое приложение с открытыми библиотеками. Об обратном GPL ничего не говорит.
GPL не разделяет приложение и библиотеки, а оперирует понятием «Corresponding Source»: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. (обратите внимание на «run the object code»).
Особенно обратите внимание на часть: For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
А дальше пошли обязанности:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
Как я смогу распространять Corresponding Source дальше на условиях GPL, если в него входит «dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work», а эта самая dynamically linked subprograms имеет закрытый код?
> Так у вас есть библиотека или нет?
Да.
> Можно сделать как в Qt и работу с библиотекой сделать через плагин.
С библиотекой, которая всю математику ядра приложения считает? Ну ну…
Но даже плагин меня не спасет от запрета на распространение измененного кода…
Еще раз.
GPL не позволяет линковаться с зависимостями, которые распространяются под не совместимыми с GPL лицензиями.
Всегда не позволяет. Без исключений. Для libstdc++ отдельное runtime exception пришлось добавлять к лицензии, чтобы ее можно было с закрытым кодом линьковать не смотря на GPL.
Если Вы знаете о существовании исключений, позволяющих линьковать GPL и закрытый код, то прямо укажите пункт GPL, который позволит линьковать GPL код и закрытый код.
LGPL или MIT/BSD/Apache позволяют линьковать открытый и закрытый код. Вот чем они помогут в данной ситуации. Я смогу легально скачать LGPL код зависящий от закрытого кода, использовать его, доработать его и, что самое главное, открыть миру свои изменения под LGPL не нарушив ее! И при этом у меня не будет обязанности открыть под GPL зависимости — те этот краеугольный закрытый код, которого у меня даже и нету, только готовая библиотека.
И еще, скачайте, пожалуйста, демо версию коммерческой поставки Qt и opensource версию Qt и посмотрите на драйвера к базам данных в модуле QtSQL. Вы обнаружите, что OpenSource Qt не содержит драйверов к закрытым базам данных, а если вы посмотрите в документацию к Qt, то там написано, что часть драйверов отсутствуют в открытой Qt из-за несовместимости проприетарного кода и GPL. Те ситуация один в один, как я и описываю.
И да, минусы ставить куда проще, чем привести пункт GPL, который разрешает линьковать закрытый и GPL код, что сразу бы прекратило спор, но я такого пункта там не видел…
А закрытый код — это данность, от которой не уйти. Intel MKL, Intel IPP, тот же IMSL с которым правда работать не доводилось — это закрытый код, у которого и близких OpenSource конкурентов по производительности нету.
> А где GPL мне как автору кода запрещает линковаться с закрытой библиотекой?
У автора кода все хорошо. Он в любом случае не обременен какой-либо лицензией на свой код, но находится он далеко за океаном и это не я.
> Вирусность заключается в использовании gpl библиотеки с не gpl приложением.
И наоборот. GPL в этом отношении симметрична. А у меня по условиям GPL есть обязанность и зависимости GPL совместимые использовать. А я не могу так делать, так как они проприетарные.
> Если человек получил такую программу, то у него уже есть эта библиотека в том или ином виде.
Конечно же нету! Человек получил эту программу в виде набора исходников, скаченных с SF много лет назад. Понятно, что в этом наборе исходников коммерческой библиотеки нет.
> Почему он не может пересобрать GPL код и слинковаться с тем же экземпляром библиотеки?
Ровно потому, что распространять это даже в исходниках не нарушив GPL будет невозможно. Более того, у меня есть подозрение, что и использование может GPL нарушать.
> Можно библиотеку подгружать в рантайме и тогда всё будет чисто.
Это ни на что не повлияет, так как библиотека является необъемлемым компонентом. Без нее не будет работать основная логика.
Получается вы считаете, что GPL позволяет линьковаться с закрытым кодом без нарушения GPL и без распространения GPL на закрытый код? Если это так, то в чем же тогда вирусность GPL?
Мне кажется, что Вы путаете GPL и LGPL, в которой сказанное вами разрешено.
Вы упорно игнорируете тот факт, что неотъемлемым компонентом обсуждаемой программы является проприетарный код, распространять который под GPL невозможно.
Какую проприетарную библиотеку в своем ядре использует GNOME? Если брать то ПО, про которое я говорю, то для его использования/запуска/компиляции требовалась библиотека стоимостью ЕМНИП порядка 1000$ в ценах 5-6 летней давности.
Теперь пойдем с конца. Пусть я доработал эту программу и хочу распространять форк. По условиям GPL я должен и зависимости под GPL распространять, но код использует коммерческую библиотеку, делая такое распространение невозможным.
Аналогичную логику можно применить и к оригинальному автору, те возникает вопрос, могу ли я вообще легально использовать эту программу на условиях GPL.
У GNOME все зависимости либо под GPL либо под совместимыми лицензиями, те которые могут автоматически перелицензироваться под GPL при их использовании.
Хуже то, что многие не понимают возможности и ограничения, которые накладываются GPL и по этому данная лицензия может использоваться как наиболее популярная, а не наиболее подходящая.
Из практики — есть в интернете приложение под GPL (сейчас уже очень давно не развивающиеся), которое для своей работы требует одну исключительно закрытую и сильно платную библиотеку. Без этой библиотеки работать ничего не будет, так как она используется в основных алгоритмах.
Вот вопрос, да, приложение под GPL, но фактически им пользоваться нельзя даже если сильно платная библиотека у вас куплена.
Даже если пользоваться им подпольно у себя, то сделать форк и выложить его уже не получится, будет мешать хвост коммерческой библиотеки (ее то под GPL вы не выложите, а надо, так как GPL вирусная).
А будь приложение под LGPL или MIT/BSD/Apache, то таких проблем бы не было, но GPL банально известнее и для человека, который в лицензиях разбираться не хочет куда проще поставить шильдик GPL.
Но полностью чистой схемой в России является схема, когда подобные соглашения заключаются до создания чего либо и где в соглашениях указывается, что собственно необходимо будет создать.
2) Как к.т.н. работающий в том числе и в науке могу сказать, что ваше видение ограничено лишь процессом написания диссертации в Вашем НИИ/вузе. Не зная Вашей темы трудно судить, но в естественно-научных и технических областях такая жесткая индивидуальность — это скорее минус ибо, а как и куда Вы ее внедрять будете (а это обязательное требование), если она не связана с другими работами лаборатории/кафедры?
3) Коллективные исследования это основной формат НИР в РФ. Не важно, госзадание ли это, гранты или коммерческие проекты, индивидуальных среди них доли процента (к сожалению такой публичной статистики по организациям нет, но Вы можете сами посмотреть, хотя бы какие из грантов РФФИ рассчитаны на индивидуальное участие).
Совсем не так. Сейчас междисциплинарность исследований в тренде и нередко даже поощряется.
Знаю штук 5 исследований, где совместную работу в области медицины вели не только медики, но и физики, математики, инженеры в том числе. И не припомню, чтобы у них были какие-то проблемы в исследованиях и публикациях совместных статей из-за наличия людей без медицинского образования.
dnssec-debugger.verisignlabs.com/fedoraproject.org
И найденный в гугле сервис, который проверяет использует ли Ваш DNS-резолвер DNSSEC: dnssec.vs.uni-due.de
У меня на DNS сервере, который использует DNSSEC, fedoraproject.org сломан, а на сервере, где его проверка отключена, сайт открывается без проблем.
Если Ваш DNS сервер его проверяет, то увы, домен не отрезолвится.
> Десять крупнейших налогоплательщиков, из которых семь представляют сектор нефтегазодобычи, перечисляют в казну 37,8% всех корпоративных налогов.
А если вычесть эти три компании из других секторов, то навскидку процентов 30-35 максимум будет, что в разы меньше Вашей оценки.
Ну и в топ50 компаний на нефтегаз приходится всего 9 компаний.
Кроме того, распределение налогов по компаниям — это зависимость с длинным хвостом, который содержит столько же платежей, сколько его высокое и короткое начало.
В статье написано, что 50 компаний платят 47% корпоративных налогов, значит остальные 3 958 731 коммерческие компании (из ведущих деятельность по состоянию на ноябрь 2016 года) платят оставшиеся 53%. Так что Ваш вывод противоречит статье, как фактически, так и по методике оценки, использованной Вами.
В нем даже не обязательно переставлять данные реально, если это не требуется, а можно использовать массив перестановок для получения реальных индексов данных.
P.S. Мне кажется или предложенный Вами алгоритм перестановки имеет квадратичную сложность?
Но, чтобы найти подходящую для модификации сортировку все-таки лучше иметь представления о существующих вариантах, чтобы случайно не взять пузырьковую :)
Кстати есть еще ситуации, когда понимание алгоритмов будет полезно. Есть алгоритмы не основанные на сравнениях — поразрядные сортировки (radix sort) и они могут работать за линейное время, что эффективнее традиционных сортировок на сравнениях (правда у них может быть больше константа, по этому на маленьких наборах данных поразрядная сортировка может проигрывать).
По этому, если мы имеем подходящие данные, то зная об этом можно попробовать взять поразрядную сортировку и получить прирост производительности ничего не меняя в основном алгоритме.
Обычно, стандартные реализации такого не позволяют, а бывают случаи, когда необходимо сортировать несколько массивов, где ключи в одном массиве, а данные в нескольких других (такой вывернутый на изнанку формат хранения может очень упростить векторизацию кода и дать существенные преимущества по скорости). Общего то итератора у них, понятное дело, нету, как и тривиального swap, поэтому стандартные реализации тут не применимы.
Пожалуй, необходимость сортировки такой структуры — это единственный (из тех, что я помню) случай в моей практике, когда мне пришлось модифицировать код сортировки, а не использовать стандартный std::sort.
> По-моему непонимание происходит из-за того, что вы воспринимаете кафку как очередную message queue.
Не совсем.
На самом деле не обязательно рассматривать сквозную гарантию уровня producer-consumer, чтобы увидеть двойственность возможной трактовки.
Даже если рассмотреть связку producer-кафка отдельно, то возникает двоякая трактовка смысла exactly-once.
Первую описали Вы, а вторая возможная — это сквозной exactly-once для связки producer-кафка. Когда, если producer что-то отправил, то он либо данные у себя удаляет без риска потери, либо перепосылает их пока данные не придут в кафку, но в обоих случая данные приходят в кафку только один раз и producer не тратит лишние ресурсы на хранение у себя тех данных, которые отправлены, успешно доставлены, но подтверждение доставки от которых затерялось. С точки зрения кафки в этом случае exactly-once тоже соблюдается неотличимо от первой трактовки.
А ресурсы для хранения повторно пересылаемых данных на практике могут требоваться значительные и таких лишних ресурсов может просто не быть, а единственным решением проблемы отсутствия такой сквозной гарантии уровня producer-кафка будет ответ от аналитиков, как менее болезненно для целей всей задачи терять сообщения producerа.
> он просто перепошлёт сообщение в кафку с тем же ID и механизм exactly-once гарантирует, что event не будет продублирован.
А тогда понятно. exactly-once получается не сквозной на стыке producer-кафка, а только для кафки, которая всего лишь будет игнорировать дубли по ID за счет какой-либо внутренней «базы» прошедших ID.
С точки зрения producerа получается никакого exactly-once нет, так как он может перепосылать сообщения, которые далее будут отбрасываться, как дубли и в худшем случае будет делать это до бесконечности, так как гарантировано узнать факт доставки он не может.
> Полагаю что вопрос всё же был про consumer-ов.
> Здесь кафка не даёт гарантий exactly-once
Это логично, так как эта гарантия теоретически невозможна в распределенной системе.
Однако, тогда получается, что в статье есть одно обобщение, которое приводит к неправильному ее пониманию:
> Семантика exactly once («строго однократная доставка»).
> Даже при повторной попытке продюсера отправить сообщение, сообщение доставляется строго один раз.
Не указано, что есть доставка и кому оно доставляется. Скорее это утверждение понимается, как доставка конечному потребителю (consumerу) от источника (producerа), так как кафка и ее абстракции это по сути промежуточный буфер, а не часть бизнес логики и не цель доставки/обработки сообщений.
На самом же деле под доставкой понимается только доставка до кафки от источника, что совсем не одно и тоже и что гораздо более слабая гарантия, чем кажется на первый взгляд.
При вылете: — товары для личного пользования (за исключением этилового спирта и неделимых товаров), перемещаемые воздушным транспортом, таможенная стоимость которых превышает сумму 10 000 евро и (или) общий вес которых превышает 50 кг;
По прибытии: — 4. Товары, не относящиеся к товарам для личного пользования. Декларирование таких товаров производится в общем порядке, установленном для участников внешнеэкономической деятельности.
Те для вылета/прилета граница по сумме уже 10 000 евро и превысить ее ноутбуком и телефоном задача нетривиальная.
Как Kafka различит ситуации, что клиент умер до обработки сообщения и сообщение нужно переотправить и ситуацию, когда клиент обработал сообщение и умер в момент отправки подтверждения обработки, следовательно сообщение переотправлять нельзя? В обоих случаях Kafka уведомления не получает, но в одном случае для гарантии exactly-once сообщение необходимо отправить повторно, а в другом нет.
GPL не разделяет приложение и библиотеки, а оперирует понятием «Corresponding Source»: The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. (обратите внимание на «run the object code»).
Особенно обратите внимание на часть: For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
А дальше пошли обязанности:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
Как я смогу распространять Corresponding Source дальше на условиях GPL, если в него входит «dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work», а эта самая dynamically linked subprograms имеет закрытый код?
> Так у вас есть библиотека или нет?
Да.
> Можно сделать как в Qt и работу с библиотекой сделать через плагин.
С библиотекой, которая всю математику ядра приложения считает? Ну ну…
Но даже плагин меня не спасет от запрета на распространение измененного кода…
GPL не позволяет линковаться с зависимостями, которые распространяются под не совместимыми с GPL лицензиями.
Всегда не позволяет. Без исключений. Для libstdc++ отдельное runtime exception пришлось добавлять к лицензии, чтобы ее можно было с закрытым кодом линьковать не смотря на GPL.
Если Вы знаете о существовании исключений, позволяющих линьковать GPL и закрытый код, то прямо укажите пункт GPL, который позволит линьковать GPL код и закрытый код.
LGPL или MIT/BSD/Apache позволяют линьковать открытый и закрытый код. Вот чем они помогут в данной ситуации. Я смогу легально скачать LGPL код зависящий от закрытого кода, использовать его, доработать его и, что самое главное, открыть миру свои изменения под LGPL не нарушив ее! И при этом у меня не будет обязанности открыть под GPL зависимости — те этот краеугольный закрытый код, которого у меня даже и нету, только готовая библиотека.
И еще, скачайте, пожалуйста, демо версию коммерческой поставки Qt и opensource версию Qt и посмотрите на драйвера к базам данных в модуле QtSQL. Вы обнаружите, что OpenSource Qt не содержит драйверов к закрытым базам данных, а если вы посмотрите в документацию к Qt, то там написано, что часть драйверов отсутствуют в открытой Qt из-за несовместимости проприетарного кода и GPL. Те ситуация один в один, как я и описываю.
И да, минусы ставить куда проще, чем привести пункт GPL, который разрешает линьковать закрытый и GPL код, что сразу бы прекратило спор, но я такого пункта там не видел…
А закрытый код — это данность, от которой не уйти. Intel MKL, Intel IPP, тот же IMSL с которым правда работать не доводилось — это закрытый код, у которого и близких OpenSource конкурентов по производительности нету.
У автора кода все хорошо. Он в любом случае не обременен какой-либо лицензией на свой код, но находится он далеко за океаном и это не я.
> Вирусность заключается в использовании gpl библиотеки с не gpl приложением.
И наоборот. GPL в этом отношении симметрична. А у меня по условиям GPL есть обязанность и зависимости GPL совместимые использовать. А я не могу так делать, так как они проприетарные.
> Если человек получил такую программу, то у него уже есть эта библиотека в том или ином виде.
Конечно же нету! Человек получил эту программу в виде набора исходников, скаченных с SF много лет назад. Понятно, что в этом наборе исходников коммерческой библиотеки нет.
> Почему он не может пересобрать GPL код и слинковаться с тем же экземпляром библиотеки?
Ровно потому, что распространять это даже в исходниках не нарушив GPL будет невозможно. Более того, у меня есть подозрение, что и использование может GPL нарушать.
> Можно библиотеку подгружать в рантайме и тогда всё будет чисто.
Это ни на что не повлияет, так как библиотека является необъемлемым компонентом. Без нее не будет работать основная логика.
Мне кажется, что Вы путаете GPL и LGPL, в которой сказанное вами разрешено.
Вы упорно игнорируете тот факт, что неотъемлемым компонентом обсуждаемой программы является проприетарный код, распространять который под GPL невозможно.
Теперь пойдем с конца. Пусть я доработал эту программу и хочу распространять форк. По условиям GPL я должен и зависимости под GPL распространять, но код использует коммерческую библиотеку, делая такое распространение невозможным.
Аналогичную логику можно применить и к оригинальному автору, те возникает вопрос, могу ли я вообще легально использовать эту программу на условиях GPL.
У GNOME все зависимости либо под GPL либо под совместимыми лицензиями, те которые могут автоматически перелицензироваться под GPL при их использовании.
Из практики — есть в интернете приложение под GPL (сейчас уже очень давно не развивающиеся), которое для своей работы требует одну исключительно закрытую и сильно платную библиотеку. Без этой библиотеки работать ничего не будет, так как она используется в основных алгоритмах.
Вот вопрос, да, приложение под GPL, но фактически им пользоваться нельзя даже если сильно платная библиотека у вас куплена.
Даже если пользоваться им подпольно у себя, то сделать форк и выложить его уже не получится, будет мешать хвост коммерческой библиотеки (ее то под GPL вы не выложите, а надо, так как GPL вирусная).
А будь приложение под LGPL или MIT/BSD/Apache, то таких проблем бы не было, но GPL банально известнее и для человека, который в лицензиях разбираться не хочет куда проще поставить шильдик GPL.