/dev/юрист
>> право, технології та простір між ними
Весь вміст від Кайла Е. Мітчелла , який не є вашим адвокатом .
Ви можете підписатися через RSS/Atom або електронною поштою та переглядати інші блоги .
21 вересня 2016
Ліцензія MIT, рядок за рядком
171 слово, яке повинен розуміти кожен програміст
Ця публікація є частиною серії « Рядок за рядком» .
Ліцензія MIT є найпопулярнішою ліцензією на програмне забезпечення з відкритим кодом. Ось одне прочитання цього, рядок за рядком.
Прочитайте Ліцензію
Якщо ви працюєте з програмним забезпеченням з відкритим вихідним кодом і не знайшли часу, щоб прочитати ліцензію зверху вниз — це лише 171 слово — вам потрібно зробити це зараз. Особливо, якщо ліцензії не є вашою щоденною справою. Зробіть подумки все, що здається незрозумілим або незрозумілим, і продовжуйте рух. Я повторю кожне слово ще раз, по частинах і по порядку, з контекстом і коментарем. Але важливо мати на увазі ціле.
Ліцензія MIT (MIT)
Авторське право (c) <рік> <власники авторських прав>
Цим надається безкоштовний дозвіл будь-якій особі, яка отримує копію цього програмного забезпечення та пов’язаних файлів документації («Програмне забезпечення»), працювати з Програмним забезпеченням без обмежень, включаючи без обмежень права на використання, копіювання, зміну, об’єднання публікувати, розповсюджувати, субліцензувати та/або продавати копії Програмного забезпечення, а також дозволяти особам, яким надано Програмне забезпечення, робити це відповідно до таких умов:
Наведене вище повідомлення про авторські права та це повідомлення про дозвіл мають бути включені до всіх копій або значних частин Програмного забезпечення.
Програмне забезпечення надається «як є», без будь-яких гарантій, явних чи неявних, включаючи, але не обмежуючись гарантіями придатності для продажу, придатності для певної мети та непорушення прав. За жодних обставин автори чи власники авторських прав не несуть відповідальності за будь-які претензії, збитки чи іншу відповідальність, незалежно від того, чи це договір, правопорушення чи інше, що виникає внаслідок, у зв’язку з програмним забезпеченням або використанням чи іншими операціями в програмне забезпечення.
Ліцензія складається з п’яти параграфів, але логічно розбивається так:
Заголовок
Назва ліцензії : «Ліцензія MIT»
Повідомлення про авторські права : «Авторське право (c)…»
Надання ліцензії : «Цим надається дозвіл…»
Обсяг гранту : «... мати справу з програмним забезпеченням…»
Умови : «…з урахуванням…»
Позначення авторства та примітка : «Вище... має бути включено...»
Відмова від гарантії : « Програмне забезпечення надається «як є»… »
Обмеження відповідальності : « Ні в якому разі… »
Ось і ми:
Заголовок
Назва ліцензії
Ліцензія MIT (MIT)
«Ліцензія Массачусетського технологічного інституту» — це не окрема ліцензія, а набір форм ліцензій, створених на основі мови, підготовленої для випусків Массачусетським технологічним інститутом. За ці роки він зазнав багато змін як для оригінальних проектів, у яких він використовувався, так і як модель для інших проектів. Проект Fedora підтримує своєрідний кабінет ліцензійних цікавинок Массачусетського технологічного інституту , із безглуздими варіаціями, збереженими у вигляді звичайного тексту, як анатомічні зразки у формальдегіді, простежуючи примхливу еволюцію.
На щастя, групи Open Source Initiative та Software Package Data eXchange стандартизували загальну форму ліцензії в стилі MIT як «Ліцензія MIT». OSI, у свою чергу, прийняв стандартизовані ідентифікатори рядків SPDX для звичайних ліцензій з відкритим кодом, MITоднозначно вказуючи на стандартизовану форму «ліцензія MIT». Якщо вам потрібні терміни в стилі MIT для нового проекту, використовуйте стандартизовану форму .
Навіть якщо ви включите «Ліцензію Массачусетського технологічного інституту» або «SPDX:MIT» у файл LICENSE, будь-який відповідальний рецензент все одно запустить порівняння тексту зі стандартною формою, щоб переконатися. У той час як різні форми ліцензій, які називають себе «Ліцензія MIT», відрізняються лише незначними деталями, вільність того, що вважається «Ліцензією MIT», спокусила деяких авторів додати надокучливі «налаштування». Канонічним жахливим, непоганим, дуже поганим прикладом цього є ліцензія JSON , ліцензія сімейства Массачусетського технологічного інституту плюс «Програмне забезпечення слід використовувати для добра, а не для зла». Такі речі можуть бути «дуже крокфордськими». Це безперечно біль у дупі. Можливо, жарт мав бути над адвокатами. Але всю дорогу до банку вони сміялися.
Мораль історії: одна лише «ліцензія MIT» є неоднозначною. Люди, напевно, добре розуміють, що ви маєте на увазі під цим, але ви лише заощадите час усім, включаючи себе, скопіювавши текст стандартної форми ліцензії MIT у свій проект. Якщо ви використовуєте метадані, як-от licenseвластивість у файлах метаданих менеджера пакунків, для позначення MITліцензії, переконайтеся, що ваш LICENSEфайл і будь-які коментарі заголовка використовують стандартний текст форми. Все це можна автоматизувати .
Повідомлення про авторські права
Авторське право (c) <рік> <власники авторських прав>
До Закону про авторське право 1976 року законодавство Сполучених Штатів про авторське право вимагало виконання певних дій, які називалися «формальності», щоб захистити авторські права на творчі роботи. Якщо ви не дотримувалися цих формальностей, ваші права подавати до суду на інших за несанкціоноване використання вашої роботи були обмежені, а часто й повністю втрачені. Однією з цих формальностей було «повідомлення»: позначення на вашій роботі та іншим способом інформування ринку про те, що ви претендуєте на авторські права. © — це стандартний символ для позначення творів, захищених авторським правом, для повідомлення про авторське право. Набір символів ASCII не містить символу ©, але Copyright (c)має ту саму точку.
Закон про авторське право 1976 року, який «реалізував» багато вимог міжнародної Бернської конвенції, скасував формальності щодо забезпечення авторського права. Принаймні в Сполучених Штатах власники авторських прав все ще повинні зареєструвати свої твори, захищені авторським правом, перш ніж подати до суду за порушення, з потенційно вищими збитками, якщо вони зареєструються до початку порушення. Однак на практиці багато хто реєструє авторські права безпосередньо перед тим, як подати позов проти когось конкретного. Ви не втрачаєте свої авторські права, просто не розміщуючи повідомлення, не зареєструвавшись, не надіславши копію до Бібліотеки Конгресу тощо.
Навіть якщо повідомлення про авторські права не є такими вкрай необхідними, як раніше, вони все одно дуже корисні. Зазначення року створення твору та того, кому належать авторські права, щоб дати деяке уявлення про те, коли термін дії авторського права на твір може закінчитися, і твір стане суспільним надбанням. Ідентичність автора або авторів також корисна: законодавство Сполучених Штатів по-різному розраховує терміни авторського права для окремих і «корпоративних» авторів. Особливо в бізнес-використанні компанії також може знадобитися двічі подумати про використання програмного забезпечення від відомого конкурента, навіть якщо умови ліцензії дають дуже щедрий дозвіл. Якщо ви сподіваєтеся, що інші побачать вашу роботу й захочуть отримати від вас її ліцензію, зауваження про авторські права чудово слугуватимуть для посилання на авторство.
Що стосується «власника авторського права»: не всі стандартні ліцензії мають місце для цього. Новіші форми ліцензій, такі як Apache 2.0 і GPL 3.0 , публікують LICENSEтексти, призначені для дослівного копіювання, з коментарями в заголовках і окремими файлами в інших місцях, щоб вказати, хто володіє авторським правом і надає ліцензію. Ці підходи акуратно перешкоджають змінам «стандартних» текстів, випадкових чи навмисних. Вони також роблять автоматизовану ідентифікацію ліцензії більш надійною.
Ліцензія MIT походить від мови, написаної для випусків коду установами. Для інституційних випусків існував лише один чіткий «власник авторських прав», установа, яка випускає код. Інші інституції схибили ці ліцензії, замінивши «MIT» власними назвами, що зрештою призвело до загальних форм, які ми маємо зараз. Цей процес повторювався для інших короткострокових інституційних ліцензій тієї епохи, зокрема оригінальної Ліцензії BSD з чотирьох статей для Каліфорнійського університету в Берклі, яка зараз використовується у варіантах із трьох і двох статей , а також Ліцензії ISC для Консорціум Інтернет-систем, варіант MIT.
У кожному випадку установа зазначила себе як власника авторських прав, покладаючись на правила володіння авторським правом, які називаються правилами « творів, створених для найму », які надають роботодавцям і клієнтам право власності на авторські права на певну роботу, яку їхні працівники та підрядники виконують від їх імені. Ці правила зазвичай не застосовуються до розповсюджених співавторів, які надсилають код добровільно. Це створює проблему для фондів керуючих проектами, таких як Apache Foundation і Eclipse Foundation, які приймають внески від більш різноманітної групи учасників. Звичайним основоположним підходом досі було використання власної ліцензії, яка вказує на одного власника авторських прав — Apache 2.0 і EPL 1.0 — підкріплених ліцензійними угодами учасників — Apache CLA та Eclipse CLA — для отримання прав від учасників. Збирання авторських прав в одному місці є ще більш важливим за ліцензіями «copyleft», такими як GPL, які покладаються на власників авторських прав, щоб забезпечити виконання умов ліцензії для просування цінностей свободи програмного забезпечення.
У наші дні багато проектів без будь-якого інституційного чи бізнес-керівника використовують умови ліцензії в стилі MIT. SPDX і OSI допомогли цим випадкам використання, стандартизувавши форми ліцензій, як-от MIT та ISC, які не стосуються певної організації чи інституційного власника авторських прав. Озброївшись цими формами, автори проектів зазвичай заповнюють власне ім’я в повідомленні про авторські права у формі дуже рано… і, можливо, змінюють рік тут і там. Принаймні відповідно до закону про авторське право Сполучених Штатів, отримане повідомлення про авторські права не дає повної картини.
Початковий власник частини програмного забезпечення зберігає право власності на свою роботу. Але в той час як умови ліцензії в стилі Массачусетського технологічного інституту надають іншим права створювати та змінювати програмне забезпечення, створюючи те, що закон називає «похідними роботами», вони не надають оригінальному автору права власності на авторські права на внески інших. Швидше, кожен учасник має авторські права на будь-яку навіть незначну творчу роботу, яку він створює, використовуючи існуючий код як відправну точку.
Більшість із цих проектів також не сприймають ідею підписання ліцензійних угод учасників, не кажучи вже про підписані передачі авторських прав. Це і наївно, і зрозуміло. Незважаючи на припущення деяких нових розробників з відкритим кодом, що надсилання запиту на отримання на GitHub «автоматично» ліцензує внесок для розповсюдження на умовах існуючої ліцензії проекту, законодавство Сполучених Штатів не визнає жодного такого правила. За замовчуванням використовується надійний захист авторських прав, а не дозволене ліцензування.
Оновлення: Пізніше GitHub змінив свої умови обслуговування для всього сайту, включивши спробу змінити це значення за умовчанням, принаймні на GitHub.com. Я написав деякі думки щодо цього розвитку подій, не всі з них позитивні, в іншій публікації .
Щоб заповнити прогалину між юридично ефективними, добре задокументованими наданням прав на внески та відсутністю паперового сліду взагалі, деякі проекти прийняли Сертифікат походження розробника , стандартну заяву, яку учасники натякають на використання Signed-Off-Byтегів метаданих у своїх комітах Git. Сертифікат походження розробника був розроблений для розробки ядра Linux після сумнозвісних судових процесів SCO, які стверджували, що фрагменти коду Linux були отримані з вихідного коду Unix, що належить SCO. Сертифікат походження розробника чудово функціонує як засіб створення паперового сліду, який показує, що кожен рядок Linux надійшов від учасника. Хоча Сертифікат походження розробника не є ліцензією, він надає багато вагомих доказів того, що ті, хто надсилає код, очікують, що проект розповсюдить їхній код, а інші використовуватимуть його відповідно до існуючих умов ліцензії на ядро. Ядро також підтримує машинозчитуваний CREDITSфайл зі списком учасників із іменами, приналежністю, областю внесків та іншими метаданими. Я провів кілька експериментів , адаптуючи цей підхід для проектів, які не використовують потік розробки ядра.
Надання ліцензії
Цим надається безкоштовний дозвіл будь-якій особі, яка отримує копію цього програмного забезпечення та пов’язаних файлів документації («Програмне забезпечення»),
Суть Ліцензії Массачусетського технологічного інституту, як ви здогадалися, — ліцензія. Загалом, ліцензія — це дозвіл, який одна фізична чи юридична особа — «ліцензіар» — надає іншій — «ліцензіату» — робити те, що інакше закон дозволив би їй подати до суду. Ліцензія MIT — це обіцянка не судитися.
Закон іноді розрізняє ліцензії та обіцянки надати ліцензії. Якщо хтось порушує обіцянку надати ліцензію, ви можете подати на нього до суду за порушення обіцянки, але ви можете не отримати ліцензію. «Цим» — одне з тих дурних, архаїчно звучать слів, яких юристи просто не можуть позбутися. Він використовується тут, щоб показати, що сам текст ліцензії надає ліцензію, а не лише обіцянку ліцензії. Це законний IIFE .
Хоча багато ліцензій надають дозвіл конкретному ліцензіату, Ліцензія MIT є «публічною ліцензією». Публічні ліцензії дають усім — широкій громадськості — дозвіл. Це одна з трьох чудових ідей у сфері ліцензування з відкритим кодом. Ліцензія MIT відображає цю ідею, надаючи ліцензію «будь-якій особі, яка отримує копію … Програмного забезпечення». Як ми побачимо пізніше, для отримання цієї ліцензії також є умова, яка гарантує, що інші також дізнаються про свій дозвіл.
Дужки з великими літерами в лапках («Визначення») є стандартним способом надання термінам конкретного значення в юридичних документах американського зразка. Суди достовірно повертатимуться до термінів визначення, коли побачать визначений термін, написаний великими літерами, використаний в іншому місці документа.
Обсяг гранту
працювати з програмним забезпеченням без обмежень,
З точки зору ліцензіата, це сім найважливіших слів у Ліцензії MIT. Основні юридичні проблеми – подати до суду за порушення авторських прав і за порушення патенту. Ні в законі про авторське право, ні в патентному праві не використовується термін «торгуватися» як художній термін; це не має конкретного значення в суді. У результаті будь-який суд, який вирішує спір між ліцензіаром і ліцензіатом, запитав би, що сторони мали на увазі та розуміли під цією мовою. Суд побачить, що мова є навмисно широкою та відкритою. Це дає ліцензіатам вагомий аргумент проти будь-яких претензій ліцензіара про те, що вони не давали дозволу ліцензіату робити певні дії з програмним забезпеченням, навіть якщо ця думка явно не спала на думку жодній із сторін під час надання ліцензії.
включаючи, без обмежень, права на використання, копіювання, зміну, об’єднання, публікацію, розповсюдження, надання субліцензії та/або продаж копій Програмного забезпечення, а також надання дозволу особам, яким надано Програмне забезпечення, робити це,
Жоден юридичний текст не є досконалим, «повністю визначеним у значенні» або безпомилково зрозумілим. Остерігайтеся тих, хто прикидається іншим. Це найменш досконала частина Ліцензії MIT. Є три основні проблеми:
По-перше, «включаючи без обмежень» є правовим антипаттерном. Він буває в будь-якій кількості смаків:
«включаючи, без обмежень»
«включаючи, без обмеження загальності вищезазначеного»
«включаючи, але не обмежуючись»
багато, багато безглуздих варіацій
Усі вони мають спільну мету, і всі вони не досягають її надійно. По суті, автори, які використовують їх, намагаються також отримати свій торт і з’їсти його. У Ліцензії Массачусетського технологічного інституту це означає введення конкретних прикладів «роботи з програмним забезпеченням» — «використання, копіювання, модифікація» тощо — без натяку на те, що дія ліцензіата має бути чимось схожою на наведені приклади, щоб вважатися «торговою діяльністю». Проблема в тому, що якщо вам знадобиться суд для перегляду та тлумачення умов ліцензії, суд розглядатиме свою роботу як з’ясувати, що ті, хто сперечається, мали на увазі під мовою. Якщо суду потрібно вирішити, що означає «угода», він не може «переглянути» приклади, навіть якщо ви йому це скажете. Я б стверджував, що для ліцензіатів краще лише «торгуватися програмним забезпеченням без обмежень». Також коротше.
По-друге, дієслова, наведені як приклади «deal in», є солянкою. Деякі з них мають конкретне значення згідно з авторським правом або патентним законодавством, інші майже мають або просто не мають:
Термін «використання» міститься в розділі 35 Кодексу США, розділі 271(a) , списку закону про патенти щодо того, за що власники патентів можуть подавати до суду на інших за виконання без дозволу.
«Копія» міститься в розділі 106 розділу 17 кодексу США , списку закону про авторське право щодо того, за що власники авторських прав можуть подати до суду на інших за виконання без дозволу.
"змінити" не згадується ні в авторському, ні в патентному статуті. Ймовірно, це ближче до «підготовки похідних робіт» згідно зі статутом про авторське право, але також може передбачати вдосконалення чи інші похідні винаходи.
"злиття" не згадується ні в авторському, ні в патентному статуті. «Злиття» має конкретне значення в авторському праві, але це явно не те, що тут мається на увазі. Швидше суд би читав «об’єднати» відповідно до його значення в галузі, як «об’єднати код».
«опублікувати» не згадується ні в авторському, ні в патентному статуті. Оскільки «Програмне забезпечення» — це те, що публікується, воно, ймовірно, ближче до «розповсюдження» відповідно до закону про авторське право . Цей статут також охоплює права на виконання та показ творів «публічно», але ці права застосовуються лише до певних видів творів, захищених авторським правом, таких як вистави, звукозаписи та кінофільми.
«розповсюджувати» з’являється в статуті авторського права .
«субліцензія» — це загальний термін законодавства про інтелектуальну власність. Право на субліцензування означає право надавати іншим власні ліцензії, робити частину або все те, на що ви маєте дозвіл. Право ліцензії Массачусетського технологічного інституту на субліцензування насправді є дещо незвичним для ліцензій з відкритим вихідним кодом загалом. Нормою є те, що Хізер Мікер називає підходом «прямого ліцензування», коли кожен, хто отримує копію програмного забезпечення та його умови ліцензії, отримує ліцензію безпосередньо від власника. Будь-хто, хто може отримати субліцензію за Ліцензією Массачусетського технологічного інституту, ймовірно, отримає копію ліцензії, яка повідомляє, що вони також мають пряму ліцензію.
«продавати копії» — дворняжка. Це близьке до «пропозиції продати» та «продати» в патентному статуті , але стосується «копій», поняття авторського права. З боку авторського права це здається близьким до «розповсюдження», але статут про авторські права не згадує про продаж.
«Дозволяти особам, яким надано програмне забезпечення, робити це» здається зайвим у «субліцензії». Це також непотрібно, оскільки люди, які отримують копії, також отримують пряму ліцензію.
Нарешті, внаслідок цієї суміші юридичних, галузевих, загальних умов інтелектуальної власності та загального використання неясно, чи включає Ліцензія MIT ліцензію на патент. Загальна мова «deal in» і деякі приклади дієслів, особливо «use», вказують на патентну ліцензію, хоча й дуже нечітку. Той факт, що ліцензія походить від власника авторських прав , який може мати або не мати патентних прав на винаходи в програмному забезпеченні, а також більшість прикладів дієслів і визначення самого «Програмного забезпечення» — все це переконливо вказує на ліцензію на авторське право . У новіших дозвільних ліцензіях з відкритим вихідним кодом, як-от Apache 2.0 , авторське право, патент і навіть товарний знак розглядаються окремо та конкретно.
Три ліцензійні умови
за дотримання наступних умов:
Завжди є заковика! MIT має три!
Якщо ви не дотримуєтеся умов ліцензії MIT, ви не отримаєте дозволу, який пропонує ліцензія. Отже, невиконання умов, принаймні теоретично, залишає вас відкритим для судового позову, ймовірно, позову щодо авторських прав.
Використання цінності програмного забезпечення для ліцензіата для мотивації дотримання умов, навіть якщо ліцензіат нічого не заплатив за ліцензію, є другою чудовою ідеєю ліцензування з відкритим кодом. Останнє, якого немає в Ліцензії MIT, базується на ліцензійних умовах: ліцензії «Copyleft», такі як GNU General Public License, використовують умови ліцензії, щоб контролювати, як ті, хто вносить зміни, можуть ліцензувати та поширювати свої змінені версії.
Умова повідомлення
Наведене вище повідомлення про авторські права та це повідомлення про дозвіл мають бути включені до всіх копій або значних частин Програмного забезпечення.
Якщо ви надаєте комусь копію програмного забезпечення, вам потрібно включити текст ліцензії та будь-яке повідомлення про авторські права. Це служить кільком важливим цілям:
Повідомляє іншим, що вони мають дозвіл на використання програмного забезпечення за загальнодоступною ліцензією. Це ключова частина моделі прямого ліцензування, коли кожен користувач отримує ліцензію безпосередньо від власника авторських прав.
Повідомляє, хто стоїть за програмним забезпеченням, щоб їх можна було засипати похвалами, славою та холодними, твердими грошовими пожертвами.
Гарантує, що відмова від гарантії та обмеження відповідальності (буде далі) дотримуються програмного забезпечення. Усі, хто отримує копію, також повинні отримати копію цих засобів захисту ліцензіара.
Ніщо не заважає вам стягувати плату за надання копії або навіть копії у скомпільованій формі без вихідного коду. Але коли ви це зробите, ви не зможете вдавати, що код MIT є вашим власним кодом або надається за іншою ліцензією. Ті, хто отримує, знайомляться зі своїми правами за «публічною ліцензією».
Відверто кажучи, дотримання цієї умови ламається. Майже кожна ліцензія з відкритим кодом має таку умову «зазначення авторства». Виробники системного та інстальованого програмного забезпечення часто розуміють, що їм потрібно буде скомпілювати файл сповіщень або екран «інформації про ліцензію» з копіями текстів ліцензій для бібліотек і компонентів для кожного власного випуску. Фонди управління проектами відіграли важливу роль у навчанні цим практикам. Але веб-розробники, як правило, не отримали пам’ятки. Це не можна пояснити відсутністю інструментів — їх багато — або високомодульною природою пакетів із npm та інших репозиторіїв, які однаково стандартизують формати метаданих для інформації про ліцензію. Усі хороші мініфікатори JavaScript мають позначки командного рядка для збереження коментарів заголовка ліцензії. Інші інструменти об’єднуватимуть LICENSEфайли з дерев пакетів. Насправді немає виправдання.
Відмова від гарантії
Програмне забезпечення надається «як є», без будь-яких гарантій, явних чи неявних, включаючи, але не обмежуючись гарантіями придатності для продажу, придатності для певної мети та непорушення прав.
Майже в кожному штаті Сполучених Штатів прийнято версію Уніфікованого комерційного кодексу, типового статуту законів, що регулюють комерційні операції. Стаття 2 UCC — «Відділ 2» у Каліфорнії — регулює контракти на продаж товарів, від викуплених уживаних автомобілів до великих поставок промислових хімікатів на заводи-виробники.
Деякі правила UCC щодо договорів купівлі-продажу є обов'язковими. Ці правила застосовуються завжди, незалежно від того, подобаються вони тим, хто купує та продає, чи ні. Інші лише «за замовчуванням». Якщо покупці та продавці не відмовляються в письмовій формі, UCC означає, що вони хочуть базове правило, яке міститься в тексті UCC для їхньої угоди. Серед стандартних правил є неявні «гарантії» або обіцянки продавців покупцям щодо якості та зручності використання товарів, що продаються.
Існує велика теоретична дискусія щодо того, чи є публічні ліцензії, такі як Ліцензія Массачусетського технологічного інституту, контрактами — обов’язковими угодами між ліцензіарами та ліцензіатами — чи просто ліцензіями, які мають один напрямок, але можуть супроводжуватися умовами. Існує менше дискусій щодо того, чи вважається програмне забезпечення «товаром», що спричиняє дію правил UCC. Серед ліцензіарів немає дискусій щодо відповідальності: вони не хочуть отримати великі гроші, якщо програмне забезпечення, яке вони надають безкоштовно, ламається, спричиняє проблеми, не працює чи іншим чином спричиняє проблеми. Це прямо протилежне тому, що роблять три правила за замовчуванням для «опосередкованих гарантій»:
Непряма гарантія «товарної придатності» відповідно до розділу 2-314 UCC — це обіцянка того, що «товари» — Програмне забезпечення — мають принаймні середню якість, належним чином упаковані та марковані та придатні для звичайних цілей, для яких вони призначені. Ця гарантія поширюється лише в тому випадку, якщо особа, яка надає програмне забезпечення, є «продавцем» щодо програмного забезпечення, тобто вона займається програмним забезпеченням і вважає себе кваліфікованим спеціалістом у програмному забезпеченні.
Непряма гарантія «придатності для певної мети» відповідно до розділу 2-315 UCC вступає в силу, коли продавець знає, що покупець покладається на нього, щоб надати товар для певної мети. Товар має бути «придатним» для цієї мети.
Непряма гарантія «непорушення» не є частиною UCC, але є загальною рисою загального договірного права. Ця прихована обіцянка захищає покупця, якщо виявиться, що отримані товари порушують чиїсь права інтелектуальної власності. Так було б, якби програмне забезпечення за Ліцензією Массачусетського технологічного інституту насправді не належало тому, хто намагався його ліцензувати, або якби воно підпадало під патент, що належить комусь іншому.
Розділ 2-316(3) UCC вимагає відмови від або «виключення» непрямих гарантій комерційної придатності та придатності для певної мети, щоб бути помітними. «Помітний», у свою чергу, означає написаний або відформатований, щоб привернути до себе увагу, протилежність мікроскопічному дрібному шрифту, призначеному для прослизнення повз необережних споживачів. Закон штату може встановлювати подібну вимогу, яка привертає увагу, до застережень про непорушення прав.
Юристи довго страждали від омани, що написання будь-чого ALL-CAPSвідповідає очевидній вимозі. Це неправда. Суди критикували адвокатуру за те, що вона так само прикидається, і майже всі погоджуються, що написання великими літерами більше заважає читати, ніж змушує. І все ж у більшості форм ліцензії з відкритим вихідним кодом застереження щодо гарантій надаються великими літерами, частково тому, що це єдиний очевидний спосіб виділити це у звичайних текстових файлах LICENSE. Я б вважав за краще використовувати зірочки чи інше зображення ASCII, але цей корабель відплив дуже-давно.
Обмеження відповідальності
За жодних обставин автори чи власники авторських прав не несуть відповідальності за будь-які претензії, збитки чи іншу відповідальність, незалежно від того, чи це договір, правопорушення чи інше, що виникає внаслідок, у зв’язку з Програмним забезпеченням або використанням або іншими операціями в програмне забезпечення.
Ліцензія Массачусетського технологічного інституту дає дозвіл на програмне забезпечення «безкоштовно», але закон не припускає, що люди, які отримують безкоштовні ліцензії, відмовляються від своїх прав на подання до суду, коли щось йде не так і винен ліцензіар. «Обмеження відповідальності», часто в поєднанні з «виключенням відшкодування збитків», схоже на ліцензії, як обіцянки не подавати до суду. Але це захист для ліцензіара від судових позовів з боку ліцензіатів .
Загалом суди обережно розглядають обмеження відповідальності та виключення про відшкодування збитків, оскільки вони можуть перекласти неймовірну кількість ризику з одного боку на інший. Щоб захистити життєво важливий інтерес спільноти в тому, щоб надати людям можливість виправити помилки, заподіяні в суді, вони «суворо тлумачать» відповідальність за обмеження мови, читаючи її проти того, хто захищається нею, де це можливо. Обмеження відповідальності мають бути конкретними, щоб вистояти. Особливо в «споживчих» контрактах та інших ситуаціях, коли особам, які відмовляються від права подати позов, не вистачає досвіду чи переговорної спроможності, суди іноді відмовляються поважати формулювання, які, здавалося, були поховані поза увагою. Частково з цієї причини, частково через силу звички, юристи також схильні надавати обмеження відповідальності великими літерами.
Якщо трохи детальніше, то частина «обмеження відповідальності» є обмеженням суми грошей, яку ліцензіат може подати до суду. У ліцензіях з відкритим вихідним кодом цей ліміт завжди без грошей, 0 доларів США, «без відповідальності». Натомість у комерційних ліцензіях це часто дорівнює сумі ліцензійних зборів, сплачених за останні 12 місяців, хоча це часто обговорюється.
Частина «виключення» перераховує, зокрема, види правових претензій — підстави для подання позову про відшкодування збитків — які ліцензіар не може використовувати. Як і в багатьох, багатьох правових формах, Ліцензія Массачусетського технологічного інституту згадує про «контрактні дії» — за порушення контракту — та «деліктні дії». Деліктні норми – це загальні правила проти необережного або зловмисного заподіяння шкоди іншим. Якщо ви збили когось на дорозі під час текстового повідомлення, ви скоїли правопорушення. Якщо ваша компанія продає несправні навушники, які обпалюють людям вуха, ваша компанія вчинила правопорушення. Якщо договір конкретно не виключає позовів про делікти, суди іноді читають формулювання виключення в договорі, щоб запобігти лише претензіям за договором. Для гарної міри Ліцензія Массачусетського технологічного інституту додає «або інакше», просто щоб вловити дивний закон про адміралтейство чи інший, екзотичний вид правової претензії.
Фраза «виникає внаслідок, унаслідок або у зв’язку з» є повторюваним позначенням, що свідчить про притаманну юрисконструктору тривожну незахищеність. Справа в тому, що на будь-який судовий процес, пов’язаний із програмним забезпеченням, поширюються обмеження та виключення. На випадковий випадок щось може «виникнути», але не «поза» або «у зв’язку з», краще мати всі три у формі, тож запакуйте їх. Неважливо, що будь-який суд змушений розділити волоски в цій частині форми повинні придумати різні значення для кожного, припускаючи, що професійний кресляр не буде використовувати різні слова підряд, щоб означати те саме. Неважливо, що на практиці, коли суди не сприймають обмеження, яке спочатку не сприймається, вони будуть більш ніж готові прочитати механізм дії обмеження. Але я відволікся. Одна і та сама мова фігурує буквально в мільйонах контрактів.
Загалом
Усі ці причіпки схожі на випльовування жуйки по дорозі до церкви. Ліцензія Массачусетського технологічного інституту є класикою права. Ліцензія MIT працює. Це аж ніяк не панацея від усіх бід інтелектуальної власності на програмне забезпечення, зокрема від лиха, пов’язаного з патентами на програмне забезпечення, яке виникло десятиліттями раніше. Але ліцензії в стилі Массачусетського технологічного інституту чудово послужили, виконуючи вузьку мету — скасування клопітких стандартних правил авторського права, купівлі-продажу та договірного права — з мінімальною комбінацією непомітних правових інструментів. У ширшому контексті обчислювальної техніки його довговічність вражає. Ліцензія Массачусетського технологічного інституту пережила і переживе переважну більшість програмного забезпечення, ліцензованого за нею. Ми можемо лише здогадуватися, скільки десятиліть вірної юридичної служби вона прослужить, коли нарешті втратить прихильність. Це було особливо щедро до тих, хто не міг дозволити собі власного адвоката.
Ми бачили, як Ліцензія Массачусетського технологічного інституту, яку ми знаємо сьогодні, є конкретним, стандартизованим набором умов, що нарешті впорядковує хаос випадкових варіацій, характерних для конкретної установи.
Ми побачили, як його підхід до атрибуції та сповіщення про авторські права вплинув на практику управління інтелектуальною власністю для академічних, стандартних, комерційних установ і установ.
Ми бачили, як Ліцензії Массачусетського технологічного інституту надають дозвіл на програмне забезпечення всім, безкоштовно, відповідно до умов, які захищають ліцензіарів від гарантій і відповідальності.
Ми бачили, що, незважаючи на деякі різкі словоблуддя та адвокатську афектацію, сто сімдесят одне маленьке слово може зробити дуже багато юридичної роботи, розчищаючи шлях програмному забезпеченню з відкритим вихідним кодом через густий підлісок інтелектуальної власності та контрактів.
Я дуже вдячний усім, хто знайшов час, щоб прочитати цей досить довгий допис, щоб повідомити мені, що вони вважають його корисним, і допомогти покращити його. Як завжди, я вітаю ваші коментарі електронною поштою , Twitter і GitHub .
Багато людей запитували, де можна прочитати більше або знайти короткі переліки інших ліцензій, як-от GNU General Public License або Apache 2.0. Незалежно від того, що вас постійно цікавить, я щиро рекомендую такі книги:
Розуміння Ендрю М. Сен-Лорана щодо ліцензування відкритого коду та безкоштовного програмного забезпечення , від O'Reilly.
Я починаю з цього, тому що, незважаючи на те, що він дещо застарів, його підхід також найближчий до підходу рядок за рядком, використаного вище. O'Reilly зробив його доступним в Інтернеті .
Heather Meeker Open (Source) for Business
На мій погляд, це, безперечно, найкращий текст про Загальну публічну ліцензію GNU та копілефт загалом. У цій книзі описано історію, ліцензії, їх розвиток, а також сумісність і дотримання вимог. Це книга, яку я позичаю клієнтам, які розглядають або мають справу з GPL.
Ліцензування відкритого коду Ларрі Розена , від Prentice Hall.
Чудова перша книга, також доступна безкоштовно онлайн . Це найкращий вступ до ліцензування відкритого коду та відповідного законодавства для програмістів, які починають з нуля. Цей також дещо застарів у деяких конкретних деталях, але таксономія ліцензій Ларрі та стислий виклад бізнес-моделей з відкритим вихідним кодом витримують випробування часом.
Усе це мало вирішальне значення для моєї власної освіти як юриста з ліцензування відкритого коду. Їхні автори – мої професійні герої. Читайте! — КЕМ
Я ліцензую цю статтю за ліцензією Creative Commons Attribution-ShareAlike 4.0 .