Я работаю над продуктом для клиента, который должен быть действительным и соответствовать цели.
Он построен на стеке LAMP (PHP / Cake), поэтому есть лицензии GPL, MIT, PHP, APACHE:
«КАК ЕСТЬ», БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ УСЛОВИЙ ЛЮБОГО ВИДА, явных или подразумеваемых, включая, без ограничений, любые гарантии или условия НАЗВАНИЯ, НЕПРАВИЛЬНОСТИ, ТОВАРНОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ ОСОБЫХ ЦЕЛЕЙ . Вы несете единоличную ответственность за определение целесообразности использования или перераспределения Произведения и принимаете на себя любые риски, связанные с осуществлением вами разрешений по настоящей Лицензии.
Мое обоснование того, что мой продукт действителен и пригоден для следующих целей:
- Подписанный документ UAT подтверждает правильность и соответствие назначению.
- Стек настолько широко используется разработчиками, отраслевыми и конечными пользователями (netcraft, gartner и т. Д.), Что существует единодушное мнение о том, что он подходит по назначению. (т. е. мы можем не принимать во внимание степень соответствия заявленной цели в заявлении об отказе от гарантии)
Это верный момент? Могу ли я заявить, что мое программное обеспечение соответствует назначению?
источник
Ответы:
Во-первых, как уже говорили другие, есть разница между фактически работающим программным обеспечением и продаваемым программным обеспечением с юридической гарантией его работы.
Текст отказа от ответственности, который вы цитируете, означает, что оригинальный лицензиар, у которого вы получили программное обеспечение, не предоставляет никаких гарантий. Вы можете предложить программное обеспечение самостоятельно с приложенной гарантией. Авторы оригинала не дают юридической гарантии того, что программное обеспечение работает, но нет никаких причин, по которым вы не можете предоставить такую гарантию своему клиенту. (Независимо от того, считаете ли вы, что это хорошая идея - прикрепить юридическую гарантию к тому, что вы не написали, это совсем другой вопрос.)
В частности, в разделе 4 GPL говорится:
Я не уверен, должна ли лицензия предоставлять вам возможность явно добавлять гарантии (я не юрист, но я думаю, что ответ - нет, моя интуиция заключается в том, что вы должны быть в состоянии предложить гарантии практически на все, что вы хотите ). В любом случае, GPL однозначно предлагает вам возможность добавить свои собственные гарантии при передаче программного обеспечения клиенту.
Я не уверен насчет BSD, так как он требует от вас сохранения отказа от ответственности, но, возможно, вы можете предложить гарантийную защиту, несмотря на отказ от ответственности в лицензии. По сути, вы можете сказать: «Я утверждаю, что эта работа в целом пригодна для какой-то цели (хотя некоторые работы, из которых получена эта большая работа, не несут такой гарантии)». Конечно, всегда проверяйте, чтобы ваши условия гарантии не нарушали лицензии на любые из ваших включенных работ.
Однако, опять же, я не юрист, и, если ваш клиент запросил гарантию пригодности, он, вероятно, ищет некоторую проверенную правовую защиту. Вам следует проконсультироваться с юристом, чтобы составить текст такой гарантии.
источник
Это стандартный отказ от ответственности, который часто дается для программного обеспечения, особенно для свободного программного обеспечения.
Это просто означает, что поставщик программного обеспечения не дает никаких гарантий относительно пригодности программного обеспечения. Он вполне может убедить себя, что программное обеспечение хорошо для того, что оно делает, но он не хочет вступать в законное минное поле, которое его гарантирует.
То же самое относится и к «консенсусу»: «сообщество» (как бы вы его ни хотели определить) может согласиться с тем, что данный фрагмент программного обеспечения соответствует заявленной цели, но не дает вам гарантии.
Короче говоря: если вы не заплатите за это, вы никогда не получите никого, кто гарантировал бы вам любую физическую форму. И даже если вы платите кому-то, они могут этого не гарантировать.
источник
Я думаю, что другие ответы охватывают различные аспекты вашего вопроса, но я не верю, что они напрямую касаются ваших подробностей.
Да , вы можете оформить гарантию на созданное вами программное обеспечение, включая программное обеспечение с различными лицензиями OSS, которые вы упомянули.
Вы (и ваша компания) будете единоличным держателем ответственности, вытекающей из этой гарантии. И это все гарантия - это ответственность. Вы гарантируете свою ответственность, если продукт не работает.
Вы не просите об этом, но вы не можете отодвинуть эту ответственность «вверх по потоку» другим компонентам / издателям программного обеспечения, о которых вы упомянули, поскольку они прямо отказались принять это покрытие ответственности.
Выдавать ли вам лицензию вместе с программным обеспечением - это связанный, но ортогональный вопрос. Лицензия предоставляет условия использования. Гарантия гарантирует определенную функциональность или работу. Я бы порекомендовал вам лицензировать продукт для вашего клиента в дополнение к предоставлению требуемой гарантии. Наличие лицензии помогает оценить применимость предоставляемой вами гарантии. Это также позволяет исключить попытки получения гарантийной поддержки от лиц, не являющихся клиентами.
То, что вы используете для определения физической формы, является исключительно вашим усмотрением. Это зависит от того, какой риск готов принять ваша организация. Это также зависит от ущерба, который вы можете получить, если продукт выйдет из строя, и ваш клиент предъявит претензию по гарантии против вас. UAT является стандартным подходом и может быть очень хорошим для определения пригодности. Это положительная проверка ожидаемой функциональности. Консенсус немного более сомнительный, поскольку вы точно не знаете, как другие используют эти компоненты. Консенсус хорош для создания определенной степени доверия, но он далеко не так строг, как определенные и конкретные тесты, которые проверяют требуемую функциональность.
источник
Я работал над проектом медицинского программного обеспечения, где мы были в соответствии с одним и тем же законодательством, мы должны как проверять, так и проверять продукт.
И мы могли бы сделать это и соответствовать требованиям FDA.
Я не принимал участия в фактической проверке сторонних инструментов, но, насколько я мог понять, нам нужно было указать, для какой цели будет использоваться стороннее программное обеспечение. Затем мы должны были сами проверить эти продукты, то есть мы убедились, что выбранные сторонние программные пакеты на самом деле служат этой цели.
Насколько я понял, этот тип проверки не должен был быть длительным процессом. Просто какой-то полстраничный документ, описывающий требования и то, как это программное обеспечение удовлетворяет этим требованиям.
Эта проверка будет как для компонентов, встроенных в реальное программное обеспечение, так и для сред разработки, систем контроля версий и т. Д.
Примечание: это основано на том, как я понял, что мы должны были сделать. Возможно, я неправильно понял вопросы. И компания, возможно, также была более чрезмерной в процессе валидации, чем фактически требовалось (у меня есть ощущение, что это имело место в некоторой степени).
Но программное обеспечение было проверено.
Но зачем вам проверенный продукт? Вы доставляете товары в регулируемый сегмент, например, в медицинский или финансовый сектор? Или клиент ISO 9001 (или аналогичный) сертифицирован? Если это так, вы должны изучить требования к такого рода правилам самостоятельно, чтобы выяснить, что именно нужно.
источник
Отказ от ответственности по лицензии GNU существует, так что по умолчанию разработчики освобождаются от ответственности, связанной с использованием программного обеспечения.
Даже если вы чувствуете, что программисты должны нести ответственность за плохое программное обеспечение, факт в том, что программное обеспечение является бесплатным.
Отказ от ответственности просто говорит, что распространяется только программное обеспечение, а не какая-либо гарантийная защита.
Модель GNU для зарабатывания денег на программном обеспечении - продажа услуг или гарантийная защита.
Гарантия - это больше, чем просто заявление о том, что продукт подходит для определенной цели. На нем должны быть деньги. По крайней мере, «возврат денег» или более: обязательство выполнить работу, чтобы привести продукт в такое состояние, чтобы он был пригоден для покрываемой цели или даже покрыть некоторые убытки и ущерб.
Наличие или отсутствие гарантии не меняет того, что продукт является ; это просто форма страхования, которая меняет распределение риска между продавцом и покупателем.
Этот бизнес предоставления обязательств перед свободным программным обеспечением на самом деле довольно распространен. Любой, кто работает на коммерческой основе со свободным программным обеспечением, обычно исправляет это, если у клиента есть проблема. Если вы делаете какой-то аппаратный блок, на котором работает встроенный дистрибутив Linux, и у него есть проблема из-за ошибки в ядре, библиотеке C или где-либо еще, вы исправите это для клиентов. Ситуация такова, что ваша коробка имеет проблему, и вы пообещали клиентам надежную коробку 24/7.
источник
Ваше рассуждение ошибочно по нескольким причинам:
Ничто в лицензии не дает вам возможности изменять ее условия. Если вы приняли условия лицензии, используя произведение, вы обязаны соблюдать все в нем. Если вам больше не нравятся условия, вы можете прекратить использование программного обеспечения.
В лицензии нет положений для широкого принятия работ, меняющих условия.
Ваш приемочный тест не имеет отношения к соглашению, которое вы заключили с лицензиаром. Если вы гарантировали, что ваш выбор работы для включения в ваш продукт делает его подходящим для целей вашего клиента, это между вами и вашим клиентом. Лицензиар является сторонней третьей стороной.
Предложение, следующее за тем, которое вы выдвинули на первый план («Вы несете единоличную ответственность за определение ...»), влечет за собой последствия использования его прямо у вас на коленях.
источник