Сравнение на лицензите с отворен код

Кратко : Това подробно ръководство ви дава възможност за ефективно сравнение на лицензите с отворен код. С обясненията за лицензите с отворен код, това трябва да ви помогне да изберете правилния лиценз за отворен код за вашия проект.

Така че, работите върху този страхотен нов проект за известно време - и сте готови сега да направите критичния ход от затворен източник към отворен код .

Тя не изглежда много по-голяма работа, отколкото почистване на източниците и историята на поемане, преди да се премести на хранилището ви в GitHub или Bitbucket…… докато въпросът за лиценза не се появи. Има толкова много възможности за избор. Кой да изберем? И наистина ли наистина имате нужда от лиценз?

Краткият отговор на последния въпрос е лесен: Да, наистина имате нужда от лиценз. Що се отнася до това какъв лиценз ви е необходим, дори мога да направя по-кратък отговор: зависи .

Но ако сте сериозни по отношение на вашия проект, вероятно искате малко повече подробности. Така че прочетете напред - и запомнете: сега влизате в свещената война!

Имам ли нужда от лиценз? А какъв е лицензът?

Лицензът е официално разрешение, предоставено от собственика на някоя Работа ("Лицензорът") на други хора ("Лицензополучателя") и уреждащо как Лицензополучателят има право да използва работата на Лицензодателя.

Това е под формата на договор, с който и двете страни трябва да се съгласят. В днешно време приемането е по-скоро имплицитно: само с използването на някаква работа, вие се съгласявате с неговия лиценз за използване.

Само за да стане ясно, когато пускате собствената си работа, Лицензодателят сте вие . А Лицензополучателят, всеки, който използва вашия код. Най-общо казано, това включва две основни категории: разработчици и крайни потребители .

За да коригираме още няколко термина с думи, като модифицираме Вашата работа, Лицензополучателят създава така наречената Деривативна работа. Не всички лицензи се съгласяват обаче, ако използването на Вашата Работа в по-голяма работа ще го квалифицира като Деривативна работа или не. Както ще видите по-долу, някои лицензи специално разглеждат тези въпроси.

Каква е целта на лиценза?

По принцип, Лицензът е начин Лицензодателят и Лицензополучателят да се споразумеят за правата и задълженията на двамата . Тези права и задължения, свързани с даден лиценз, могат да бъдат всичко - до степента на това, което е позволено от закона . Например, Лицензодателят може да изиска от Лицензополучателя да цитира името си, когато използва своята работа. Или може да разрешите да копирате работата й, но не и да я модифицирате по какъвто и да е начин. Или дори изискват Деривативното произведение да бъде освободено при същите условия като оригиналната работа.

От друга страна, лицензът е начин за защита на лицензополучателя. Чрез ясното посочване как може да използва вашата работа, той не рискува да ви види неочаквано искане за възнаграждение или друга форма на обезщетение за това, че сте използвали работата си. Нещо, което е от решаващо значение за приемането на работата ви.

Така, Лицензът ще защити вашата работа. Ще защити Лицензодателя. Но също ще ви предпази. Искам да кажа лично . Например чрез ограничаване на отговорността на Лицензодателя за потенциални щети, причинени от нейната работа.

А какво, ако изобщо не използвам никакъв лиценз?

При липса на Лиценз, изрично свързан с произведение, важи авторското право по подразбиране за авторството. С други думи, никога не разглеждайте „отсъствието на лиценз“ като имплицитно разрешение за нас да правим каквото искаме с вашата работа. Това е точно обратното: без специален лиценз вие, авторът, не сте се отказали от правата, предоставени от закона.

Но винаги помнете, че Лицензът управлява правата и задълженията. Замисляли ли сте се някога защо толкова много текст от Лиценз съдържа отказ от отговорност, написан във ВСИЧКИ УПОТРЕБНИ БУКВИ за гаранциите, предоставени с продукт - или по-често липсата на гаранция? Това е за защита на собственика на работата срещу скрити гаранции или потребителски предположения. Последното, което искате, е да бъдете съдени като следствие от освобождаването на вашата работа с отворен код!

Мога ли да използвам персонализиран лиценз?

Да, можеш. Но вероятно не би трябвало.

Като договор, Лицензът не може (в повечето юрисдикции? Всички?) Да има предимство пред териториалните закони. Оттук и трудността за прилагане на лицензионните права в един глобализиран свят. Вероятно би било по-лесно (имам предвид по-малко трудно) да се защити „стандартен“ лиценз пред съдия. Всъщност такива случаи вече са защитени в няколко юрисдикции и могат да бъдат цитирани като прецедент. Очевидно е нещо, което не може да се направи с потребителски лиценз.

