GPL vs MIT vs Apache: ఏ licence ఎప్పుడు ఎంచుకోవాలి?

GPL vs MIT vs Apache: ప్రతి licence మీపై విధించే బాధ్యతలు

GPL, MIT మరియు Apache 2.0 ఒకే ప్రశ్నకు వేర్వేరు విధాలుగా సమాధానం ఇస్తాయి: మీరు software ను ఇతరులకు అందించినప్పుడు, వారికి మీ బాధ్యత ఏమిటి? MIT ప్రకారం copyright notice ఇవ్వడం తప్ప మరేమీ అవసరం లేదు. Apache 2.0 ప్రకారం ఆ notice తో పాటు, code ను ఉపయోగించే ప్రతి ఒక్కరి మధ్య patent హక్కులకు సంబంధించిన ఒప్పందం కూడా ఉంటుంది. GPL ప్రకారం మీరు ఆధారంగా తీసుకున్న software పై నిర్మించినదాని source code ను, మీరు పొందిన అదే licence కింద, public చేయాలి.

మీరు నిర్వహించే project ఒకరోజు తన licence ను మార్చుకుని రెండు భాగాలుగా విడిపోయే వరకు ఇది lawyers కోసం ఉన్న ప్రశ్నలా కనిపిస్తుంది. ఆ తర్వాత ఇది operations కు సంబంధించిన ప్రశ్న అవుతుంది. మీకు ఎంచుకోవడానికి రెండు package repositories ఉంటాయి. పరస్పరం మాట్లాడటం ఆపేసే client libraries ఉంటాయి. ఈ guide licences మరియు వాటి mechanics గురించి మాత్రమే వివరిస్తుంది; వాటిని రూపొందించిన movement గురించి కాదు. అందువల్ల ప్రతి section చివరికి upgrade ను అమలు చేయాల్సిన మీలాంటి వ్యక్తిపై దాని ప్రభావం వద్ద ముగుస్తుంది.

GPL ఎందుకు ఉంది: ఎవరికీ మరమ్మతు చేయడానికి అనుమతి లేని printer

1980 ప్రాంతంలో MIT Artificial Intelligence Lab కు Xerox 9700 laser printer వచ్చింది. అంతకుముందు ఉపయోగించిన printer కోసం lab సాఫ్ట్‌వేర్‌కు patch చేసి, మీ job jam అయినప్పుడు అది మీకు తెలియజేసేలా చేసింది. కొత్త printer కోసం source code అందుబాటులో లేదు. Nondisclosure agreement కారణంగా source code ఇవ్వాలన్న అభ్యర్థనను తిరస్కరించారు. అప్పటికి labలో programmer గా ఉన్న Richard Stallman, ఈ తిరస్కరణను ఒక చెడు అనుభవంగా కాకుండా సాధారణ పరిస్థితిగా పరిగణించారు. 27 September 1983న GNU project ను ప్రకటించారు.

Copyleft అనేది copyright law ఆధారంగా ఏర్పడింది; దానికి వ్యతిరేకంగా కాదు. సాధారణంగా, ఇతరుల code ను copy చేయడానికి మీకు ఎలాంటి హక్కు ఉండదు. GPL ఆ హక్కును ఒక షరతుతో ఇస్తుంది: మీరు program ను మరొకరికి ఇస్తే, అదే నిబంధనల ప్రకారం source code ను కూడా ఇవ్వాలి. అప్పుడు ఆ వ్యక్తి lab చేయలేకపోయిన పనిని చేయగలరు. Licence లేకపోతే మొదటినుంచే మీకు అనుమతి ఉండదు కాబట్టి, ఈ షరతును చట్టపరంగా అమలు చేయవచ్చు.

Stallman మొదట GNU Emacs కోసం licence రాశారు. తరువాత దాన్ని సాధారణ రూపంలోకి మార్చి, 25 February 1989న GPL version 1 గా విడుదల చేశారు. GPL version 2 June 1991లో వచ్చింది. మీరు నడిపే చాలా system software ఇప్పటికీ ఈ licence కిందనే ఉంది. Libraries కోసం Lesser GPL వచ్చింది. దాంతో copyleft library ని ఏ licence కింద ఉన్న program అయినా link చేయవచ్చు. ఆ program మొత్తం GPL పరిధిలోకి రావాల్సిన అవసరం ఉండదు.

