Компатибилност лиценце је грешка која се јавља када се лиценца поставља на дело које је заштићено ауторским правом, конкретно, софтверска лиценца, може да садржи контрадикторне захтеве, и њиховим рендеровањем није могуће комбиновати изворни код или садржај неког рада у циљу формирања новог.O'Riordan, Ciaran (2006-11-10).
Пример Претпоставимо да софтверски пакет поседује лиценцу која каже, модификоване верзије морају спомињати њихове програмере у било ком рекламном материјалу, а друга лиценца пакета каже, модификоване верзије не могу да садрже додатне захтеве. Без директне дозволе од стране власника ауторског права ниједан од ова два пакета не би могао да легално дистрибуира зато што овакви захтеви лиценци не могу да буду испуњени у исто време. Тако да би ова два пакета била некомпатибилна у смислу лиценце.
Дефиниције Компатибилност лиценце се може дефинисати на различите начине у зависности од концепта колективног/комбинованог/нагомиланог посла и од изведеног рада. Прва дефиниција компатибилности лиценце колективног рада је дозвољавала коришћење и комбиновање различитих лиценцираних радова.
Снажнија дефиниција, такође коришћена од стране фондације за слободни софтвер,. fsfe.org. укључује могућност промене лиценце. Као најбољи пример, копилефт лиценце захтевају да изведени рад комбинован из кода који је под различитим лиценцама као целина буде прихваћен као копилефт лиценца. мини|400x400px|Компатибилност лиценце: компатибилност за изведене радове властитог кода и спољно развијене лиценце отвореног кода (усвојене од Ека 2005).Välimäki, Mikko (2005). Изведени радови су мешовити кодови, комбиновани радови имају компоненте које су под различитим лиценцама. Здесна налево комбинован рад треба да има јачу раздвојенст између различито лиценцираних делова како би спречио да они постану изведени радови (раздвајање: комбиновано статичким везивањем или раздвајањем изворног фајла тако да се све компоненте налазе у истом процесу и адресном простору, јака раздвојеност: компоненте које су спојене само преко бинарних простора и које се налазе у одвојеним процесима).
Врсте комбинованих радова Комбиновани рад се састоји од више различито лиценцираних делова (избегавајући ре-лиценцирање). Како би се постигао, комбиновани рад такође треба да укључује копилефт лиценциране компоненте (које имају вирусно власништво које потенцијално води ка изведеном раду ), као и да погодне изолационо/раздвајајуће буду задовољене.
Фајлови са индивидуално лиценцираним изворним кодом вишеструких не-реципрочних лиценци (као допусне лиценце или властити код) могу бити раздвојени, док би комбиновано компајлиран програм могао да буде ре-лиценциран (али није неопходно). Таква раздвојеност изворног кода је преслаба за копилефт/реципрочне лиценце (како што је ГПЛ), јер оне поред ре-лиценцирања комплетног рада захтевају и реципрочну лиценцу.
Мало јачи приступ је раздвојеност на бази везивања са бинарним објектним кодом (статичко везивање) са свим компонентама које се налазе у програму у истом процесу и адресном простору. Ово задовољава слаб копилефт/стандардни реципрични комбиновани рад (као они који су ЛГПЛ лиценцирани), али не и јак копилефт/стандардно реципрочни комбиновани рад. Док такво, претежно прихваћено везивање (статичко па чак и динамичко) представља извод јаког копилефтованог рада,Lewis Galoob Toys, Inc. v. MereAggregation "What constitutes combining two parts into one program? License Compatibility Matrix "Use a library[...] linking" on gnu.org (same compatibility of source code use and library use)LGPL on GNU.orgorigins-lgpl "Remember that the GPL requires anything that statically links to any code under the GPL also be placed under the GPL." on freebsd.org постоје посебне алтернативне интерпретације.Linus Torvalds, GPL only modules, linux-kernel mailing list (17 December 2006).Lawrence Rosen, Derivative Works, Linux Journal (1 January 2003).
За комбиноване радове са јаким копилефт модулима је потребна изолација, на пример, за раздвајање програма на његове процесе и то преко бинарног АБИ-а или другим индиректним начинима. Примери су раздвајање Андроидовог простора језгра и корисничког простора преко Бионика, или дистрибуција Линукса које имају власничке бинарне блобове и поред тога што имају јака копилефт језгра.
Компатибилност ФОСС лиценци мини|400x400px|Компатибилност лиценце између обичних лиценци ФОСС софтвера према Дејвиду А. Вилеру (2007): стрелице показују компатибилност, и види се да је већа компатибилност са леве него са десне стране.The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007 Чак и ако су прихваћене, обичне лиценце отвореног кода нису неопходно компатибилне међусобно.Thomas F. Gordon Open Source license compatibility Fraunhofer FOKUS Berlin in December 2009. Тако да је немогуће да се мешају легално (или преко везе) чак и лиценце отвореног кода ако су компоненте доступне под различитим лиценцама. На пример, софтвер који је комбиновао код објављен под верзијом 1.1 Мозилине јавне лиценце (МПЛ) са кодом који је под ГНУ-овом општом јавном лиценцом (ГПЛ) није могао да буде дистрибуиран без нарушавања услове једне од лиценци. То је тако јер су обе лиценце одобрене под Иницијативом отвореног кода и фондацијом за слободни софтвер.. Компатибилност лиценце између копилефт лиценце и неке друге лиценце је често компатибилност у једном правцу. Ова карактеристика чини да копилефт ГПЛ (и већина других копилефт лиценца) буде некомпатибилан са власничким комерцијалним лиценцама као и са не-власничким лиценцама. Ова једносмерна компатибилност је критикована од стране фондације Апач, која је омогућила попустљиву Апач лиценцу која не поседује ову карактеристику. Не-копилефт лиценце као што је ФОСС попустљива лиценца имају мање компликовану интеракцију са другим лицецнама а имају најчешће највећу компатибилност са истим..
ГПЛ компатибилност Како би се смањила пролиферација лиценце и њена некомпатибилност у ФОСС-овом екосистему, неке организације (на пример ФФС) и неки појединци (као што је Дејвид А. Вилер), су се расправљали око тога да је компатибилност широко расрпострањене ГПЛ лиценце заправо карактеристика софтверских лиценци.GPL compatibility on dwheeler.com Већина најобичнијих слободних софтверских лиценци, посебно попустљиве лиценце, као што је првобитна МИТ/Х лиценца, BSD лицецне (у трочланим или двочланим формама, али не у оригиналним четворочланим формама), МПЛ 2.0, и ЛГПЛ, су ГПЛ-компатибилне. Тако да, њихов код може бити комбинован са програмом који је под ГПЛ-ом без икаквог конфликта и новонастала комбинација би имала потпуно примењен ГПЛ (не за друге лиценце).
Када је реч о копилефт софтверским лиценцама, оне нису подразумевано ГПЛ-компатибилне, чак ни ГПЛ верзија 2, сама по себи, није компатибилна са ГПЛ верзијом 3.. gnu.org. Asay, Clark D. "Michigan Telecommunications and Technology Law Review Volume 14 - Issue 22008 The General Public License Version 3.0: Making or Breaking the Foss Movement". law.umich.edu.Као резултат, лиценце нису компатибилне: ако се меша код који се налази под обе ове лиценце, то би нарушило одељак 6 ГПЛ лиценце верзије 2. Ипак, код који је објављен под ГПЛ лиценоцм верзије 2 или више, је компатибилан са верзијом 3 јер га ГПЛ в3 сама по себи подразумева. Међутим, већина софтвера која се налази под ГПЛ лиценцом верзије 2 омогућава коришћење карактеристика новијих верзија ГПЛ-а, али неке од њих имају назнаку да могу да се комбинују са софтвером који се налази под неком другом лиценцом.. 2014-11-20.
Развојни програмер Флеск-а, Армин Ронакер је представио у јулу 2013. године негативан резиме о компатибилности ГПЛ-а у ФОСС-овом екосистему где је закључио: Када је ГПЛ умешан, комплексност лиценцирања постаје загонетка.
Такође, ФСФ је препоручио да звог тога што ГНУ-ова лиценца за слободну документацијуGNU project: Frequently Asked Questions about the GNU Licenses: Why don't you use the GPL for manuals? није компатибилна са ГПЛ-ом, текст лиценциран под ГФДЛ-ом не би требало да буде припојен ГПЛ софтверу. Такође, Дебијан пројекат је одлучио да 2006. године изда резолуцију о коришћењу ГПЛ-ове документације.Debian Project: Resolution: Why the GNU Free Documentation License is not suitable for Debian. ФЛОСС фондација је урадила исто што и Дебијан, 2007. године.FLOSS Manuals foundation: License Change 6 June 2007. 2009. године фондација Викимедије се пребацила са ГФДЛ-а на CC-BY-SA лиценцу као главну лиценцу за њихове пројекте.Wikimedia license update approvalWikipedia + CC BY-SA = Free Culture Win! on creativecommons.org by Mike Linksvayer, June 22nd, 2009
Још један важан пример некомпатибилности ГПЛ-а је ЗФС фајл систем који је лиценциран под CDDL са ГПЛ верзијом 2 Линукс језгра.2.2 What is the licensing concern? on zfsonlinux.com Упркос томе што су и једна и друга верзија слободни софтвери под копилефт лиценцом, ЗФС није дистрибуисан са већим бројем дистрибуција Линукса (осим са FreeBSD-ом и Mac OS-ом), ФСФ је сматрао да CDDL није компатибилна са Линукс језгорм под ГПЛ-ом.Yao: The State of ZFS on Linux September 11, 2014 by jake on lwn.netCDDL on gnu.org Легална интерпретација овог комбинованог рада која конституише изведене радове ГПЛ-ових језгра није недвосмислена и окарактерисана је као контроверзна; постоје алтернативне интерпретације везане за покрет ФСФ.
Ре-лиценцирање за компатибилност Понекад се деси да пројекти буду заглављени звог некомпатибилности лиценце и једини прихватљив начин да се то реши је било ре-лицецирање некомпатибилних делова. Релиценцирање је постигнуто уз одобрење свих укључених развојних програмера и група. Док је у домену слободних и софтвера отворених кодова постизање 100% учинка често немогуће, због великог броја сарадника, Мозилин пројекат за релицецирање је претпоставио да је 95% довољно за релиценцирање комплетне кодне основе.O’Riordan, Ciaran (2006-10-06). Други у ФОСС домену, као што је Ерик С. Рејмонд, су дошли до супротног закључка у вези са захтевима за лиценцирање целе кодне основе.Licensing HOWTO by Eric Steven Raymond&Catherine Olanich Raymond "Changing an existing license [.
Примери релиценцирања Рани пример пројекта који успео да изврши релиценцирање због компатибилности лиценце је Мозила пројекат и њихов Фајерфокс претраживач. Изворни код Нетскејповог комуникатора 4.0 (веб претраживача) је првобитно објављен 1998. године под Нетскејп јавном лиценцом/Мозила јавном лиценцомNetscape Public License FAQ on mozilla.org али је критикован од стране фондације за слободни софтвер и ОСИ-а да је некомпатибилна.On the Netscape Public License by Richard Stallman on GNU.org Око 2001 Тајм Варнер, испробавајући своја права под Нетскејп јавном лиценцом, и на захтев Мозила фондације, је релиценцирао. mozilla.org. цео код који коришћен на Мозили који је био под Нетскејп јавном лиценцом (укључујући код других сарадника) на МПЛ 1.1/ГПЛ 2.0ЛГПЛ 2.1 три лиценце, и тако постао ГПЛ компатибилан.
ВЛЦ пројекат је такође закомпликовао историју лиценце у смислу компатибилности: 2007. године је одлучио због компатибилности не ажурира тек избачену верзију 3 ГПЛ лиценце.Denis-Courmont, Rémi. Пошто је ВЛЦ обрисан са Епл-ове продавнице апликација почетком 2011. године, у октобру 2011. ВЛЦ пројекат је релиценцирао део ВЛЦ библиотеке са ГПЛ вс на ЛГПЛ в2 како би постигао бољу компатибилност.Vaughan-Nichols, Steven. У јулу 2013. године ВЛЦ апликација је поново враћена на Епл-ову продавницу релиценцирана под Мозила јавном лиценцом.VLC under Mozilla public relaunched. on Ars Technica (Accessed 10/10/2013)
Још један пример ГНУ ТЛС пројекта, који је 2011. године прихватио лиценцу ЛГПЛ верзије 3 али је релиценцирао 2013. године на ЛГПЛ верзију 2.1 због великог броја проблема са компатибилношћу лиценце.Version 2.99.4 (released 2011-07-23)[...] ** libgnutls: license upgraded to LGPLv32013-03-14 Nikos Mavrogiannopoulos ([email protected]) * COPYING.