В допълнение, персонализираните лицензи (понякога с прякор „Vanity Licenses“) могат да създадат несъвместимост с други лицензи, което води до лоша съвместимост на вашето произведение законно.

Мога ли да използвам няколко лиценза?

Да. Много лицензирането - особено Dual-licenseing - не е толкова необичайно. Това е особено вярно, когато искате да изградите бизнес около свободната си работа. В този случай вашият проект вероятно ще бъде пуснат както под някакъв лиценз на FOSS, така и на търговски лиценз.

Друго използване на мулти-лицензиране е да се увеличи съвместимостта, като се позволи работата ви да бъде комбинирана с произведения, публикувани при различни условия или за да отговарят на различни потребителски нужди или изисквания. Това е причината, поради която някои проекти се издават по няколко FOSS лиценза.

Но бъдете предупредени: не всички лицензи са съвместими заедно! Още веднъж бих ви обезсърчил да преоткриете колелото, като останете с добре известни съвместими лицензи, ако искате да отидете по този начин.

Мога ли да променя лиценза „по-късно“?

Да. Собственикът на авторските права носи отговорност за лицензионните условия. Лесно е да промените лиценза, докато сте единственият сътрудник. Но за да вземем крайния пример, ако Линус Торвалд би искал да пусне ядрото на Linux под различен лиценз, той вероятно ще се нуждае първо от съгласието на хилядите участници в този проект. Нещо невъзможно на практика.

За един по-разумен проект, той може да бъде направен. И всъщност това е, както ще видите в някои примери по-долу.

Кой лиценз за отворен код трябва да използвам?

Добре, сега сте убедени, че трябва да използвате стандартен лиценз. Но кой да избере? Окончателният избор зависи от вас. Има много добре направени сравнители, достъпни в интернет, за да ви помогнат в избора ви. Просто да цитирам любимите ми:

  • //oss.ly/licdif
  • //choosealicense.com/ / //choosealicense.com/appendix/
  • //opensource.org/licenses
  • //tldrlegal.com/

Но както винаги с правни въпроси, окончателният отговор ще бъде да прочетете - и да разберете - авторитетния текст на лиценза. Това може да изисква помощ от професионален адвокат. Нещо не съм.

Но това, което мога да направя, е да ви запозная с най-често срещаните лицензи, за да направите първите стъпки.

Общ публичен лиценз на GNU (GPL)

GPL е един от най-популярните лицензи за отворен код. Той идва в няколко версии - но за нов проект трябва да помислите за най-новата, която е GPL 3 към момента на писането.

Поддържайки силен copyleft, GPL е може би най-защитният лиценз за свободен софтуер. Нещо, което може да бъде похвалено или критикувано заради вашата гледна точка. Основната концепция на GPL е каквато и да е деривативна работа трябва да бъде издадена и под GPL.

  • Силно копилефт
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да предоставят източника заедно с Деривативна работа.
  • Производната работа трябва да бъде освободена при същите условия.

Популярни проекти

GPL е естественият лиценз за проектите на Фондацията за свободен софтуер. Включване на инструментите на GNU в сърцето на всяка Linux система. Големи проекти - a fortiori търговски - са склонни да използват GPL заедно с една или няколко други лицензи.

  • Inkscape (векторно изображение): GPLv2
  • Drupal (Система за управление на уеб съдържание): GPLv2
  • MariaDB (Бази данни): GPL v2
  • MySQL (бази данни): GPL и търговски лиценз
  • Qt (платформа за приложения на различни платформи): LGPL, GPL и Commercial - в зависимост от нивото на модулите и споразумението за услуги

Общ обществен лиценз на GNU (LGPL)

GPL е много рестриктивен в смисъл, че принуждава производното произведение да бъде освободено с отворен код при същите условия. Това е особено важно за библиотеките - които са градивни елементи за по-голям софтуер: чрез освобождаване на библиотека под GPL, ще принудите всяко приложение, използващо тази библиотека, да бъде пуснато и като GPL. Нещо, което LGPL адресира.

За библиотеките FSF разграничава три случая:

  • Вашата библиотека прилага стандарт, който се конкурира с несвободен стандарт. В този случай широкото възприемане на вашата библиотека ще помогне на причината за свободния софтуер. FSF предлага доста разрешителен лиценз Apache за този случай (описан по-късно в тази статия).
  • Вашата библиотека изпълнява стандарт, вече реализиран от други библиотеки. В този случай няма никаква полза за свободния софтуер да се откаже изцяло от copyleft. Така FSF препоръчва LGPL.
  • И накрая, ако вашата библиотека не се конкурира с други библиотеки или други стандарти, FSF препоръчва GPL.