GPL self-hoster పై ఎలా ప్రభావం చూపుతుందో ఒక ముఖ్యమైన అంశం నిర్ణయిస్తుంది. ఈ బాధ్యత use పై కాకుండా distribution పై ప్రారంభమవుతుంది. మీరు GPL program ను మార్చి, మీ స్వంత server పై నడిపి, దాని ద్వారా public కు service అందించవచ్చు. మీరు దాని copy ని ఎవరికీ ఇవ్వనందున, ఎవరికీ source code ఇవ్వాల్సిన బాధ్యత ఉండదు. AGPL ఉనికికి ఇదే కారణం.

ఉదార లైసెన్స్ సంప్రదాయం: BSD, తరువాత MIT

Berkeley భిన్నమైన మార్గాన్ని ఎంచుకుంది. Computer Systems Research Group తన Unix పనిని, copyright notice ను అలాగే ఉంచాలని మరియు ఎలాంటి warranty ఇవ్వబడదని స్పష్టంగా పేర్కొన్న licence కింద విడుదల చేసింది. అసలు version లో నాలుగు clauses ఉన్నాయి. అందులో నాలుగోది advertising clause. Software లక్షణాలను ప్రస్తావించే ప్రతి ప్రకటనలో University కు acknowledgement ఇవ్వాలని అది కోరింది. ఈ విధానం విస్తరించదగినది కాదు. NetBSD యొక్క 1997 version లో 75 వేర్వేరు acknowledgements ఉన్నాయని Stallman లెక్కించారు. UC Berkeley తన Office of Technology Licensing కు చెందిన William Hoskins రాసిన లేఖ ద్వారా 22 July 1999న ఆ clause ను తొలగించింది.

మిగిలింది 3-clause BSD licence. ఇది contributors పేర్లను మీ product కు endorsement గా ఉపయోగించడాన్ని నిషేధిస్తుంది. 2-clause version ఆ నిబంధనను కూడా తొలగిస్తుంది. MIT licence text 1980s లో MIT నుంచి వచ్చింది. అక్కడ అది X Window System కు వర్తించింది. ఆచరణలో ఇది 2-clause BSD చేసే పనినే చేస్తుంది.

ప్రేరణలు భిన్నంగా ఉన్నాయి. Public money తో నిధులు పొందిన ఒక university తన పనిని companies సహా ప్రతి చోటా ఉపయోగించాలని కోరుకుంది. GNU project మూసివేయలేని commons ను కోరుకుంది. రెండు వైఖరులూ నిజాయితీతో కూడినవే. రెండింటికీ ఒక failure mode ఉంది. Permissive code ను private code గా మార్చుకోవచ్చు. అప్పుడు మీకు తిరిగి ఏమీ రాకపోవచ్చు. ఆ షరతును తమ lawyers అంగీకరించని companies copyleft code ను తిరస్కరిస్తాయి.

Berkeley నుంచి వచ్చే రెండో పాఠం ఉంది. ఈ post మళ్లీ మళ్లీ దానికే తిరిగి వస్తోంది. AT&T's Unix System Laboratories, BSD code పై 1992లో Berkeley Software Design పై lawsuit దాఖలు చేసింది. ఈ కేసు 1994 ప్రారంభంలో settlement తో ముగిసింది. రెండు సంవత్సరాల పాటు BSD పై build చేయడం సురక్షితమా అనే విషయం ఎవరికీ నిశ్చయంగా తెలియలేదు. Linux పెరుగుతున్న సమయంలో adoption నిలిచిపోయింది. Missing feature కంటే legal uncertainty adoption ను వేగంగా ఆపుతుంది.

Apache 2.0లో patent grant ఎందుకు చేర్చబడింది

Apache Group యొక్క మొదటి licence కూడా అదే advertising సమస్య కలిగిన BSD 4-clause derivative. 2000లో వచ్చిన Version 1.1 ఆ clause ను తొలగించింది. January 2004లో ప్రచురించిన Version 2.0 మాత్రం చిన్న మార్పు కాదు; అది పూర్తిగా పునర్రచించబడింది.

