Комментарии 43
Почему не попробовать?
Я могу ошибаться, но вроде бы все лицензии подразумевают необходимость предоставления кода только непосредственным пользователям продукта. Если вы не используете продукт - вы немножко в пролёте. Бесплатные проекты открывают код по-умолчанию потому что круг их пользователей теоретически неограничен. А платные/закрытые имеют право открывать код только своим подтверждённым пользователям. Пример - Red Hat. Вы не можете просто так посмотреть исходники их версии ядра Linux, вам нужно регистрироваться хотя бы для бесплатной версии для разработчиков.
Поскольку Home Credit Bank использует вашу модель во внутреннем продукте, вам надо сначала устроиться к ним в техподдержку или админом (чтоб стать пользователем этого продукта), а потом уже требовать исходники.
Но попробовать, конечно, стоит.
Тут ответ наверное аналогичный соседней ветке, вот смотрите, что Google думает на эту тему - https://opensource.google/documentation/reference/using/agpl-policy
AGPL Policy
WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.
The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.
The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed. Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.
Do not attempt to check AGPL-licensed code into google3 or use it in a Google product in any way.
Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office.
In some cases, we may have alternative licenses available for AGPL licensed code.
я конечно не спец. Но они не предоставляют сервис как SaaS (главная фишка AGPL) и не распространяют софт. Сама компания использует софт внутри себя (сам себе юзер), т.е нет 3 лица. Выглядит как будто ничего плохого они не делают.
Ну не знаю. Вот смотрите, что Google думает на эту тему: https://opensource.google/documentation/reference/using/agpl-policy
AGPL Policy
WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.
The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.
The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed. Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.
Do not attempt to check AGPL-licensed code into google3 or use it in a Google product in any way.
Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office.
In some cases, we may have alternative licenses available for AGPL licensed code.
Когда я общался с американскими заказчиками, они боятся ее как огня ...
Когда я общался с американскими заказчиками, они боятся ее как огня ...
Думаю сравнивать американскую юридическую систему и нашу имеет мало смысла. Например если вы начнете судиться, то судье скорее всего будет не важно то, что думает гугл(вероятно большинство судей даже не знают про эти лицензии). Ну а в целом, защита может на самом деле отталкиваться от того, что они должны предоставить исходники, только конечным пользователям, и т.к. это внутренний продукт, то и предоставить они должны его только сотрудникам по сути.
Совершенно верно. Гугл думает так ровно по одной причине — им нельзя добавлять код с такой лицензией в проекты, доступные пользователям ("Search, Gmail, Maps, YouTube"). Чтобы такой код точно не попадал в них — они и исключили AGPL полностью.
Если банк использует вашу библиотеку для внутренних целей (и это недоступно обычным клиентам) — это их полное право.
Хорошие примеры agpl, grafana. Очень популярный тул для визуализации . Видели что всех юзеров засудили? Почти в каждой большой компании поднят хотябы один инстанс. Ну или вспомнить хотябы mongodb, которая раньше тоже была под agpl, вы точно про неё слышали и наверно даже юзали, вас судили?
Я сам ворюсь в ентерпайзе, читаю эти лицензии каждый день… такое себе удовольствие
Ворюсь
А если без шуток, вы часто видите когда американская компания продает в суд на компании из России?
Как много людей используют графану или монгу напрямую в своем коде? AGPL не требует ничего публиковать, если просто используется бинарник as-is.
Вот если бы драйвер монги был agpl, тут, вероятно, была бы проблема
Как использовать (A)GPL библиотеку? Берем Flask или подобный фреймворк и нужные методы библиотеки выносим на контроллер. В результате, проприетарный код, который вызывает методы из такого вебсервера, остается проприетарным без конфликта лицензий.
Делали ли так разработчики из Home Credit - не знаю.
Банки вообще очень редко что-то публикуют. Насколько понимаю фишка AGPL лицензии в ее "виральности".
The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.
не понимаю, чем она «виральнее» обычной gpl
Обычная GPL распространяется на случаи, когда пользователь получает копию ПО любым законным способом: покупает, скачивает с официального сайта, приобретает физическое устройство с программой в прошивке... Такой пользователь имеет право запросить у производителя исходный код производного продукта с внесенными производителем изменениями и далее может распоряжаться этим кодом на тех же GPL условиях. Но ситуация, когда пользователь взаимодействует с программой на сервере, сюда не входит. Пользователь не получил собственно программу, а лишь работает с неким удаленным сервисом, и производитель не обязан предоставлять пользователю исходный код.
AGPL исправляет как раз этот момент: пользуешься AGPL программой на сервере - значит имеешь право получить исходный код сервиса, производного от AGPL.
я с этим не спорю, но причём тут виральность (способность «заражать» сторонний код)?
ниже привели такое толкование: пока внешние пользователи не работают непосредственно с AGPL-приложением, никаких дополнительных ограничений AGPL в сравнении с GPL не накладывает.
а, если не секрет, сколько стоит коммерческая лицензия??
И почему то я думал, что банки более щепетильно относятся к таким вопросам. А уж если дело дошло до публикации статьи в корпоративном блоге, тем более..
Как посторонний человек хочется вам сказать: конечно ввязывайтесь в это дело, заодно и нам потом расскажете.. Но, не знаю, не знаю...
Как заядлый оптимист скажу: а вдруг вам попадутся честные люди, и всё будет не так страшно..
В любом случае желаю удачи вам и вашему проекту.
а, если не секрет, сколько стоит коммерческая лицензия??
Мы обычно делаем КП каждому B2B заказчику персонально. Но у нас чеки такого уровня, что для банка это вообще даже не является погрешностью.
Как заядлый оптимист скажу: а вдруг вам попадутся честные люди, и всё будет не так страшно..
Естественно, я не удержался от повода мягко потроллить банк под их статьей, но я конечно сразу предложил им опцию дружественного урегулирования.
Посмотрим и будем надеяться на их благоразумие.
уж не знаю получится ли их наказать, но оппытаться надо обязательно. довольно печально что в снг многим просто насрать на открытые лицензии. такое ощущение что на весь банк не нашлось ни одного человека с мозгами способного подумать "хм, а ведь у этого проекта есть лицензия, пойду почитаю что она обязывает а что запрещает". встаёт вопрос а стоит ли доверять ценные бумаги банку который так наплевательски относится к куда более "ценным" "бумагам"..
Я бы конечно пошутил про иностранный капитал ... но некоторые отечественные банки тоже совсем не радуют.
И как бы я не Хабре не иронизировал насчет национализации Сбербанка из ФНБ, но ... сотрудники банка на местах стали активно помогать обходить "тупики" в их системе креативными способами.
А насчет лицензий - они наверное просто даже не смотрят.
сотрудники сбербанка до сих пор не догадались рассказать руководству что кнопочку включения СБП не надо прятать в недра программы а надо вывести в самый верх настроек.
сотрудники банков до сих пор не догадались что банк клиент это не инстаграмм и нефиг туда пихасть сториз..
сотрудники банка выводят ботов помошников в приоритет перед "живой" поддержкой ДО того как протестируют а может ли это чудо ответить хоть на один вопрос..
исходя из вышесказанного единственная причина почему они "даже не смотрят" лицензии это отсутствие разума..
Или безразличие.
Тут безразличие уже следствие отсутствия разума.
Проблема банков ещё в том что там обычно рядовые сотрудники никак не могут повлиять на решение вышестоящих как бы не били себя пяткой в грудь..
Если опустить 10 логических переходов, то можно сразу перейти к известной цитате про капитализм и 300% прибыли.
Всё дело не в безразличии и не в том, что руководство не знает о кнопочке СБП, а как раз является следствием действий топ-менеджмена. Если помните, Сбер - единственный банк, отказывавшийся вводить СБП, так как комиссия за переводы составляла в районе 30% от общего пирога переводов других банков. Так что судите сами, нужно ли банку платить денежки и читать лицензии, если денежки можно не платить и лицензии не ЧИТАТЬ))
сотрудники сбербанка до сих пор не догадались рассказать руководству что кнопочку включения СБП не надо прятать в недра программы а надо вывести в самый верх настроек
Чтобы банк терял доход от комиссии за перевод? По-моему очевидно, что это сделано специально.
то что это очевидно ничего не меняет
ещё как меняет, у кучи людей сбп в сбербанке не подключен, и при попытке объяснить как подключить получаешь ответ «сложно»
И насколько я помню, спб нельзя было подключить через web версию. Только через приложение. И причём это было не только с спб, а и с другими "мелкими" фишками. Например нельзя было выбрать карту по умолчанию.
Надеюсь сейчас, когда их приложение выпилили из маркетов, они возьутся за допиливание web сервиса. Наконец то.
сотрудники сбербанка до сих пор не догадались рассказать руководству что кнопочку включения СБП не надо прятать в недра программы
Думаю давно догадались, но 50 рублей комиссии это 50 рублей комиссии.
Ну в цивилизованых странах, сперва пытаются решить дело внесудебным образом. Например обратиться в юридический отдел банка, чтобы прояснить этот вопрос.
Как я понял, банк использует модель в своих внутренних процессах. Для обработки транскрибированого текста из записей телефонных разговоров. Модифицированое ПО тут не распространяется, а используется внутри компании. У него нет как таковых пользователей. Кому предоставлять источники? Вот похожий вопрос на SО.
Тут вроде речь про GPL, а не AGPL.
Ключевая разница у них, как я понял, только в том, что сетевые сервисы основаные на "свободном" ПО, тоже считаются распространением. Поэтому для вопроса не критично. Вопрос: является ли внутрикорпоративное использование AGPLv3 ПО - распространением. И как я понимаю - нет. Вот если бы они начали публичный сервис или продукт разрабатывать на его основе - то да.
Однако, если они разрабатывали это не сами, а, например, у них был подрядчик, который реализовывал эту функцию, то вот подрядчик предоставляя плоды своего труда заказчику, уже бы по сути распространял дериват.
Вот если бы они начали публичный сервис или продукт разрабатывать на его основе - то да.
То есть когда я звоню в банк (и телефон доступен для любой публики), это не является публичным сервисом?
Ключевая разница у них, как я понял, только в том, что сетевые сервисы основаные на "свободном" ПО, тоже считаются распространением.
И в том, что эта лицензия требует аналогичной лицензии и публикации их софта, который этот модуль использует. Она "виральная":
The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license.
То есть когда я звоню в банк (и телефон доступен для любой публики), это не является публичным сервисом?
А вот тут вопрос - что входит в этот самый сервис? Использует ли тот, кто звонит в банк, результат работы продукта, который должен быть лицензирован под AGPL? Или же он использует продукт деятельности банка, а уже банк, в свою очередь, внутри себя использует код под AGPL?
То есть когда я звоню в банк (и телефон доступен для любой публики), это не является публичным сервисом?
ИМХО нет, вы же не используете api.
И в том, что эта лицензия требует аналогичной лицензии и публикации их софта, который этот модуль использует. Она "виральная":
моё мнение, если решение банка «завязано» именно на ваш код, то у вас есть основания считать их решение производным (это не значит, что он автоматически становится производным, но тут есть что обсуждать дальше).
если же они (пусть даже формально) добавят поддержку нескольких движков распознавания, то их код уже не может считаться производной работой.
P. S. и да, не стоит в каждом комментарии цитировать мнение гугла об использовании agpl в своих продуктах.
В том то и дело, что они дериват (если это вообще дериват) не публикуют, а используют внутренне.
В интересной статье на Medium приводятся примеры с базой данных. В первом примере база данных используется для хранения пользовательских данных приложения. Программа тут эксплуатируется "как есть", в неизменном, "бинарном" виде, что не обязывает к раскрытию исходников программы на ней основаных. Во втором примере, база данных адаптируется, чтобы поддерживать новые типы запросов, но при этом производная работа не распространяется напрямую, а используется для запросов из приложения. И тут тоже не нужно открывать исходники приложения. В четвертом примере, он использует модифицированную базу данных для аутентификации пользователей внутри огранизации. И тут он тоже не должен публиковать исходники, потому что он не распространяет дериват, а только использует его. И только в третьем примере, где он предоставляет пользователям приложения функцию основанную на его модификации базы (допустим это какой-то новый тип фильтрации), то тут он должен предоставить исходники.
То есть когда я звоню в банк (и телефон доступен для любой публики), это не является публичным сервисом?
Вероятно, если бы в стране было бы более законодательство на счет лицензий, то вы бы скорее всего были бы правы(поэтому гугл и боится этой лицензии), а у нас не понятно, что будет.
То есть когда я звоню в банк (и телефон доступен для любой публики), это не является публичным сервисом?
Ну так у вас же не ПО для телефонии. С результатом работы вашей модели вы как-то взаимодействуете при звонке в банк?
Вот, скажем, если бы вы разрабатывали некую виртуальную АТС и банк её использовал — это было бы другое дело.
Реально ли привлечь или заставить приобрести коммерческую лицензию?
Пудинг, как говорится, познается в еде. Надо написать досудебную претензию и вопрос, возможно, решится сам собой.
Сотрудники "Открытой Мобильной Платформы" тут, на Хабре, пару лет назад хохотали над требованием открыть код их ядра. Оно типичное андроид-linux с GPL лицензией. Даже пытались доказывать, мол-дескать вообще нарушения нет. Весьма вольно трактуя пункты лицензии. Я связался с FSF, обрисовал ситуацию, и они разъяснили, что нарушение есть. И код обязаны открыть. Но, разумеется, никто в ОМП так этого не сделал.
Реально ли привлечь Home Credit Bank за нарушение лицензии открытого проекта?