Аргументите на ФСС са предимно етични и философски. На практика разработчиците могат да имат други опасения. Особено, ако планират да развият бизнес въз основа на лицензираната работа. Още веднъж, възможността за двойно лицензиране може да бъде разгледана.

  • Слабо копилефт (свързан към динамично свързана библиотека)
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да предоставят източника заедно с Деривативна работа.
  • ако промените Работата, трябва да освободите Променената работа при същите условия.
  • ако използвате Работата, не е необходимо да освободите Деривативната работа при същите условия.

Популярни проекти

  • OpenOffice.org 3 (офис пакет): LGPLv3 - но Apache OpenOffice 4 премина към Apache License 2.0.
  • GTK +, GIMP Toolkit (инструментариум за GUI): LGPLv2.1
  • CUPS (междуплатформена система за печат): GPL или LGPLv2 с изключение за операционните системи на Apple - в зависимост от компонентите.
  • WineHQ (слой за съвместимост с Windows): LGPLv2.1
  • GNU Aspell (Проверка на правописа): LGPLv2.1

Публичен лиценз Eclipse (EPL 1.0)

С по-слабо копиране от LGPL, лицензът Eclipse е по-бизнес-приятелски, тъй като позволява подлицензиране и изграждане на софтуер, направен от лицензиран код EPL и без EPL (дори собственост), при условие че кодът, различен от EPL, е „отделен“ модул [и] на софтуера ” .

В допълнение, EPL добавя допълнителна защита за вносителите на код EPL в случай на съдебни дела / вреди, причинени от търговска оферта, включително тази работа.

  • Слабо копилефт (свързан със софтуерния модул)
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Ако промените Работата, трябва да освободите Променената работа при същите условия.
  • Ако използвате Работата, не е необходимо да освободите Деривативната работа при същите условия.
  • Търговските разпространители на софтуера трябва да защитават или да компенсират първоначалните участници в EPL от съдебни дела / вреди, причинени от търговското предлагане.

Популярни проекти

Очевидно е, че EPL е естественият лиценз за проектите на Фондация Eclipse. Включително популярната Eclipse IDE. Но тя придоби известна популярност отвъд това - особено в света на Java:

  • Clojure (език за програмиране)
  • Graphviz (пакет за визуализация на графиките)
  • Jetty (Application server): двойна лицензия EPL1.0 / Apache License 2.0 след Jetty 7
  • JUnit (Java модул за тестване)

Публичен лиценз на Mozilla (MPL)

Публичният лиценз на Mozilla е лиценз, използван за софтуер, разработен от фондация Mozilla. Но със сигурност не се ограничава само до тази област. MPL има за цел да бъде компромисен етап между строгите лицензи (като GPL) и разрешителните лицензи (като лиценза на MIT).

В MPL "лицензиращата единица" е изходният файл. Лицензодателите нямат право да ограничават правата на потребителите и достъпа до всеки файл, обхванат от MPL. Но един и същ проект може също да съдържа патентовани не-MPL лицензирани файлове. Полученият проект може да бъде освободен под всеки лиценз, при условие че е предоставен достъп до лицензираните MPL файлове.

  • Слабо копилефт (свързан с отделни файлове)
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да осигурят подходящо приписване за работата.
  • Лицензополучателите могат да разпространяват Деривативна работа при различни условия
  • Лицензополучателите не могат да relicense лицензиран от MPL източник
  • Лицензополучателите трябва да разпространяват изходния код, лицензиран с MPL, заедно с тяхната Деривативна работа.

Популярни проекти

  • Mozilla Firefox (уеб браузър), Mozilla Thunderbird (имейл клиент): MPL
  • LibreOffice (офис пакет): MPL2.0
  • H2 Database Engine (база данни): MPL2.0 и Eclipse License 1.0
  • Кайро (2D графичен двигател): MPL 1.1 или LGPLv2.1

Лиценз за Apache 2.0 (ASL 2.0)

С ASL навлизаме в сферата на разрешителните безплатни лицензи. Но дори и FSF предлага Apache License в някои случаи. Лицензът на Apache е разрешителен, тъй като не изисква каквато и да е деривативна работа, която да се разпространява при същите условия. С други думи, това е лиценз без копилефт.