ముఖ్యమైన చేర్పు patents. MIT మరియు BSD licences వాటి గురించి అసలు ఏమీ చెప్పవు. ఒక contributor తన code కోసం మీకు స్పష్టమైన copyright అనుమతి ఇవ్వవచ్చు. అదే సమయంలో ఆ code చేసే పనికి వర్తించే patent అతని వద్ద ఉండవచ్చు. ఆ code ఉపయోగించే వ్యక్తులపై అతను దావా వేయవచ్చు. Apache 2.0 ఈ లోపాన్ని తొలగిస్తుంది: ప్రతి contributor తన contribution ను కవర్ చేసే patent licence ను మంజూరు చేస్తాడు. ఆ పని తన patents ను ఉల్లంఘిస్తుందని పేర్కొంటూ ఎవరైనా దావా వేస్తే, ఆ వ్యక్తి ఆ పని కోసం పొందిన తన patent licence ను కోల్పోతాడు. ఈ రక్షణ పరస్పరంగా ఉంటుంది. అందువల్ల ఆచరణలో ఎవరూ దావా వేయరు.

2.0లో మిగిలిన మార్పులు పరిపాలనా అంశాలకు సంబంధించినవి. అందుకే కంపెనీలు దీనిని ఇష్టపడతాయి. నిర్దిష్టమైన NOTICE file ఉంటుంది. కాబట్టి attribution మొత్తం source treeలో చెల్లాచెదురుగా ఉండకుండా ఒకే చోట ఉంటుంది. ప్రతి source fileలో licence textను మళ్లీ చేర్చాల్సిన అవసరం లేకుండా reference ద్వారా licenceను వర్తింపజేయవచ్చు. Contributions స్పష్టమైన terms ద్వారా కవర్ అవుతాయి. Trademarks ఇందులో భాగం కావు. Apache 2.0 dependencyకి సంబంధించిన legal reviewలో అడగాల్సిన ప్రతి ప్రశ్నకు textలోనే సమాధానం ఉంటుంది. అందువల్ల approval ఒక సాధారణ ప్రక్రియగా మారుతుంది. "corporate default" అనే పదానికి ఎక్కువగా ఇదే అర్థం.

GPLv3 ఏమి మార్చింది, Linux ఎందుకు GPLv2 పైనే కొనసాగింది

TiVo Linux నడిచే video recorder ను విడుదల చేసి, GPLv2 అవసరాల ప్రకారం kernel source ను ప్రచురించింది. అయితే boot సమయంలో hardware cryptographic signature ను తనిఖీ చేసి, తాను గుర్తించని kernel ను నడపడానికి నిరాకరించింది. మీరు source ను చదవగలిగారు, దాన్ని మార్చగలిగారు, compile చేయగలిగారు. కానీ అది వచ్చిన device పైన దాన్ని నడపలేకపోయారు. License అక్షరార్థ అవసరాలు నెరవేరినా, దాని ఉద్దేశం విఫలమైంది. ఈ పద్ధతికి తరువాత tivoisation అనే పేరు వచ్చింది.

29 June 2007న ప్రచురించిన GPL version 3 దీనికి నేరుగా సమాధానం ఇచ్చింది. Consumer device లో binary ను పంపిణీ చేసినప్పుడు, "Installation Information" ను కూడా అందించాలి. ఇందులో మార్చిన version ను install చేసి, అది నడిచేలా చేయడానికి అవసరమైన keys లేదా instructions ఉంటాయి. Version 3 స్పష్టమైన patent grant ను కూడా జోడించింది. November 2006లో Microsoft మరియు Novell మధ్య జరిగిన patent agreement కు ప్రతిస్పందనగా రాసిన terms ను, Apache 2.0తో one-way compatibility ను కూడా చేర్చింది.

Linux ఈ మార్పును అనుసరించలేదు. Kernel కేవలం GPL version 2 కింద మాత్రమే ఉంది. అందులో "or any later version" అనే escape clause లేదు. దాని COPYING file కూడా ఇదే విషయాన్ని చెబుతుంది. Signed hardware పై anti-tivoisation terms ను Linus Torvalds బహిరంగంగా వ్యతిరేకించారు. అయితే ఈ విభేదం కంటే practical barrier పెద్దది. Kernel కు వేలాది copyright holders ఉన్నారు. అందరూ అంగీకరించినా, relicensing కు అవసరమైన permissions ను ఎవరూ సమీకరించలేరు. ఒక project కు లభించగల అత్యంత బలమైన రక్షణ ఈ ఒక్క వాస్తవమే. ఒకే company యాజమాన్యంలో ఉన్న project ను పరిశీలించేటప్పుడు దీన్ని గుర్తుంచుకోవాలి.

