Чи можете ви стверджувати, що ваш продукт підходить за призначенням, коли він використовує програмне забезпечення OSS, яке не гарантує його?

Я працюю над продуктом для клієнта, який повинен бути дійсним та відповідним призначенню.

Він побудований на стеку LAMP (PHP / Cake), тому є ліцензії GPL, MIT, PHP, APACHE:

ОСНОВА "ЯК Є", БЕЗ гарантій чи умов будь-якого виду, явних або явних, включаючи, без обмежень, будь-які гарантії або умови НАЗВА, НЕЗАКОНУВАННЯ, ПРОДАЖНІСТЬ або ПІДПРИЄМСТВО ДЛЯ ЧАСНОЇ ЦІЛІ . Ви несете повну відповідальність за визначення доцільності використання або перерозподілу твору та несете будь-які ризики, пов’язані з вашим виконанням дозволів відповідно до цієї Ліцензії.

Моє обгрунтування того, що мій товар є дійсним і підходить для цілей:

• Підписаний документ UAT підтверджує дійсність та придатність до призначення.
• Цей стек настільки широко використовується розробниками, галуззю та кінцевими користувачами (netcraft, gartner тощо), що існує консенсус щодо його відповідності призначенню. (тобто ми можемо в міру відхилення від вимог щодо гарантії придатності до гарантії)

Це дійсний пункт? Чи можу я стверджувати, що моє програмне забезпечення підходить за призначенням?

Перш за все, як говорили інші, є різниця між програмним забезпеченням, яке фактично працює, а не програмним забезпеченням, яке продається, з юридичною гарантією його роботи.

Текст про відмову, який ви цитуєте, означає, що оригінальний ліцензіар, від якого ви отримали це програмне забезпечення, не дає жодної гарантії. Ви можете запропонувати програмне забезпечення самостійно, додавши гарантію. Оригінальні автори не дають юридичної гарантії, що програмне забезпечення працює, але немає причин, чому ви не можете зробити таку гарантію своєму клієнту. (Ви вважаєте, чи ні ви вважаєте, що це гарна ідея приєднати юридичну гарантію до того, що ви не написали, - цілком інша справа.)

Зокрема, у розділі 4 GPL зазначено:

Ви можете стягувати будь-яку ціну або ціну за кожну передану копію, і ви можете запропонувати підтримку або гарантійний захист за певну плату.

Я не впевнений, чи повинна ліцензія надати вам можливість явно додавати гарантії (я не юрист, але я думаю, що відповідь - ні. Моя інтуїція полягає в тому, що ви повинні мати можливість надавати гарантії практично на все, що ви хочете ). У будь-якому випадку GPL однозначно пропонує вам можливість додавати власні гарантії під час передачі програмного забезпечення клієнту.

Я не впевнений у BSD, оскільки він вимагає збереження відмови від відповідальності, але, можливо, ви можете запропонувати гарантійний захист, незважаючи на відмову в ліцензії. Насправді, ви можете сказати: "Я стверджую гарантію, що ця робота в цілому підходить для певної мети (навіть якщо деякі роботи, з яких ця велика робота походить, не несуть такої гарантії)". Завжди завжди переконайтесь, що гарантійні умови не порушують ліцензії жодного із ваших робіт.

Однак, знову ж таки, я не юрист, і якщо ваш клієнт попросив гарантії відповідності цілі, він, ймовірно, шукає певного перевіреного юридичного захисту. Вам слід проконсультуватися з юристом, щоб скласти текст такої гарантії.

Це стандартна відмова від відповідальності, яка часто дається для програмного забезпечення, особливо вільного програмного забезпечення.

Це просто означає, що постачальник програмного забезпечення не дає гарантій щодо придатності програмного забезпечення. Він цілком може переконатися сам що програмне забезпечення добре для того, що він робить, але він не хоче входити в законне мінне поле, яке це гарантує.

Це ж стосується і «консенсусу»: «Спільнота» (однак ви хочете її визначити) може погодитись, що певна частина програмного забезпечення відповідає його визначеним цілям, але вони не дадуть вам гарантії.

Якщо коротко: якщо ви не заплатите за це, ви ніколи не змусите когось гарантувати вам будь-який вид фітнесу. І навіть якщо ви когось заплатите, він може не гарантувати цього.

Я думаю, що інші відповіді охоплюють різні аспекти вашого запитання, але я не вірю, що вони безпосередньо стосуються ваших даних.

Так , ви можете видавати гарантію на створене вами програмне забезпечення, включаючи програмне забезпечення з різними згаданими вами ліцензіями на OSS.

Ви (і ваша компанія) будете єдиним носієм відповідальності, породженої цією гарантією. І це все гарантія - це відповідальність. Ви гарантуєте, що несете відповідальність, якщо продукт не працює.

Ви не просите цього робити, але ви можете не відштовхувати цю відповідальність "вгору" до інших програмних компонентів / видавців, про яких ви згадуєте, оскільки вони прямо відмовили у прийнятті цього покриття відповідальності.