ASL е единственият лиценз, използван за проекти на Apache Software Foundation. Като се счита, че е благоприятна за бизнеса, тя е придобила широко разпространение извън тази организация. Не е необичайно да се видят проекти от корпоративния клас, които да бъдат издадени в рамките на ASL.

  • Други свободни
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да осигурят подходящо приписване за работата.
  • Лицензополучателите могат да разпространяват Деривативна работа при различни условия.
  • Лицензополучателите не трябва да разпространяват изходния код заедно с тяхната Деривативна работа.

Популярни проекти

  • Android (операционна система): ASL 2.0 с някои изключения (особено по отношение на ядрото на Linux)
  • Apache httpd (уеб сървър): ASL 2.0
  • Apache Spark (Клъстерна изчислителна рамка): ASL 2.0
  • Spring Framework (Рамка за корпоративни приложения, базирани на Java): ASL 2.0

Лиценз за MIT

Този е много популярен лиценз. Дори вероятно най-популярната. Поставяйки много малко ограничения за повторна употреба, лицензът на MIT може лесно да бъде свързан с други лицензи, от GPL до лицензи за собственост.

  • Други свободни
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да осигурят подходящо приписване за работата.
  • Лицензополучателите могат да разпространяват Деривативна работа при различни условия
  • Лицензополучателите не трябва да разпространяват изходния код заедно с тяхната Деривативна работа.

Популярни проекти

  • node.js (JavaScript runtime environment): Лиценз на MIT
  • jQuery (клиентска JavaScript библиотека): Лиценз на MIT (до 2012 г., с двойна лицензия MIT / GPL)
  • Atom (текстов редактор): Лиценз на MIT
  • AngularJS (JavaScript заявка рамка): MIT Лиценз
  • SQLAlchemy (SQL инструментариум и Object Relational Mapper за Python): MIT Лиценз

Лицензи за BSD

Лицензът на BSD се предлага в три варианта. Оригиналният 4-клаузен лиценз, „преработеният“ 3-клаузен лиценз и „опростения“ 2-клаузен лиценз. Всички в дух са много близки до лиценза на MIT. И наистина, има много малко практически разлики между 2-клаузната BSD лицензия и лиценза на MIT.

Лицензи за BSD с 3 и 4 клаузи добавят повече изисквания относно повторното използване на името и рекламата. Това е нещо, което трябва да се обмисли, ако искате да защитите вашия продукт или търговска марка.

  • Други свободни
  • Работата е подходяща за търговска употреба.
  • Лицензополучателите могат да променят работата.
  • Лицензополучателите трябва да осигурят подходящо приписване за работата.
  • Лицензополучателите могат да разпространяват Деривативна работа при различни условия.
  • Лицензополучателите не трябва да разпространяват изходния код заедно с тяхната Деривативна работа.
  • Лицензополучателите не могат да използват оригиналното име на автора или търговска марка, за да потвърдят деривативна работа (BSD за 3- и 4- клауза)
  • Лицензополучателите трябва да признаят оригиналния Автор във всички рекламни материали, споменаващи функции или използване на Работата (4-клауза BSD)

Популярни проекти

  • Django (уеб рамка): 3-клауза BSD
  • Redis (хранилище на данни): 3-клауза BSD
  • Ruby (език за програмиране): 2-клауза BSD и персонализиран лиценз
  • Nginx (уеб сървър): 2-клауза BSD
  • NetBSD (Операционна система): 2-клауза BSD - 4-клауза BSD до 2008 година

Последната дума за лицензи с отворен код

Ако дойдете толкова далеч, поздравления! Сега разбирате, лицензирането е наистина огромна и сложна тема. Но си струва да отделите време да изберете правилния лиценз за вашия проект - и да направите този избор по-рано. Това може да ви спести много проблеми по-късно, така че можете да използвате времето и енергията си, за да работите по проекта си, вместо да се занимавате с проблеми, свързани с авторското право или съвместимостта на закона.

Дори ако направих всичко възможно, за да направя тази тема достъпна, не винаги е лесно да обобщим тънкостите на различните лицензи. Освен малкото големи лицензи, представени тук, има десетки други, които се използват повече или по-малко.

Така че, не се колебайте да използвате раздела за коментари по-долу, за да ни кажете какъв е предпочитаният от вас лиценз и защо. Или да спомена някои важни характеристики, които може да съм забравил!

Препоръчано

Как да се определи десен клик Touchpad не работи на Ubuntu 18.04
2019
Unity Gaming Engine пристига в Linux
2019
Как да използвате разширенията на GNOME Shell
2019