2007లో వచ్చిన మరో license మీకు మరింత ముఖ్యమైనది. అదే సంవత్సరం Novemberలో ప్రచురించిన GNU Affero GPL version 3, network ద్వారా program తో పరస్పర చర్య చేసే వ్యక్తులకూ source obligation ను విస్తరించింది. ప్రజల కోసం మార్చిన AGPL service ను నడిపితే, ఆ users కు source ను అందించాలి. అందుకే self-hosted web software లో చాలా భాగం AGPL కింద ఉంటుంది. Nextcloud ఒక ఉదాహరణ. మీరు Nextcloud కు self-hosted ప్రత్యామ్నాయాలను పోల్చుతున్నట్లయితే, ప్రతి candidate repository లోని license line, దాని feature list కంటే వచ్చే ఐదు సంవత్సరాల గురించి ఎక్కువ సమాచారాన్ని ఇస్తుంది.

మీరు వాస్తవంగా ఏ licenses ను కలిపి ఉపయోగించవచ్చు?

Compatibility permissive license నుంచి copyleft license వైపు మాత్రమే పనిచేస్తుంది.

• MIT మరియు BSD code ను closed product తో సహా ఏ project లోనైనా చేర్చవచ్చు.
• Apache 2.0 code ను GPLv3 project లో చేర్చవచ్చు. కలిపిన work GPLv3 కింద ఉంటుంది.
• Apache 2.0 code ను GPLv2-only project లో చేర్చలేరు. దాని patent termination మరియు indemnity నిబంధనలు అదనపు షరతులు. GPLv2 ప్రకారం మీరు అలాంటి షరతులను జోడించలేరు. FSF మరియు ASF రెండూ ఈ నిర్ణయాన్ని ప్రచురించాయి.
• GPL code ను మీరు permissive license కు మార్చలేరు. అది copyright holders మాత్రమే చేయగలరు. అందువల్ల వారు ఎవరో తెలుసుకోవాల్సిన ప్రశ్న మళ్లీ ముందుకు వస్తుంది.

రిలైసెన్సింగ్ యుగం: SSPL, BUSL మరియు అవి కానివి

దీనికి కారణం వాణిజ్య ప్రయోజనం. ఒక కంపెనీకి ఒక ఉత్పత్తిపై copyright ఉంటుంది. ఒక cloud provider అదే ఉత్పత్తిని managed service గా పెద్ద స్థాయిలో విక్రయిస్తూ, తిరిగి చాలా తక్కువ సహకారం అందిస్తుంది. దీన్ని ఆపడానికి కంపెనీ licence ను మారుస్తుంది. Redis Labs 2018 ఆగస్టులో మొదటి స్పష్టమైన చర్య తీసుకుంది. తన అనేక modules కు Apache 2.0 పై Commons Clause ను జోడించింది. 2018 అక్టోబర్ 16న MongoDB కూడా AGPLv3 నుంచి Server Side Public License కు మారింది.

SSPL అనేది ఒక section ను తిరిగి రాసిన AGPL. మీరు ఆ program ను third parties కు service గా అందిస్తే, దాన్ని అందించడానికి ఉపయోగించే ప్రతిదాని source ను publish చేయాలి. అందులో దాని చుట్టూ ఉన్న management మరియు orchestration software కూడా ఉంటాయి. ఆ బాధ్యతకు స్పష్టమైన పరిమితి లేదు. ఏ కోర్టు కూడా దాన్ని ఇంకా పరీక్షించలేదు. OSI ఈ licence ను ఎప్పుడూ ఆమోదించలేదు. MongoDB తన application ను 2019 మార్చిలో ఉపసంహరించుకుంది. Debian కూడా 2018 డిసెంబరులోనే SSPL software తన archive లో ఉండకూడదని తెలిపింది. 2019 జనవరిలో Fedora ఈ licence free కాదని నిర్ణయించింది. ఆ తరువాత Red Hat, Fedora మరియు Red Hat Enterprise Linux నుంచి MongoDB ను తొలగించింది. Relicence యొక్క ప్రత్యక్ష ఫలితం ఇదే: distribution ఆ software ను package చేయడం ఆపేస్తుంది. అందువల్ల మీ upgrades ఇప్పుడు vendor repository నుంచి, vendor నిర్ణయించిన schedule ప్రకారం వస్తాయి.