Чи ви видаєте ліцензію разом із програмним забезпеченням, чи це ортогональне питання. Ліцензія передбачає умови використання. Гарантія гарантує певну функціональність або експлуатацію. Я рекомендую вам ліцензувати продукт своєму клієнту на додаток до надання необхідної гарантії. Наявність ліцензії сприяє застосуванню наданої гарантії. Це також дозволяє виключити не клієнтів від спроб вимагати від вас гарантійної підтримки.

Що ви використовуєте для визначення придатності - це виключно ваш розсуд. Це залежить від того, який ризик ваша організація готова прийняти. Це також залежить від збитків, яким ви можете зазнати, якщо виріб вийде з ладу і ваш клієнт пред'явить до вас гарантійний позов. UAT - це стандартний підхід і може бути досить хорошим для визначення придатності. Це позитивна перевірка очікуваної функціональності. Консенсус - трохи більше, оскільки ви точно не знаєте, як інші використовують ці компоненти. Консенсус приємний для отримання певної міри впевненості, але він ніде не є таким строгим, як визначено та специфічні тести, які підтверджують необхідну функціональність.

Я працюю над проектом медичного програмного забезпечення, де ми регулювалися однаковим регулюванням, і ми повинні як перевірити, так і затвердити продукт.

І ми могли б це зробити і відповідати вимогам FDA.

Я не брав участі у фактичній валідації інструментів сторонніх виробників, але, наскільки я міг зрозуміти, що нам потрібно було зробити, це вказати, для якої мети нам послужить програмне забезпечення сторонніх розробників. Тоді нам довелося перевірити ці продукти самостійно, це означає, що ми підтвердили, що вибрані сторонні програмні пакети дій діють для цієї мети.

Наскільки я зрозумів, цей тип перевірки не повинен був бути тривалим процесом. Просто якийсь документ на половині сторінки, що описує вимоги та те, як це програмне забезпечення відповідало цим вимогам.

Ця перевірка була б для обох компонентів, вбудованих у власне програмне забезпечення, а також для середовищ розробки, систем управління джерелами тощо.

Примітка. Це засновано на тому, як я зрозумів, що нам потрібно зробити. У мене можуть бути неправильно зрозумілі проблеми. І компанія, можливо, також була більш надмірною в процесі валідації, ніж насправді вимагалося (я відчуваю, що це було до певної міри).

Але програмне забезпечення було підтверджено.

Але для чого потрібен валідований продукт? Чи доставляєте ви в регульований сегмент, наприклад, медичний або фінансовий. Або клієнт ISO 9001 (або подібний) сертифікований? Якщо так, то ви повинні вивчити вимоги до цих видів регламенту, щоб визначити, що саме потрібно.

Відмова від ліцензії GNU існує так, що за замовчуванням розробники позбавляються будь-якої відповідальності, що виникає внаслідок запуску програмного забезпечення.

Навіть якщо ви вважаєте, що програмісти повинні нести відповідальність за погане програмне забезпечення, факт полягає в тому, що програмне забезпечення є безкоштовним.

Відмова від відповідальності просто говорить про те, що розповсюджується лише програмне забезпечення, а не гарантійний захист.

Модель GNU для заробітку на програмному забезпеченні - це продаж послуг або гарантійний захист.

Гарантія - це більше, ніж просто впевненість у тому, що продукт підходить для певної мети. На цьому треба їсти гроші. По крайней мере, «повернення грошей», або більше: зобов’язання виконати роботи, щоб привести товар до такого стану, щоб він підходив для покритого призначення, або навіть покривав деякі збитки та збитки.

Наявність або відсутність гарантії не змінює того, що продукт є ; це просто форма страхування, яка змінює спосіб розподілу ризику між продавцем та клієнтом.

Цей бізнес із забезпечення зобов'язань щодо вільного програмного забезпечення насправді є досить поширеним. Кожен, хто працює на комерційній основі з вільним програмним забезпеченням, зазвичай виправляє його, якщо у клієнта є проблеми. Якщо ви зробите якийсь апаратний ящик, на якому працює вбудований дистрибутив Linux, і у нього виникають проблеми через помилку в ядрі, бібліотеці С або деінде, ви виправите це для клієнтів. Ситуація така, що у вашій коробці є проблема, і ви пообіцяли клієнтам надійну скриньку, 24/7.

Ваші міркування є помилковими з кількох причин:

• Ніщо в ліцензії не дає вам можливості змінювати її умови. Якщо ви прийняли ліцензійні умови, використовуючи твір, вас зобов’язує все, що в ньому є. Якщо вам більше не подобаються умови, ви можете припинити використання програмного забезпечення.

• У ліцензії немає положень про широке прийняття твору, що змінює умови.

• Ваш тест на прийняття користувача не впливає на угоду, яку ви уклали з ліцензіаром. Якщо ви гарантували, що ваш вибір твору для включення у ваш продукт робить його придатним для цілей вашого замовника, це між вами та вашим замовником. Ліцензіар - це неучасна третя сторона.

Речення, яке слідує за тим, яке ви виділили ("Ви несете повну відповідальність за визначення ..."), має наслідки того, що він його прямо використав у колінах.