Сьогодні я був здивований, дізнавшись про деякі наслідки ліцензії GPL, головним чином, що я не міг користуватися нею так вільно, як думав.
Тепер я знаю.
Що ще я повинен знати, а ширше - що кожен розробник повинен знати про такі юридичні речі?
Ви можете відокремити співробітників, фрілансерів, авторів проектів з відкритим кодом (тощо) або дати більш широку відповідь.
Відповіді:
Дванадцять юридичних міркувань щодо розробки програмного забезпечення
Програмне забезпечення захищено авторським правом, якщо воно стає доступним для широкої громадськості. Більше не потрібно розміщувати повідомлення про авторські права в додатку чи у вихідному коді. Власником авторських прав є автор (и) або компанія, яка платить автору (авторам).
Авторське право на програмне забезпечення може бути призначене власником авторського права, або воно може бути збережене власником, а програмне забезпечення може бути надано користувачеві або користувачам ліцензією власнику.
Бібліотеки, що використовуються в розробці, ймовірно, мають обмеження щодо їх використання та розповсюдження. GPL не робить бібліотеку загальнодоступною, а також той факт, що бібліотека постачається з платформою розробки. Ви повинні прочитати та зрозуміти ліцензію, перш ніж розповсюджувати свою програму. Деякі бібліотеки вимагають виплат роялті, хоча останнім часом це стає рідше.
Позови щодо патентів на програмне забезпечення - це глупості. Звичайно, ви не повинні свідомо порушувати патент на програмне забезпечення. Однак існує невеликий, але реальний шанс, що якась компанія подасть на вас позов за порушення їх патенту. Це може статися, навіть якщо ви розробляєте своє програмне забезпечення самостійно, ви ніколи не чули про патент, а патент охоплює техніку, яка інтуїтивно очевидна і майже повністю не пов'язана з вашим програмним забезпеченням. Не можна багато чого зробити, щоб цього уникнути, враховуючи поточну політику USPTO, окрім придбання страховки. Хороша новина полягає в тому, що патентні тролі, як правило, подають до великих компаній із великими коштами.
Якщо ви використовуєте співробітника або фрілансера для розробки програмного забезпечення, ви повинні письмово пояснити, кому належать авторські права на програму, включаючи вихідний код. Деякі фрілансери та компанії, що розробляють контракти, вважають вихідний код своїм майном, залишаючи компанію залежною від оригінального розробника (розробників). Це законно, якщо це передбачено угодою про розробку.
Якщо у вас є співробітник, який розробляє програмне забезпечення «не вчасно», ви повинні чітко вказати, кому належить це програмне забезпечення, і яке програмне забезпечення працівник повинен мати можливість писати та розповсюджувати за межами компанії.
Якщо ви - співробітник або фрілансер, що розробляє програмне забезпечення, перед початком розробки вам слід чітко вказати, кому належать авторські права на вашу програму. Крім того, ви повинні знати або уточнити, кому належить програмне забезпечення, яке ви пишете у свій час. Деякі компанії мають положення в трудових угодах, що вимагають права власності на будь-яке програмне забезпечення, написане розробником протягом періоду працевлаштування, будь то вдома чи на роботі. Багато компаній мають угод про неконкуренцію в трудових угодах, які обмежують програмне забезпечення, яке працівник може виробляти для розповсюдження за межами компанії. Іноді ці обмеження досить широкі.
Торгова марка - це назва чи символ, а не саме програмне забезпечення. Якщо ви поширюєте програмне забезпечення, вам слід (а) переконатись, що назва вашої програми та її «марка» або дизайн імені не «заплутано схожі» з іншими програмами, та (б) зареєструвати свою торгову марку. Дата першого використання є важливою для вирішення конфліктів, тому вам слід задокументувати, коли програма вперше використовується в комерції.
Коли ви називаєте програму, перевіряйте наявність зареєстрованих торгових марок, а також перевіряйте Google. Додаток із першим використанням імені може мати змогу прийняти ваше ім’я та торгову марку після того, як ваша заявка буде успішною, навіть якщо вона не зареєструвала торгову марку, а ви це зробили.
Коли ви використовуєте або підписуєте контракт чи угоду, переконайтеся, що обидві сторони це розуміють. У трудовій угоді згадування будь-яких потенційно чутливих сфер може запобігти багатьом проблемам пізніше. У угоді про розробку, якщо обидві сторони знають, кому належить вихідний код, або хто відповідає за оновлення, або хто відповідає за технічне обслуговування тощо, що входить у проект розробки, тоді є значно менша ймовірність судового позову після заявки було завершено. У договорі про дистрибуцію переконайтесь, що дистриб’ютор розуміє обов’язки та строк угоди.
Кожне нетривіальне додаток має помилки (або "міркування щодо дизайну" :-)). Будь-яка угода користувача чи угода про розповсюдження повинна чітко вказувати, що ви не несете відповідальності за програмне забезпечення, яке не містить помилок, і від вас не можна чекати виправлення всіх помилок. Поясніть чітко, що зміни, виправлення та оновлення здійснюються за вибором розробника (або з найкращих зусиль), і чітко поясніть, хто платить за виправлення та оновлення.
Навіть після того, як ви проконсультуєтесь з юристом щодо угод про розробку та розповсюдження програмного забезпечення, вам слід прочитати угоди інших програмних компаній і подивитися, що їх юристи придумали.
Я не юрист, і це не юридична порада.
Some freelancers and contract development companies consider the source code their own property, leaving the company dependent on the original developer(s). This is legal if it's in the development agreement.Якщо ви, як фрілансер, не робите, вам краще доплатити. Якщо ви витрачаєте час на розробку чистої базової системи, чому б ви дозволили їм заносити її в якийсь салон, щоб отримати плоди? Ви вклали гроші в кодову базу, саме так ви змусите свої інвестиції окупитися. Також це дозволяє повторно використовувати загальну логіку в іншому місці для наступного клієнта.
Якщо є сумніви, зверніться до адвоката.
Я не юрист, але з часом я зібрав кілька основних правил від юридичних осіб, якими ви можете заощадити час:
.dll/ .soз бібліотеки - це один із способів "використовувати" код LGPL без будь-яких зобов'язань, крім належного повідомлення про авторські права.Часто допомагає зв’язатися з супровідником проекту з відкритим кодом. Вони найкраще можуть порадити вам про початковий намір ліцензії, а також про власні думки щодо відкритого коду. Іноді супровідники готові випустити програмне забезпечення за кількома ліцензіями, щоб допомогти вам. Часто це не так. Залежить від особи, якій належать авторські права.
Проект KDE має зручну матрицю
Я думаю, що Ви шукаєте Юридичний посібник з розробки веб-програм та програмного забезпечення Стівена Фішмана.
Огляд
Дивовижна книга! Відповідає майже на кожне юридичне запитання, яке ви можете собі уявити, і на якесь, про яке ви б ніколи не думали. - Джон Дворжак, журнал ПК
Охоплює кожну уявну деталь, важливу для такого швидко зростаючого та нематеріального середовища. - Підприємець
Ця книга проходить мій особистий тест на правові керівництва - з вищими оцінками, ніж будь-який інший юридичний посібник. - Джефф Дантеманн, редактор журналу PC Techniques
Опис продукту
Захистіть свої права та свою важку працю!
Закони, що стосуються розробки веб-сайтів та програмного забезпечення, є складними та заплутаними, але якщо ви їх не розплутаєте, це може коштувати вам тисяч доларів гонорарів адвокатів та судових позовів.
На щастя, Юридичний посібник з розробки веб-програм та програмного забезпечення розшифровує цю складну область закону, ретельно та зручною для читачів англійською мовою. Він також надає контракти, угоди та юридичні форми на компакт-диску з покроковими інструкціями щодо їх заповнення, щоб ви могли захистити своє програмне забезпечення та веб-сайт, не платячи викупу адвоката.
Скористайтеся Юридичним посібником з розробки веб-програм та програмного забезпечення, щоб дізнатися:
- який правовий захист вам потрібен
- сильні сторони та обмеження кожного виду захисту
- як уникнути порушення
- які положення вам потрібні при складанні угоди
- як отримати дозвіл на використання чужих матеріалів
Ви знайдете повні покрокові інструкції для складання:
- трудові договори
- договори підрядника та консультанта
- угоди про розвиток
- ліцензійні угоди
П’яте видання Юридичного посібника з розробки веб-програм та програмного забезпечення повністю оновлене з урахуванням останньої судової практики та законодавчих змін.
Деякі інші пропозиції:
Якщо фрілансер або підрядник: переконайтеся, що у вас є хороша страховка відповідальності та знаєте, що на неї поширюється.
Наприклад, я не покриваю відповідальність за помилки, допущені в коді, які можуть відкрити номери кредитних карток. Тож я більше не чіпаю ці речі!
Для співробітників: ми повинні мати можливість дати перший рад вашим клієнтам - наприклад, чи можуть вони / ми використовувати потрібний нам компонент у своєму застосуванні?
Для фрілансерів: ми повинні бути в змозі дати настійну пораду вашим клієнтам; і вибрати, які компоненти ми можемо використовувати для програм, які ми розробляємо для них.
Звичайно, ваше слово не так добре, як поради юриста; але ви вже можете допомогти у першому турі; наприклад, сказати "ми точно не можемо цим скористатися, бо це означало б ..."
Зрештою, адвокат знатиме багато про кутові справи - але якщо ви можете трохи допомогти ...
Для співпрацівників OSS: знання деяких відмінностей між безкоштовними ліцензіями може мати значення, якщо вам цікаво, що люди можуть робити з вашим кодом (перерозподіляти? Модифікувати? Використовувати його в комерційній програмі? Використовувати в власній програмі?)
Одна з відповідей стверджувала, що закон не такий, як кодекс. Я не погоджуюсь.
У перші дні IBM платила програмістам за інструкцією. (Хтось, кого я знав, сказав, що він працював із програмістом, який таким чином збагатився. Очевидно, хлопець не знав, як користуватися індексним регістром машини; він написав процедуру нуль пам'яті, яка вручну зберігала нуль у кожній адресі пам'яті.)
Також був час (давно), коли адвокатам платили за слово. Це сприяло популяризації таких практик, як звернення до людей як до "найбільш шанованих таких-то" та інших багатослівностей.
Я щойно прочитав відповідь на SO, де VB.NET 2008 все ще дозволяє номери рядків . Ви все ще можете запустити чистий DOS на сучасному ПК. І в жарті є багато правди, що всі програми COBOL відхиляються від загального предка шляхом поступових змін. У нашій галузі поширена зворотна сумісність та "історичні причини".
Це можна порівняти із сферою права. Є закони, які вносять незначні (або великі) зміни до інших законів. У вас є певна залежність. Є кілька смішних історичних законів (у Гобарті, Тасманія, заборонено чоловікові одягати жіноче плаття після заходу сонця - адже колись засуджені одягалися як жінки та грабували людей), які ніхто не мріяв би виконувати, так само, як у програмному забезпеченні є деякі історичні особливості, якими більше ніхто не користується.
Закони часто мають ненавмисні наслідки (помилки!), Використовуються творчо (хаки!), Містять лазівки (уразливості безпеки!), Деякі з яких є навмисними (бэкдори!), Змінюються (виправлення!) Або скасовуються (видалення!) .
Так, закони (на відміну від кодексу) підлягають тлумаченню. Але я думаю, що це схоже на обслуговування коду. Це допомагає пристосувати закони до нових соціальних норм.
Щоб відповісти прямо на запитання: кожен розробник повинен знати, що закон - це, схоже, на смішно величезний програмний проект, який розроблявся сотні років. (Насправді кожна країна має свій власний проект, і вони вирішують проблеми по-різному.) Теоретично, прочитавши ліцензію, ви зрозумієте, що можна, а що не можна робити зі своїм кодом. Але якщо грамотний програміст не може помітити всі помилки в своєму коді, лише прочитавши його, то який шанс у не-юриста проаналізувати кутові справи та сірі області юридичного документа?
Як і у випадку з вихідним кодом програмного забезпечення, ви зазвичай можете зрозуміти суть юридичного документа, прочитавши його, але якщо вам потрібно знати щось конкретне, зверніться до фахівця .
NOLO (я не працюю на них) видає хороший набір юридичних книг для неспеціалістів.
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
Я відповів би на це так само, як і "що кожен юрист повинен знати про програмування?" Тобто знайте, що жодним чином ви не можете знати глибинне поле настільки добре, щоб зробити більше, ніж найпростіші речі. Отримайте експерта.
Ви повинні знати основні права та обов'язки ліцензії, яку ви збираєтесь використовувати. Це не так складно, і навіть якщо їх багато, потрібно уважно читати лише ті, кого ви збираєтесь використовувати або доторкнутися. Просто прочитайте їх, у більшості випадків вони цілком зрозумілі.
Все, що вам може знадобитися, це залежить. Патентування? Торгові марки? Якщо вам потрібні ці речі, швидше за все, ви перебуваєте в компанії і у вас є юридичний відділ, який зробить це за вас.
Я завжди міг би припустити, що розробники проекту хочуть, щоб будь-яке програмне забезпечення, що використовує їх роботи, випускалося за точно такою ж ліцензією. Прочитайте їх поширені запитання та юридичні сторінки, щоб отримати додаткову інформацію, і не соромтеся зв’язуватися з розробниками / супровідниками, якщо ви все ще не впевнені.
Якщо ви хочете допомогти зрозуміти деталі ліцензійної угоди, поговоріть з юристом.
6.Якщо у вас є працівник, який розробляє програмне забезпечення "не в режимі", ви повинні чітко вказати, кому належить> це програмне забезпечення, і яке програмне забезпечення працівник повинен мати можливість писати та розповсюджувати за межами компанії.
право на свободу слова, як це зазначено в більшості конституцій (зокрема, якщо розробники роблять безкоштовні безкоштовні сеанси без вихідних), може спричинити жахливі збої в судах
Закон не схожий на кодекс. Це не дуже чітко визначений набір кроків і правил, які можна однозначно зрозуміти.