Business Source License వేరే విధానం. ఇది MariaDB founders నుంచి వచ్చింది. Version 1.1 2017 నాటిది. ఇది copyleft కాదు. ఇది open source కూడా కాదు. Source public గా ఉంటుంది. Vendor ప్రత్యేకంగా మినహాయించిన use తప్ప మిగతా ఉపయోగం ఉచితం. సాధారణంగా ఆ మినహాయింపు, పోటీ hosted service ను నడపడం. ప్రతి release, ఆ release తర్వాత గరిష్ఠంగా నాలుగు సంవత్సరాల్లో వచ్చే change date నాడు నిజమైన open source licence కు స్వయంచాలకంగా మారుతుంది. మారే licence GPLv2-compatible అయి ఉండాలి. HashiCorp 2023 ఆగస్టు 10న Terraform మరియు తన ఇతర products ను BUSL 1.1 కు మార్చింది. Outline కూడా దీన్ని ఉపయోగిస్తుంది. మీరు self-hosted Notion ప్రత్యామ్నాయాల నుంచి ఎంచుకుంటే ఈ విషయం తెలుసుకోవడం ఉపయోగకరం: మీ స్వంత team కోసం దాన్ని నడపడం అనుమతించబడుతుంది. దానిపై service నిర్మించడం అనుమతించబడదు.

ఏ licence కూడా మోసపూరితమైనది కాదు. రెండూ తాము source available అని స్పష్టంగా చెబుతాయి. OSI నిర్వచనం ప్రకారం ఏదీ open source కాదు. ఈ తేడా, అది లక్ష్యంగా పెట్టుకున్న cloud provider పై కాకుండా, మీపై ప్రభావం చూపుతుంది.

OpenSearch: licence fork వల్ల ఆపరేటర్‌కు అయ్యే వ్యయం

Elastic 14 January 2021న Elasticsearch మరియు Kibana, release 7.11 నుంచి Apache 2.0ను వదిలి SSPL లేదా Elastic Licenseలో ఒకదాన్ని ఎంచుకునే విధానానికి మారుతాయని ప్రకటించింది. Version 7.10.2 చివరి Apache 2.0 release. సుమారు ఒక వారం తరువాత AWS, రెండింటికీ Apache 2.0 forkను సృష్టించి నిర్వహిస్తామని తెలిపింది. 12 April 2021న ఆ forkకు OpenSearch అని పేరు పెట్టారు; Kibana పేరును OpenSearch Dashboardsగా మార్చారు. OpenSearch 1.0, Elasticsearch 7.10.2 మరియు Kibana 7.10.2 ఆధారంగా నిర్మించబడి, 12 July 2021న సాధారణ వినియోగానికి అందుబాటులోకి వచ్చింది.

Clusters నడిపే వారికి దాని వ్యయం ఎలా పడిందో చూడండి. Package పేర్లు మరియు repositories మారాయి. Runbookలోని ప్రతి Kibana సూచనను OpenSearch Dashboardsగా మార్చాల్సి వచ్చింది. Plugin పేర్లు మారాయి. తరువాత ఈ విభజన application codeకు చేరింది: Elastic అధికారిక client librariesలో version 7.13 నుంచి, client తాను ఏ softwareకు connect అయిందో తనిఖీ చేసి, Elasticsearch కాని దేనితోనైనా కొనసాగడానికి నిరాకరిస్తుంది; server unknown product అని నివేదిస్తుంది. మీరు పనిచేయని ఒక కంపెనీ తీసుకున్న licence నిర్ణయం, మీ స్వంత applicationలో failing callగా ప్రత్యక్షమైంది.

ఆ తరువాత ఈ కథ మరో రెండు సార్లు మారింది. 29 August 2024న Elastic, మూడవ licence ఎంపికగా AGPLv3ను చేర్చింది. అందువల్ల ప్రస్తుత Elasticsearch మళ్లీ OSI-approved open source అయింది. 16 September 2024న AWS, OpenSearchను Linux Foundation ఆధ్వర్యంలోని OpenSearch Software Foundationకు బదిలీ చేసింది. దీనివల్ల ఆ forkకు ఒకే కంపెనీకి చెందని governance home లభించింది. విభజన జరిగిన ఐదు సంవత్సరాల తరువాత రెండు projects కూడా open sourceగానే ఉన్నాయి, రెండూ నిర్వహించబడుతున్నాయి, మరియు August 2026 నాటికి OpenSearch 3.x seriesలో ఉంది.

