Григор Гачев
Металицензиране
1. Лабиринтът на лицензите
В света на свободния софтуер съществуват много различни лицензи — и това има както предимства, така и недостатъци.
От една страна, програмистите се различават по това каква степен и тип свобода биха дали на продукта си, и съответно се нуждаят от различни лицензи. Съществуват например BSD-тип лицензи, които позволяват напълно свободна употреба на софтуера, без никакви ограничания — и GPL-тип лицензи, които изискват деривативите на софтуера също да бъдат свободни (често те биват наричани copyleft лицензи). Ако програмист не може да намери или създаде лиценз, който отговаря на вижданията им как да се използва продуктът, той може да се откаже да го създаде или обяви за свободен. В това отношение, един широк спектър от лицензи е предимство.
От друга страна, много лицензи не позволяват използване на лицензираните под тях продукти с или в продукти, контролирани от друг лиценз (междулицензово споделяне). Често намеренията зад това са добри — например GNU GPL използва това, за да предотврати обявяването на кода за затворен, което би отнело свободата му. Това обаче е и недостатък за свободния софтуер, тъй като фрагментира богатството на кода му между различните лицензи, и така вреди на една от най-силните му страни — общата база от код.
Често тази бариера бива пренебрегвана — човек може да открие подобно „нелегално“ споделяне на код между различни лицензи в повечето големи пакети свободен софтуер, като средство интегритетът на богатството на кода да бъде запазен. Засега това „пренебрегване на закона“ тревожи твърде малко хора. То обаче е потенциален проблем, и ще е по-добре да го разрешим някак.
Това фрагментиране е неизбежната цена на обективната нужда от различни типове лицензи, и няма как да бъде избягнато напълно. От юридическа гледна точка обаче свободният код вече е прекалено фрагментиран. Повечето от него все още е под един лиценз, GPL, но вече има много подобни на GPL лицензи. Същото е и с BSD-подобните лицензи. Имаме например CDDL, който много прилича на MPL, но е различен, и код под CDDL не може да се използва под GPL. Ако нещата продължават по този начин — а те вървят точно натам — скоро в свободния софтуер може да започнат лицензни войни. А това е последното, от което имаме нужда, и трябва да направим всичко възможно да го избегнем.
Добре де, всеки принос е добре дошъл. Така е при свободния софтуер. И ако (да предположим за момент) Sun иска CDDL да бъде именно несподелящ лиценз, за да предотврати прехвърляне на код от OpenSolaris към Linux, тогава те вероятно няма да пожелаят да променят CDDL. Богатството на свободния софтуерен код обаче трябва да бъде колкото се може по-цялостно. В противен случай губим едно голямо предимство, източник на свобода, ниска цена и качество за всички потребители на свободния софтуер. (Което включва повечето, ако не и всички от нас.)
Един от възможните начини за това може да бъде опит да бъдат убедени авторите на сходни лицензи да създадат общи лицензи, които задоволяват всеки, и да използват един общ лиценз вместо многото. В много случаи обаче това ще бъде невъзможно, а в много други компромисът ще бъде труден и за постигане, и за опазване.
Друг възможен начин е да се предложат споразумения между авторите на лицензи за „кръстосано лицензиране“, което позволява споделянето на код между свободните лицензи. В много случаи обаче това ще бъде безуспешно — създателите на сходни, но несподелящи лицензи сигурно имат причини да ги създадат и направят несподелящи…
Един трети подход, който избягва повечето от тези проблеми, е металицензирането.
2. Основи на металицензирането
Създателят на един свободен софтуер е неговият оригинален носител на авторско право, и контролиращ това право орган. Ако Франк иска неговият код да бъде използваем примерно с всеки несподелящ свободен лиценз, той е в правото си да го лицензира изрично с всеки такъв лиценз. Също така, създателите на свободен софтуер имат изгодата техният код да бъде споделян колкото се може повече, докато това не надхвърли степента на свобода, която биха му дали. Така че от гледна точка на опазването на цялостта на богатството на кода, те са тези, които трябва да могат удобно да го лицензират за когото пожелаят.
На практика обаче това не е лесно. Повечето програмисти не са експерти по лицензите. Списъците с лицензи постоянно еволюират. Ако развиването на код продължи паралелно под два несподелящи лиценза, двата клона не може да бъдат обединени обратно… Тези, а и други проблеми, могат да бъдат разрешени чрез специален тип лиценз — металиценз.
В най-простия си вид металицензът е лиценз, който позволява код да бъде използван под който и да е от лицензите, изброени в определен списък. Малко по-сложен вариант би могъл да включва набор допълнителни изисквания или условия, и би могъл да изяснява отношенията си с лицензите в списъка.
Металицензът би могъл юридически да заобиколи изискването за несподеляне на несподелящите свободни лицензи. Ако например код е лицензиран под металиценз, който позволява използването му под CDDL и GPL, той може легално да бъде включван както в лицензиран под CDDL, така и в лицензиран под GPL софтуер. А ако деривативите на този код са лицензирани под същия металиценз, те също ще са съвместими и с двата лиценза. Тъй като несподелящата клауза в повечето copyleft лицензи е въведена специално за да опазва свободата на кода, а не да го „заключва“ към лиценза, металицензирането на код към повече от един такъв лиценз не би трябвало да противоречи на духа им.
Поддръжката на списъка с лицензите може да бъде поверена на доверен орган, който се грижи да го поддържа в съответствие с оригиналната идея. Така дори ако металицензът е несподелящ, той би позволил използване на кода под всички лицензи, допустими спрямо идеята, и би включвал своевременно нови лицензи, ако те съответстват на идеята му, без да трябва програмистът непрекъснато да следи новостите около лицензи и да прелицензира кода си непрекъснато.
Повечето, или дори всички металицензи биха могли да споделят един или същ основен текст, ако той е добре обмислен, и да се различават само по списъка от позволени лицензи. Това може да позволи също така лесно създаване на специализирани металицензи за случаите, когато стандартните не са подходящи.
Лицензите в списъка могат също да бъдат металицензи. Това позволява създаването на йерархична структура от лицензи на базата на сегашната „плоска“, което ще направи удобно за програмистите избирането на ниво и тип лиценз, които дават на продукта им точно желаната степен и тип свобода. (Това може също и да пообразова компютърните маниаци в типове лицензи — те по природа разбират йерархични структури много по-добре от юридическите термини. :-)
Най-сетне, металицензите могат да бъдат идентифицирани по кодова система, и така лесно да се определя типът и спектърът на металиценза. Кодовете могат лесно да се изведат от мястото на металиценза в йерархията на лицензите.
Всички тези предимства пред използването на специфични лицензи вероятно биха направили металицензите удобни за програмистите. Новонаписан код може да бъде металицензиран вместо, или в добавка към специфичния лиценз; стар код може да бъде пре-лицензиран, ако авторът го позволи. Колкото повече код се металицензира, толкова по-малка ще бъде фрагментацията на богатството на свободния код — и толкова по-добре ще е за всички нас.
3. Примерен образец за металиценз
