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 ప్రకారం, మీరు దాని ఆధారంగా నిర్మించినదాని source ను, మీరు పొందిన అదే licence కింద ప్రచురించాలి.

మీరు నడుపుతున్న 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 లేదని స్పష్టం చేయాలని కోరే license కింద విడుదల చేసింది. అసలు version లో నాలుగు clauses ఉన్నాయి. అందులో మూడవది advertising clause. Software features గురించి ప్రస్తావించే ప్రతి advertising material లో University కి acknowledgement ఇవ్వాలని అది కోరింది. ఇది పెద్ద స్థాయిలో పనిచేయదు. NetBSD యొక్క 1997 version లో 75 వేర్వేరు acknowledgements ఉన్నట్లు Stallman లెక్కించారు. UC Berkeley ఈ clause ను 22 July 1999న తొలగించింది. ఈ నిర్ణయం దాని Office of Technology Licensing కు చెందిన William Hoskins రాసిన లేఖ ద్వారా వెల్లడైంది.

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

ఉద్దేశాలు వేర్వేరుగా ఉన్నాయి. ప్రజా నిధులతో నడిచే ఒక university తన పనిని companies తో సహా ప్రతి చోట ఉపయోగించాలని కోరుకుంది. GNU project మూసివేయలేని ఒక commons ను కోరుకుంది. రెండు స్థానాలూ నిజాయితీతో కూడినవే. రెండింటికీ ఒక వైఫల్య పరిస్థితి ఉంది. అనుమతించే code ను private గా మార్చుకోవచ్చు. అప్పుడు మీకు తిరిగి ఏమీ రాదు. ఆ నిబంధనను వారి lawyers అంగీకరించని companies copyleft code ను తిరస్కరిస్తాయి.

Berkeley నుంచి మరో పాఠం ఉంది. ఈ post మళ్లీ మళ్లీ దానివైపు తిరుగుతుంది. BSD code పై AT&T's Unix System Laboratories, Berkeley Software Design పై 1992లో దావా వేసింది. ఈ కేసు 1994 ప్రారంభంలో settlement తో ముగిసింది. రెండు సంవత్సరాల పాటు BSD ఆధారంగా build చేయడం సురక్షితమా కాదా అని ఎవరికీ ఖచ్చితంగా తెలియలేదు. Linux అభివృద్ధి చెందుతున్న సమయంలో adoption నిలిచిపోయింది. 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 కూడా ఉంటాయి. ఈ బాధ్యతకు స్పష్టమైన పరిమితి లేదు. ఏ court కూడా దీనిని ఇంకా పరీక్షించలేదు. OSI ఈ licence ను ఎప్పుడూ ఆమోదించలేదు. MongoDB 2019 మార్చిలో తన application ను ఉపసంహరించుకుంది. 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 గా ఉంటుంది. Production కాని ఉపయోగం ఉచితం. Vendor యొక్క Additional Use Grant అనుమతించిన మేరకే production use చేయవచ్చు. సాధారణంగా ఆ grant, పోటీ hosted service ను నడపకుండా నిరోధిస్తుంది. ప్రతి release, ఆ release వచ్చిన నాలుగు సంవత్సరాలలోపు ఉండే change date నాడు స్వయంచాలకంగా నిజమైన open source licence కు మారుతుంది. అది మారే licence తప్పనిసరిగా GPL version 2.0 లేదా దాని తరువాతి version అయి ఉండాలి. లేదా వాటిలో ఒకదానితో compatible గా ఉండాలి. HashiCorp, 2023 ఆగస్టు 10న Terraform మరియు తన ఇతర products ను BUSL 1.1 కు మార్చింది. Outline కూడా దీన్ని ఉపయోగిస్తుంది. మీరు self-hosted Notion ప్రత్యామ్నాయాలలో ఎంచుకుంటున్నప్పుడు ఇది తెలుసుకోవడం ఉపయోగకరం: మీ స్వంత team కోసం దీన్ని నడపడం అనుమతించబడుతుంది. దీని ఆధారంగా service నిర్మించడం అనుమతించబడదు.

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

OpenSearch: లైసెన్స్ fork వల్ల ఆపరేటర్‌పై పడే ఖర్చు

Elastic 14 January 2021న Elasticsearch మరియు Kibana Apache 2.0 నుంచి SSPL లేదా Elastic License లోకి మారుతాయని ప్రకటించింది. ఈ మార్పు release 7.11 నుంచి అమలులోకి వచ్చింది. 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 తాను ఏదికి connect అయిందో తనిఖీ చేసి, అది Elasticsearch కాకపోతే కొనసాగడానికి నిరాకరిస్తుంది. Server తెలియని product అని error ఇస్తుంది. మీరు పనిచేయని ఒక కంపెనీ తీసుకున్న licence నిర్ణయం, మీ స్వంత application లో failing call గా ప్రత్యక్షమైంది.

తరువాత ఈ కథనం మరో రెండుసార్లు మారింది. Elastic 29 August 2024న AGPLv3 ను మూడవ licence option గా చేర్చనున్నట్లు ప్రకటించింది. దాని licensing FAQ ప్రకారం ఈ addition September 2024లో జరిగింది. అందువల్ల ప్రస్తుత Elasticsearch మళ్లీ OSI-approved open source అయింది. 16 September 2024న AWS OpenSearch ను Linux Foundation ఆధ్వర్యంలోని OpenSearch Software Foundationకు బదిలీ చేసింది. దీనివల్ల ఈ fork కు ఒకే కంపెనీకి పరిమితం కాని governance home లభించింది. విభజన జరిగిన ఐదు సంవత్సరాల తరువాత రెండు projects కూడా open sourceగానే ఉన్నాయి, రెండింటినీ నిర్వహిస్తున్నారు. October 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 కు కొత్త పేరు పెట్టి rebuild చేయాల్సి వచ్చింది, అలాగే copy చేసేందుకు అంతకుముందు fork ఏదీ లేదు. OpenTofuకి 153 రోజులు పట్టాయి. Valkeyకి 27 రోజులు పట్టాయి. ఎందుకంటే అది Redis 7.2.4ను fork చేసి, protocol మరియు on-disk format ను యథాతథంగా ఉంచింది. ఉపయోగకరమైన విషయం దిశలో ఉంది: foundation మరియు paid maintainers మొదటి రోజునుంచే తోడుగా ఉంటే, విశ్వసనీయమైన fork ఇప్పుడు కొన్ని వారాల్లోనే అందుబాటులోకి వస్తుంది.

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 చేయడం ద్వారా కొన్ని నెలలు సమయం లభించవచ్చు. కానీ అది దీర్ఘకాలిక ప్రణాళిక కాదు.