ఇదే చివరి పాఠం. Licence తిరిగి వచ్చినా fork అలాగే మిగిలింది. ఒక ecosystemలో ప్రతి దానికి రెండు versions ఏర్పడిన తరువాత, paperworkను వెనక్కి మార్చడం ద్వారా వాటిని మళ్లీ కలపలేరు.

Relicence వల్ల కలిగే నష్టాన్ని నిర్ణయించే సంఖ్య, announcement నుంచి మీరు వాస్తవంగా deploy చేయగల stable fork వరకు ఉన్న వ్యవధి.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

క్రింద ఇచ్చిన తేదీలను ఉపయోగించి, ప్రతి వ్యవధిని vendor public announcement నుంచి fork మొదటి stable release వరకు లెక్కించాం. OpenSearch 1.0కు 179 రోజులు పట్టాయి. ఎందుకంటే ఆ forkకు పేరు మార్చి, ముందుగా copy చేసుకోగల fork ఏదీ లేకుండానే దాన్ని మళ్లీ నిర్మించాల్సి వచ్చింది. OpenTofuకు 153 రోజులు పట్టాయి. Valkeyకు 27 రోజులు పట్టాయి. అది Redis 7.2.4 నుంచి fork అయి, protocol మరియు on-disk formatను ఒకే విధంగా కొనసాగించింది. ఇందులో ఉపయోగకరమైన విషయం దిశ: ఇప్పుడు నమ్మదగిన fork కొన్ని వారాల్లోనే అందుబాటులోకి వస్తుంది. మొదటి రోజు నుంచే foundation మరియు చెల్లింపు పొందే maintainers కూడా ఉంటారు.

Valkey మరియు OpenTofu: అదే నమూనా, మరింత వేగంగా

Redis Ltd 20 March 2024న Redis ను 3-clause BSD licence నుంచి RSALv2 లేదా SSPLv1లో ఒకదాన్ని ఎంచుకునే విధానానికి మార్చింది. ఎనిమిది రోజుల తరువాత Linux Foundation Redis 7.2.4 నుంచి fork చేసి, BSD 3-clause licence కింద కొనసాగుతున్న Valkeyను ప్రకటించింది. Valkey 7.2.5 16 April 2024న విడుదలైంది. ఇందులో అదే protocol మరియు అదే data files ఉన్నాయి. అందువల్ల చాలా మంది operators కోసం migration అనేది package name మార్చడానికే పరిమితమైంది. తరువాత Redis, May 2025లో Redis 8లో AGPLv3ను మూడవ ఎంపికగా చేర్చింది. OSI నిర్వచనం ప్రకారం దాంతో అది మళ్లీ open source అయింది. అయితే Valkey తన స్వంత governance కింద కొనసాగుతోంది. ఈ పరిణామాల నమూనా Elasticsearchతో చాలా దగ్గరగా సరిపోతుంది.

Terraform కూడా ఇదే మార్గాన్ని అనుసరించింది, అయితే ఒక అదనపు అధ్యాయంతో. OpenTofu చివరి Mozilla Public License 2.0 release నుంచి fork అయింది. ఇది September 2023లో Linux Foundationలో చేరి, 10 January 2024న 1.6.0ను విడుదల చేసింది. 3 April 2024న HashiCorp న్యాయవాదులు ప్రాజెక్ట్‌కు cease and desist letter పంపారు. BUSL-licensed Terraform releaseలోని codeను forkలో copy చేశారని వారు ఆరోపించారు. OpenTofu 11 April 2024న వివరణాత్మక సమాధానాన్ని ప్రచురించి, ఆ ఆరోపణను ఖండించింది. రెండు ప్రాజెక్ట్‌లకు ఉమ్మడిగా ఉన్న MPL-licensed చరిత్ర నుంచే వివాదాస్పద code వచ్చిందని వివరించింది. ప్రజలకు అందుబాటులో ఉన్న సమాచారంలో ఆ తరువాత మరేమీ జరగలేదు. ఆ సంఘటనలో గుర్తుంచుకోవాల్సిన అసలు ప్రమాదం ఇదే: ఒక ఆరోపణ మాత్రమే adoptionను ఒక quarter పాటు నిలిపివేయగలదు. ముప్పై సంవత్సరాల క్రితం Berkeley lawsuit కలిగించిన ప్రభావం కూడా ఇదే.

