Pull to refresh

Comments 7

По части «Денег» также надо учитывать перспективы наращивания требований к данной функциональности. Бывает что выгоднее по времени и деньгам держать в команде человека, который полностью контролирует данную функциональность и может её быстро и качественно модифицировать.

+ «Место в общей системе» — чем ближе к ключевой функциональности, тем менее оправдано использование внешних библиотек. И обратно, периферийные и сервисные задачи лучше решать сторонними библиотеками.

+ «Полезная доля» — если из внешней библиотеки будет использоваться 1% функциональности, то лучше поискать альтернативу или написать самим.
А, если не секрет, какие именно аргументы против LGPL?
UFO just landed and posted this here
А зачем обычно это нужно?
Знаю только одно весомое противопоказание — места критичные к производительности. Остальные вроде бы решаются нормальным инсталятором. Что-то упускаю?
UFO just landed and posted this here
Ясно, видимо я мало сталкивался с закрытыми экосистемами.
Формальное обьяснение (не только для LGPL, а для всех blacklisted) — потенциальное раскрытие интеллектуальной собственности компании и высокая трудоемкость/риски связанные с выполнением всех требований лицензии.
Один из точно известных мне рисков — по LGPL v3 необходимо предоставить возможность замены компонента на другую сборку. Мы же не можем этого сделать из-за регуляции — никакие несанкционированные изменения не разрешаются, даже апгрейд проводится исключительно нашими инженерами.
Sign up to leave a comment.

Articles