ప్రతి fork licence మార్పుతో ప్రారంభం కాదు. Gitea అభివృద్ధి ఒక కంపెనీ ఆధీనంలోకి వెళ్లిన తరువాత, 2022లో Forgejo, Gitea నుంచి fork అయింది. ఇది licensing సమస్య కాకుండా governance వివాదం. Forgejo తన version 8 series వరకు MIT కిందే కొనసాగింది. తరువాత 2024లో version 9.0 నుంచి GPLv3 or laterకు relicense అయింది. అందువల్ల దాని codeను వాణిజ్య నియంత్రణలో ఉన్న productలోకి తిరిగి చేర్చడం సాధ్యం కాదు. మీరు self-hosted Git server ఎంపికలను పరిశీలిస్తున్నట్లయితే, ఒకే codebaseకు చెందిన రెండు philosophiesకు ఈ జంటే అత్యంత స్పష్టమైన ప్రస్తుత ఉదాహరణ.

ఏదైనా స్వీకరించే ముందు నిర్వహించాల్సిన పరీక్ష

మొదటి install తర్వాత కాకుండా, దానికి ముందే నాలుగు ప్రశ్నలు అడగాలి.

1. Copyright ఎవరి వద్ద ఉంది? ప్రతి copyright holder నుంచి అనుమతి అవసరం కాబట్టి, వందలాది స్వతంత్ర contributors ఉన్న మరియు హక్కుల బదలాయింపు జరగని project ను వాస్తవంగా relicence చేయలేరు. ఒకే company వద్ద అన్ని హక్కులు ఉన్న project ను board meeting లో relicence చేయవచ్చు.
2. CLA ఉందా? అది ఏ హక్కులను ఇస్తుంది? Company తనకు నచ్చిన ఏ నిబంధనల కిందైనా మీ contribution ను relicence చేయడానికి అనుమతించే contributor licence agreement, పై relicence ఉదాహరణలన్నింటి వెనుక ఉన్న ఖచ్చితమైన mechanism. Linux kernel 2004లో స్వీకరించిన sign-off line అయిన DCO (developer certificate of origin) ఎలాంటి హక్కులనూ బదిలీ చేయదు. Company విక్రయించబడే అవకాశం ఉన్నందున, company వద్ద ఉన్న CLA కంటే foundation వద్ద ఉన్న CLA మరింత సురక్షితం.
3. Trademark ఎవరి సొంతం? Elastic, Elasticsearch పేరును తన వద్దే ఉంచుకుంది. అందువల్ల fork తన పేరును మార్చుకోవాల్సి వచ్చింది. Kibana గురించి ఉన్న ప్రతి runbook ను కూడా తిరిగి రాయాల్సి వచ్చింది.
4. ప్రత్యేకంగా మీకు relicence చేయడానికి ఎంత ఖర్చవుతుంది? Data format, client libraries, మీరు తిరిగి రాయాల్సిన configuration, అలాగే ఇప్పటికే compatible fork ఉందా లేదా అనే విషయాలను లెక్కించండి.

ఈ విషయాల్లో కొంత భాగానికి రెండు commands కొన్ని సెకన్లలో సమాధానం ఇస్తాయి.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

ప్రతి Debian మరియు Ubuntu package, /usr/share/doc/<package>/copyright వద్ద ఒక file ను అందిస్తుంది. మీరు install చేసిన version యొక్క licence ను అది నమోదు చేస్తుంది; project ప్రస్తుతం ఉపయోగిస్తున్న licence ను కాదు. Ubuntu 24.04లో bash కోసం ఆ file GNU General Public License version 3 అని చూపిస్తుంది. రెండో command ను source checkout లో అమలు చేస్తే licence file చరిత్రను స్వయంగా చూడవచ్చు. గత రెండు సంవత్సరాల్లో అక్కడ జరిగిన commit ను project పై ఏదైనా build చేయడానికి ముందు చదవడం విలువైనది. Command ఏమీ print చేయకపోతే repository తన licence file కు వేరే పేరు ఉపయోగిస్తోంది. అందువల్ల root directory ను list చేసి పరిశీలించండి.

ఏ licence కూడా ప్రతి ఫలితం నుంచి మిమ్మల్ని రక్షించదు. Ideology ఆధారంగా ఎంపిక చేయడం వల్ల అనుకోని సమస్యలు ఎదురవుతాయి. Copyright అనేక మంది వద్ద విభజించబడి ఉన్న లేదా foundation వద్ద ఉన్న projects కు ప్రాధాన్యం ఇవ్వండి. మీ data ను export చేయగల format లో ఉంచండి. తరువాత మీరు ఏ fork కు మారతారో తెలుసుకుని, అవసరం ఏర్పడకముందే ఆ పేరును రాసి ఉంచండి. ప్రతి candidate పై ఈ తనిఖీ చేయడానికి ఒక గంటకంటే తక్కువ సమయం పడుతుంది. మీరు 2026లో ఏదిని self-host చేయాలో నిర్ణయించేటప్పుడు, upgrade మరియు migration మధ్య తేడాను స్పష్టంగా చూపేది ఇదే.

FAQ

MIT licence, BSD licence ఒకటేనా?

ప్రయోగాత్మకంగా MIT licence, 2-clause BSD licence కు సమానంగా ఉంటుంది: copyright notice మరియు warranty disclaimer ను అలాగే ఉంచి, closed product నిర్మించడం సహా మీకు నచ్చిన విధంగా ఉపయోగించవచ్చు. 3-clause BSD licence లో ఒక అదనపు నియమం ఉంటుంది. Contributors అనుమతి లేకుండా వారి పేర్లను మీ product ను సమర్థిస్తున్నట్లు చూపించకూడదు. పాత 4-clause version లో advertising material లో acknowledgement ఇవ్వాలని కూడా కోరేది. UC Berkeley ఈ clause ను 22 July 1999న తొలగించింది. అందువల్ల ప్రస్తుతం దాన్ని కలిగిన licenceలు దాదాపుగా కనిపించవు.

Apache 2.0 code ను GPLv2 project లో చేర్చవచ్చా?

లేదు. Apache 2.0లో GPLv2 అనుమతించని అదనపు షరతులు ఉన్నాయి. ముఖ్యంగా patent termination clause కారణంగా, కలిపిన work రెండు licenceల నిబంధనలను ఒకేసారి పాటించలేదు. FSF మరియు ASF రెండూ ఇదే నిర్ణయాన్ని ప్రచురించాయి. విరుద్ధ దిశలో ఇది సాధ్యమే: Apache 2.0 code ను GPLv3 project లో చేర్చవచ్చు. ఫలితంగా అది GPLv3 అవుతుంది. Apache 2.0 code ను Linux kernel లో merge చేయలేకపోవడానికి ఇదే కారణం. Linux kernel GPL version 2 మాత్రమే ఉపయోగిస్తుంది.

SSPL open source licenceనా?

కాదు. దీనికి ఆచరణాత్మక ప్రభావాలు ఉన్నాయి. OSI దీన్ని ఎప్పుడూ ఆమోదించలేదు. MongoDB తన application ను March 2019లో ఉపసంహరించుకుంది. SSPL software తమ archiveలో ఉండకూడదని Debian December 2018లో తెలిపింది. January 2019లో Fedora ఈ licence free కాదని నిర్ణయించింది. ఆ తరువాత Red Hat, Fedora మరియు Red Hat Enterprise Linux నుంచి MongoDBని తొలగించింది. దీని అర్థం, మీ distribution గతంలో maintain చేసిన package ఇప్పుడు vendor repository నుంచి వస్తుంది. దాని updates vendor నిర్ణయించే support timetable ప్రకారం వస్తాయి. Business Source License కూడా open source కాదు; అది source available licence మాత్రమే. అయితే ప్రతి release నాలుగు సంవత్సరాలలోపు open source licenceకు మారుతుంది.

నేను ఇప్పటికే నడుపుతున్న versionకు licence మార్పు వర్తిస్తుందా?

లేదు. ఒక releaseతో మంజూరు చేసిన licenceను ఇప్పటికే ప్రచురించిన copies నుంచి వెనక్కి తీసుకోలేరు. Forks సాధ్యమవడానికి ఇదే ప్రధాన కారణం. OpenSearch, Elasticsearch 7.10.2 ఆధారంగా నిర్మించబడింది. Apache 2.0 కింద Elastic ప్రచురించిన చివరి release అదే. మీరు కోల్పోయేది భవిష్యత్తు updates. ఎందుకంటే తరువాతి security fix కొత్త నిబంధనల కింద వస్తుంది. చివరి permissively licensed versionను pin చేయడం ద్వారా కొన్ని నెలలు సమయం లభించవచ్చు. కానీ అది దీర్ఘకాలిక ప్రణాళిక కాదు.