GPL, MIT, Apache உரிமங்களின் வேறுபாடுகள் என்ன?

GPL vs MIT vs Apache: ஒவ்வொரு உரிமமும் உங்களிடமிருந்து எதிர்பார்ப்பது என்ன

GPL, MIT மற்றும் Apache 2.0 ஆகிய மூன்றும் ஒரே கேள்விக்கு வெவ்வேறு விதமாகப் பதிலளிக்கின்றன: மென்பொருளை நீங்கள் மற்றவர்களுக்கு வழங்கும்போது, அவர்களுக்கு நீங்கள் என்ன செய்யக் கடமைப்பட்டிருக்கிறீர்கள்? MIT உரிமம், பதிப்புரிமை அறிவிப்பை (copyright notice) மட்டும் கோருகிறது, வேறு எதையும் கேட்பதில்லை. Apache 2.0 உரிமம், அந்த அறிவிப்புடன் சேர்த்து, குறியீட்டிற்குப் பங்களிக்கும் அனைவருடனும் ஒரு காப்புரிமை ஒப்பந்தத்தையும் (patent bargain) கோருகிறது. GPL உரிமம், நீங்கள் உருவாக்கிய மென்பொருளின் மூலக் குறியீட்டை (source code), நீங்கள் பெற்ற அதே உரிமத்தின் கீழ் வெளியிட வேண்டும் என்று கோருகிறது.

நீங்கள் இயக்கும் ஒரு திட்டத்தின் உரிமம் மாற்றப்பட்டு, அது இரண்டாகப் பிரியும் நாள் வரை, இது வழக்கறிஞர்களுக்கான கேள்வியாகவே தோன்றும். அந்த நாளில், இது ஒரு செயல்பாட்டுச் சிக்கலாக (operations question) மாறுகிறது. அப்போது நீங்கள் இரண்டு தொகுப்பு களஞ்சியங்களுக்கு (package repositories) இடையே ஒன்றைத் தேர்ந்தெடுக்க வேண்டியிருக்கும், மேலும் ஒன்றுடன் ஒன்று தொடர்புகொள்ளாத client libraries-களைக் கையாள வேண்டியிருக்கும். இந்த வழிகாட்டி உரிமங்கள் மற்றும் அவற்றின் செயல்பாடுகளைப் பற்றியது; அவற்றை உருவாக்கிய இயக்கத்தைப் பற்றியது அல்ல. எனவே, ஒவ்வொரு பகுதியும் உங்களை எங்கு பாதிக்கிறதோ, அங்கு முடிகிறது: அதாவது, மேம்படுத்தலை (upgrade) மேற்கொள்ள வேண்டிய நபராகிய உங்களை.

GPL ஏன் உருவாக்கப்பட்டது: சரிசெய்ய அனுமதி மறுக்கப்பட்ட ஒரு பிரிண்டர்

1980-வாக்கில் MIT செயற்கை நுண்ணறிவு ஆய்வகத்திற்கு Xerox 9700 லேசர் பிரிண்டர் ஒன்று கிடைத்தது. இதற்கு முந்தைய பிரிண்டரில் காகிதம் சிக்கிக்கொண்டால் எச்சரிக்கும் வகையில் ஆய்வகத்தினர் அதன் மென்பொருளை மாற்றியமைத்திருந்தனர். புதிய பிரிண்டருக்கு source code கிடைக்கவில்லை; ரகசிய ஒப்பந்தம் (nondisclosure agreement) காரணமாக அதைக் கோரியபோது மறுக்கப்பட்டுவிட்டது. அப்போது அங்கு புரோகிராமராக இருந்த Richard Stallman, இந்த மறுப்பை ஒரு தனிப்பட்ட நிகழ்வாகப் பார்க்காமல் பொதுவான சிக்கலாகக் கருதினார். இதன் விளைவாக, 1983 செப்டம்பர் 27 அன்று GNU திட்டத்தை அவர் அறிவித்தார்.

Copyleft என்பது பதிப்புரிமைச் சட்டத்திற்கு எதிராக அல்ல, அதன் அடிப்படையிலேயே கட்டமைக்கப்பட்டுள்ளது. இயல்பாகவே, பிறருடைய code-ஐ நகலெடுக்க உங்களுக்கு உரிமை இல்லை. GPL அந்த உரிமையை ஒரு நிபந்தனையுடன் வழங்குகிறது: நீங்கள் ஒரு நிரலை மற்றவர்களுக்கு வழங்கினால், அதே நிபந்தனைகளின் கீழ் நீங்களும் source code-ஐ வழங்க வேண்டும். அப்போதுதான் அந்த ஆய்வகத்தால் செய்ய முடியாததை அவர்களால் செய்ய முடியும். இந்த உரிமம் இல்லையென்றால் உங்களுக்கு எந்த அனுமதியும் இல்லை என்பதால், இந்த நிபந்தனையை அமல்படுத்த முடியும்.

Stallman முதலில் GNU Emacs-க்காக ஒரு உரிமத்தை எழுதினார், பின்னர் அதை 1989 பிப்ரவரி 25 அன்று GPL version 1 ஆகப் பொதுமைப்படுத்தினார். 1991 ஜூன் மாதம் GPL version 2 வெளியானது; இன்றும் நீங்கள் இயக்கும் பெரும்பாலான system software-களில் இதுவே உரிமமாக உள்ளது. நூலகங்களுக்காக (libraries) Lesser GPL உருவாக்கப்பட்டது. இதன் மூலம், ஒரு copyleft library-ஐ எந்த உரிமத்தின் கீழ் உள்ள நிரலுடனும் இணைக்க முடியும்; அந்த நிரலை GPL-க்குள் கொண்டுவர வேண்டிய கட்டாயம் இருக்காது.

ஒரு self-hoster-ஐ GPL எவ்வாறு பாதிக்கிறது என்பதை ஒரு நுணுக்கமான அம்சம் தீர்மானிக்கிறது. இந்த கடமை விநியோகத்தின் (distribution) போதுதான் தூண்டப்படுகிறது, பயன்பாட்டின் போது அல்ல. நீங்கள் ஒரு GPL நிரலை மாற்றியமைத்து, உங்கள் சொந்த server-ல் இயக்கி, பொதுமக்களுக்குச் சேவை வழங்கினாலும், நீங்கள் யாருக்கும் எதையும் தர வேண்டியதில்லை; ஏனெனில் நீங்கள் அதன் நகலை யாரிடமும் வழங்கவில்லை. இந்த இடைவெளிதான் AGPL இருப்பதற்கான காரணம்.

அனுமதிக்கும் மரபு: BSD, பின்னர் MIT

Berkeley ஒரு மாறுபட்ட பாதையைத் தேர்ந்தெடுத்தது. அதன் Computer Systems Research Group, தனது Unix பணிகளை ஒரு உரிமத்தின் கீழ் வெளியிட்டது. அந்த உரிமம், பதிப்புரிமை அறிவிப்பை (copyright notice) அப்படியே வைத்திருக்க வேண்டும் என்றும், எந்தவொரு உத்தரவாதத்தையும் (warranty) வழங்கவில்லை என்றும் குறிப்பிட்டது. அதன் அசல் பதிப்பில் நான்கு பிரிவுகள் இருந்தன. மூன்றாவது பிரிவான 'விளம்பரப் பிரிவு' (advertising clause), மென்பொருளின் அம்சங்களைக் குறிப்பிடும் அனைத்து விளம்பரங்களிலும் பல்கலைக்கழகத்திற்கு நன்றி தெரிவிக்க வேண்டும் என்று கட்டாயப்படுத்தியது. இது நடைமுறைக்குச் சாத்தியமானதல்ல. 1997-ம் ஆண்டு NetBSD பதிப்பில் 75 தனித்தனி நன்றியறிவிப்புகள் இருந்ததை Stallman கணக்கிட்டார். UC Berkeley, தனது Office of Technology Licensing-ன் William Hoskins எழுதிய கடிதத்தின் மூலம், 1999 ஜூலை 22 அன்று அந்தப் பிரிவை நீக்கியது.

தற்போது எஞ்சியிருப்பது 3-clause BSD உரிமம் ஆகும். இது பங்களிப்பாளர்களின் பெயர்களை உங்கள் தயாரிப்பை ஆதரிக்கப் பயன்படுத்தக்கூடாது என்ற அசல் தடையைத் தக்கவைத்துள்ளது. 2-clause பதிப்பு அந்தத் தடையையும் நீக்கிவிடுகிறது. MIT உரிமத்தின் உரை 1980-களில் MIT-யிலிருந்து உருவானது; இது X Window System-ஐ உள்ளடக்கியிருந்தது. நடைமுறையில் இது 2-clause BSD செய்யும் அதே பணியைச் செய்கிறது.

இவற்றின் நோக்கங்கள் வெவ்வேறானவை. பொது நிதியால் இயங்கும் ஒரு பல்கலைக்கழகம், தனது பணிகள் நிறுவனங்கள் உட்பட அனைத்து இடங்களிலும் பயன்படுத்தப்பட வேண்டும் என்று விரும்பியது. GNU திட்டம், மூடப்பட முடியாத ஒரு பொதுச் சொத்தை (commons) உருவாக்க விரும்பியது. இரண்டு நிலைப்பாடுகளும் நேர்மையானவை, ஆனால் இரண்டிலும் தோல்விக்கான வாய்ப்புகள் உள்ளன. அனுமதிக்கும் (permissive) குறியீட்டை நிறுவனங்கள் தனியுரிமையாக்கிக் கொள்ளலாம், அதற்குப் பதிலாக உங்களுக்கு எதுவும் கிடைக்காது. Copyleft குறியீட்டை, அதன் நிபந்தனைகளை ஏற்க மறுக்கும் நிறுவனங்கள் பயன்படுத்தாது.

Berkeley-யிடமிருந்து கிடைக்கும் இரண்டாவது பாடம் இதுதான்; இந்த இடுகை மீண்டும் மீண்டும் இதையே வலியுறுத்துகிறது. AT&T-ன் Unix System Laboratories, 1992-ல் BSD குறியீடு தொடர்பாக Berkeley Software Design மீது வழக்குத் தொடர்ந்தது. இந்த வழக்கு 1994-ன் தொடக்கத்தில் முடிவுக்கு வந்தது. இரண்டு ஆண்டுகள் வரை, BSD-ஐ அடிப்படையாகக் கொண்டு மென்பொருள் உருவாக்குவது பாதுகாப்பானதா என்பதில் யாருக்கும் உறுதியில்லை. இதனால் அதன் பயன்பாடு தேக்கமடைந்தது, அதே நேரத்தில் Linux வளர்ந்தது. ஒரு மென்பொருளில் அம்சம் விடுபட்டிருப்பதை விட, சட்டரீதியான நிச்சயமற்ற தன்மை அதன் பயன்பாட்டை மிக வேகமாக நிறுத்திவிடும்.

Apache 2.0 ஏன் காப்புரிமை மானியத்தை (patent grant) சேர்த்தது

Apache Group-ன் முதல் உரிமம், அதே விளம்பரச் சிக்கலைக் கொண்டிருந்த BSD 4-clause உரிமத்தின் வழித்தோன்றலாகும். 2000-ல் வெளியான பதிப்பு 1.1, அந்த விதியை நீக்கியது. ஜனவரி 2004-ல் வெளியிடப்பட்ட பதிப்பு 2.0, ஒரு திருத்தம் (patch) என்பதை விட முழுமையான மறுஎழுத்தாகும்.

இதில் சேர்க்கப்பட்ட முக்கியமான அம்சம் காப்புரிமைகள் (patents) ஆகும். MIT மற்றும் BSD உரிமங்கள் இதைப் பற்றி எதையும் குறிப்பிடவில்லை. ஒரு பங்களிப்பாளர் தனது குறியீட்டிற்குத் தெளிவான பதிப்புரிமை அனுமதியை வழங்கினாலும், அந்தக் குறியீடு செய்யும் செயலுக்கான காப்புரிமையை அவர் வைத்திருக்க முடியும்; பின்னர் அதைப் பயன்படுத்தும் நபர்கள் மீது அவர் வழக்குத் தொடரலாம். Apache 2.0 இந்த ஓட்டையை அடைக்கிறது: ஒவ்வொரு பங்களிப்பாளரும் தங்கள் பங்களிப்பிற்கான காப்புரிமை உரிமத்தை வழங்குகிறார்கள், மேலும் அந்தப் படைப்பு தங்கள் காப்புரிமைகளை மீறுவதாகக் கூறி வழக்குத் தொடரும் எவரும், அதற்கான தங்கள் சொந்த காப்புரிமை உரிமத்தை இழக்க நேரிடும். இந்த அச்சுறுத்தல் இருதரப்பிலும் இருப்பதால், நடைமுறையில் யாரும் வழக்குத் தொடர்வதில்லை.

பதிப்பு 2.0-ன் மற்ற பகுதிகள் நிர்வாகம் சார்ந்தவை, இதனாலேயே நிறுவனங்கள் இதை விரும்புகின்றன. இதில் வரையறுக்கப்பட்ட NOTICE கோப்பு உள்ளது, எனவே அங்கீகாரம் (attribution) என்பது குறியீட்டு மரம் முழுவதும் சிதறிக் கிடப்பதற்குப் பதிலாக ஒரே இடத்தில் அமைகிறது. உரிமத்தை ஒவ்வொரு source கோப்பிலும் ஒட்டுவதற்குப் பதிலாக, குறிப்பு (reference) மூலம் பயன்படுத்தலாம். பங்களிப்புகள் தெளிவான விதிகளின் கீழ் வருகின்றன. வர்த்தக முத்திரைகள் (trademarks) இதில் சேர்க்கப்படவில்லை. ஒரு Apache 2.0 dependency-ஐ சட்டப்பூர்வமாக ஆய்வு செய்யும் போது, கேட்க வேண்டிய அனைத்து கேள்விகளுக்கும் உரையிலேயே பதில் கிடைத்துவிடுகிறது. இதனால் ஒப்புதல் பெறுவது வழக்கமான ஒன்றாக மாறுகிறது, இதுவே "corporate default" என்பதன் முக்கிய பொருளாகும்.

GPLv3 எதை மாற்றியது, Linux ஏன் GPLv2-லேயே நீடிக்கிறது

TiVo நிறுவனம் Linux இயங்கும் ஒரு video recorder-ஐ விற்பனை செய்தது. GPLv2 விதிகளின்படி, அது kernel source code-ஐ வெளியிட்டது. ஆனால், அந்த hardware boot செய்யும்போது ஒரு cryptographic signature-ஐச் சரிபார்க்கும்; அங்கீகரிக்கப்படாத எந்த kernel-ஐயும் அது இயக்காது. நீங்கள் source code-ஐப் படிக்கலாம், மாற்றலாம், compile செய்யலாம். ஆனால், அந்த மாற்றியமைக்கப்பட்ட kernel-ஐ அதே device-ல் உங்களால் இயக்க முடியாது. உரிமத்தின் எழுத்துப்பூர்வமான விதிகள் பின்பற்றப்பட்டன, ஆனால் அதன் நோக்கம் சிதைக்கப்பட்டது. இந்த நடைமுறை tivoisation என்று அழைக்கப்பட்டது.

ஜூன் 29, 2007 அன்று வெளியிடப்பட்ட GPL version 3, இதற்கு நேரடியாகப் பதிலளிக்கிறது. ஒரு consumer device-க்குள் binary-ஐ நீங்கள் வழங்கும்போது, அதனுடன் "Installation Information"-ஐயும் வழங்க வேண்டும்: அதாவது, மாற்றியமைக்கப்பட்ட பதிப்பை நிறுவி இயக்குவதற்குத் தேவையான keys அல்லது வழிமுறைகள். Version 3-ல் காப்புரிமைக்கான (patent) தெளிவான அனுமதி சேர்க்கப்பட்டது. இது நவம்பர் 2006-ல் Microsoft மற்றும் Novell இடையே ஏற்பட்ட காப்புரிமை ஒப்பந்தத்திற்குப் பதிலடியாக எழுதப்பட்டது. மேலும், Apache 2.0 உரிமத்துடன் ஒருவழி இணக்கத்தன்மையும் (one-way compatibility) இதில் சேர்க்கப்பட்டது.

Linux இதைப் பின்பற்றவில்லை. Linux kernel என்பது GPL version 2 மட்டுமே; இதில் "or any later version" என்ற விதிவிலக்கு கிடையாது. அதன் COPYING கோப்பு இதை உறுதிப்படுத்துகிறது. கையொப்பமிடப்பட்ட hardware-களுக்கான tivoisation-க்கு எதிரான விதிகளை Linus Torvalds பகிரங்கமாக எதிர்த்தார். நடைமுறைச் சிக்கல் கருத்து வேறுபாட்டை விடப் பெரியது: kernel-க்கு ஆயிரக்கணக்கான பதிப்புரிமைதாரர்கள் உள்ளனர். எனவே, அனைவரும் விரும்பினாலும் உரிமத்தை மாற்றுவதற்குத் தேவையான அனுமதிகளை யாராலும் திரட்ட முடியாது. இந்த ஒரு உண்மைதான் ஒரு திட்டத்திற்கு இருக்கும் மிக வலுவான பாதுகாப்பு. ஒரு நிறுவனத்திற்குச் சொந்தமான திட்டத்தைப் பார்க்கும்போது இதை நினைவில் கொள்வது அவசியம்.

2007-ல் வெளியான மற்றொரு உரிமம் உங்களுக்கு அதிக முக்கியத்துவம் வாய்ந்தது. அதே ஆண்டு நவம்பரில் வெளியான GNU Affero GPL version 3, ஒரு நிரலை network வழியாகப் பயன்படுத்தும் பயனர்களுக்கும் source code-ஐ வழங்க வேண்டிய கட்டாயத்தை உருவாக்குகிறது. மாற்றியமைக்கப்பட்ட AGPL சேவையை நீங்கள் பொதுமக்களுக்கு வழங்கினால், அந்தப் பயனர்களுக்கு நீங்கள் source code-ஐ வழங்க வேண்டும். இதனால்தான் பல self-hosted web software-கள் AGPL உரிமத்தில் உள்ளன. Nextcloud இதற்கு ஒரு உதாரணம். நீங்கள் Nextcloud-க்கு மாற்றான self-hosted மென்பொருட்களை ஒப்பிட்டுப் பார்க்கிறீர்கள் என்றால், அந்தந்த repository-ல் உள்ள உரிம விவரம், அதன் feature list-ஐ விட அடுத்த ஐந்து ஆண்டுகளில் அந்த மென்பொருள் எப்படி இருக்கும் என்பதைத் தெளிவாகக் காட்டும்.

எந்தெந்த உரிமங்களை (licences) நீங்கள் உண்மையில் இணைக்க முடியும்?

இணக்கத்தன்மை (compatibility) என்பது ஒரு திசையில் மட்டுமே செயல்படும்; அதாவது, தாராளமான (permissive) உரிமங்களிலிருந்து நகல்-உரிமை (copyleft) உரிமங்களை நோக்கிச் செல்லும்.

• MIT மற்றும் BSD குறியீடுகளை எதிலும் சேர்க்கலாம்; மூடிய-மூல (closed) தயாரிப்புகளிலும் இதைப் பயன்படுத்தலாம்.
• Apache 2.0 குறியீட்டை ஒரு GPLv3 திட்டத்தில் சேர்க்கலாம்; அவ்வாறு இணைக்கப்பட்ட படைப்பு GPLv3 உரிமத்திற்கு உட்பட்டதாக மாறும்.
• Apache 2.0 குறியீட்டை GPLv2-மட்டும் கொண்ட திட்டத்தில் சேர்க்க முடியாது. அதன் காப்புரிமை முடிவு (patent termination) மற்றும் இழப்பீடு (indemnity) நிபந்தனைகள், GPLv2 அனுமதிக்காத கூடுதல் கட்டுப்பாடுகளாகும். FSF மற்றும் ASF ஆகிய இரண்டு அமைப்புகளும் இந்த முடிவை உறுதிப்படுத்துகின்றன.
• GPL குறியீட்டை உங்களால் தாராளமான உரிமத்திற்கு மாற்ற முடியாது. பதிப்புரிமை வைத்திருப்பவர்களால் (copyright holders) மட்டுமே அதைச் செய்ய முடியும்; இது மீண்டும் அவர்கள் யார் என்ற கேள்விக்கே உங்களை அழைத்துச் செல்லும்.

உரிம மாற்ற காலம்: SSPL, BUSL மற்றும் அவை எவை அல்ல

இதற்கான தூண்டுதல் வணிக ரீதியானது. ஒரு நிறுவனம் ஒரு தயாரிப்பின் பதிப்புரிமையை வைத்திருக்கிறது; ஒரு cloud provider அதை ஒரு நிர்வகிக்கப்படும் சேவையாக (managed service) பெரிய அளவில் விற்கிறது, ஆனால் அதற்குப் பதிலாக மிகக் குறைந்த பங்களிப்பையே வழங்குகிறது. இதைத் தடுக்க அந்த நிறுவனம் உரிமத்தை மாற்றுகிறது. Redis Labs ஆகஸ்ட் 2018-ல் தனது பல தொகுதிகளுக்கு Apache 2.0 உடன் Commons Clause-ஐச் சேர்த்து முதல் குறிப்பிடத்தக்க மாற்றத்தைச் செய்தது. MongoDB 16 October 2018 அன்று AGPLv3-லிருந்து Server Side Public License-க்கு மாறியதன் மூலம் இதைப் பின்பற்றியது.

SSPL என்பது AGPL-ன் ஒரு பகுதியை மாற்றியமைத்த வடிவம். ஒரு நிரலை மூன்றாம் தரப்பினருக்குச் சேவையாக வழங்கினால், அதை வழங்க நீங்கள் பயன்படுத்தும் அனைத்தின் மூலக் குறியீட்டையும் (source code) வெளியிட வேண்டும்; இதில் அதைச் சுற்றியுள்ள மேலாண்மை மற்றும் ஒருங்கிணைப்பு மென்பொருளும் அடங்கும். அந்த கடமைக்குத் தெளிவான எல்லை இல்லை, எந்த நீதிமன்றமும் இதைச் சோதிக்கவில்லை. OSI இந்த உரிமத்திற்கு ஒருபோதும் ஒப்புதல் அளிக்கவில்லை, மார்ச் 2019-ல் MongoDB தனது விண்ணப்பத்தைத் திரும்பப் பெற்றது. டிசம்பர் 2018-லேயே Debian, SSPL மென்பொருள் அதன் காப்பகத்திற்குள் சேரவில்லை என்று கூறிவிட்டது. ஜனவரி 2019-ல் Fedora இந்த உரிமம் இலவசமானது அல்ல என்று தீர்ப்பளித்தது. அதன் பிறகு Red Hat, MongoDB-ஐ Fedora மற்றும் Red Hat Enterprise Linux-லிருந்து நீக்கியது. இது ஒரு உரிம மாற்றத்தின் இயந்திரத்தனமான விளைவு: விநியோகஸ்தர்கள் (distribution) அந்த மென்பொருளைத் தொகுப்பதை நிறுத்திவிடுகிறார்கள், எனவே உங்கள் மேம்படுத்தல்கள் (upgrades) விற்பனையாளரின் கால அட்டவணைப்படி அவர்களின் களஞ்சியத்திலிருந்து (repository) கிடைக்கின்றன.

Business Source License ஒரு மாறுபட்ட கருவி. இது MariaDB நிறுவனர்களிடமிருந்து வந்தது, இதன் 1.1 பதிப்பு 2017-ல் வெளியானது. இது copyleft அல்ல, இது open source-ம் அல்ல. மூலக் குறியீடு பொதுவானது மற்றும் தயாரிப்பு அல்லாத பயன்பாட்டிற்கு இது இலவசம். விற்பனையாளரின் Additional Use Grant அனுமதிக்கும் அளவிற்கு மட்டுமே தயாரிப்பு பயன்பாடு அனுமதிக்கப்படுகிறது, மேலும் அந்த அனுமதி பொதுவாகப் போட்டியிடும் hosted சேவைகளை இயக்குவதைத் தடுக்கிறது. ஒவ்வொரு வெளியீடும், அந்த வெளியீட்டிற்குப் பிறகு நான்கு ஆண்டுகளுக்கு மிகாத ஒரு குறிப்பிட்ட தேதியில் உண்மையான open source உரிமமாகத் தானாகவே மாறிவிடும். அது மாறும் உரிமம் GPL version 2.0 அல்லது அதற்குப் பிந்தைய பதிப்பாகவோ, அல்லது அவற்றுடன் இணக்கமான உரிமமாகவோ இருக்க வேண்டும். HashiCorp தனது Terraform மற்றும் பிற தயாரிப்புகளை 10 August 2023 அன்று BUSL 1.1-க்கு மாற்றியது. Outline-ம் இதையே பயன்படுத்துகிறது; நீங்கள் self-hosted Notion மாற்றுகளை தேர்வு செய்கிறீர்கள் என்றால் இதைத் தெரிந்துகொள்வது அவசியம்: உங்கள் சொந்தக் குழுவிற்காக அதை இயக்குவது அனுமதிக்கப்படுகிறது, ஆனால் அதன் மீது ஒரு சேவையை உருவாக்குவது அனுமதிக்கப்படாது.

இந்த இரண்டு உரிமங்களும் நேர்மையற்றவை அல்ல. இவை இரண்டும் தாங்கள் source available என்று தெளிவாகக் கூறுகின்றன. OSI வரையறையின்படி இவை இரண்டும் open source அல்ல, மேலும் இதன் தாக்கம் நீங்கள் பயன்படுத்தும் cloud provider-ஐ விட உங்கள் மீதே அதிகம் விழுகிறது.

OpenSearch: உரிம மாற்றத்தால் (licence fork) இயக்கும் நபர்களுக்கு ஏற்படும் செலவு

Elastic நிறுவனம் 14 ஜனவரி 2021 அன்று, Elasticsearch மற்றும் Kibana ஆகியவை Apache 2.0 உரிமத்திலிருந்து விலகி, 7.11 release முதல் SSPL அல்லது Elastic License-க்கு மாறப்போவதாக அறிவித்தது. 7.10.2 பதிப்பே கடைசி Apache 2.0 release ஆகும். ஒரு வாரம் கழித்து, AWS நிறுவனம் இவை இரண்டிற்கும் Apache 2.0 உரிமம் கொண்ட fork-ஐ உருவாக்கி பராமரிக்கப்போவதாகத் தெரிவித்தது. 12 ஏப்ரல் 2021 அன்று இந்த fork-க்கு OpenSearch என்று பெயரிடப்பட்டது; Kibana, OpenSearch Dashboards என மறுபெயரிடப்பட்டது. Elasticsearch 7.10.2 மற்றும் Kibana 7.10.2 ஆகியவற்றிலிருந்து உருவாக்கப்பட்ட OpenSearch 1.0, 12 ஜூலை 2021 அன்று பொதுப் பயன்பாட்டிற்கு வந்தது.

கிளஸ்டர்களை (clusters) இயக்கும் நபர்களுக்கு இது என்ன செலவை ஏற்படுத்தியது என்று பாருங்கள். Package பெயர்களும் repositories-ம் மாறின. Runbook-களில் இருந்த Kibana பற்றிய ஒவ்வொரு குறிப்பும் OpenSearch Dashboards என மாற்றப்பட வேண்டியிருந்தது. Plugin பெயர்கள் மாறின. பின்னர் இந்த பிளவு application code-ஐயும் பாதித்தது: Elastic-ன் அதிகாரப்பூர்வ client libraries-ன் 7.13 பதிப்பிலிருந்து, client தான் எதனுடன் இணைக்கப்பட்டுள்ளது என்பதைச் சரிபார்க்கிறது. அது Elasticsearch இல்லை என்றால், server ஒரு அறியப்படாத தயாரிப்பு (unknown product) என்று கூறி இணைப்பைத் துண்டிக்கிறது. நீங்கள் பணிபுரியாத ஒரு நிறுவனத்தின் உரிம முடிவு, உங்கள் சொந்த application-க்குள் ஒரு தோல்வியுற்ற அழைப்பாக (failing call) வந்து சேர்ந்தது.

இந்தக் கதை மேலும் இரண்டு முறை மாறியது. Elastic நிறுவனம் 29 ஆகஸ்ட் 2024 அன்று, AGPLv3-ஐ மூன்றாவது உரிம விருப்பமாகச் சேர்க்கப்போவதாக அறிவித்தது. அதன் உரிம FAQ-வின்படி, இந்தச் சேர்க்கை செப்டம்பர் 2024-ல் நடைமுறைக்கு வந்தது. எனவே, தற்போதைய Elasticsearch மீண்டும் OSI-அங்கீகாரம் பெற்ற open source ஆகிவிட்டது. 16 செப்டம்பர் 2024 அன்று, AWS நிறுவனம் OpenSearch-ஐ Linux Foundation-ஆல் நடத்தப்படும் OpenSearch Software Foundation-க்கு மாற்றியது. இது அந்த fork-க்கு ஒரே நிறுவனத்தைச் சாராத ஒரு நிர்வாக அமைப்பைக் கொடுத்தது. பிளவு ஏற்பட்டு ஐந்து ஆண்டுகளுக்குப் பிறகு, இரண்டு திட்டங்களும் open source ஆக உள்ளன, இரண்டுமே பராமரிக்கப்படுகின்றன, மேலும் அக்டோபர் 2026 நிலவரப்படி OpenSearch அதன் 3.x தொடரில் உள்ளது.

இதன் முடிவுதான் பாடம். உரிமம் மீண்டும் பழைய நிலைக்குத் திரும்பியது, ஆனால் fork அப்படியே தங்கிவிட்டது. ஒரு ecosystem-ல் எல்லாவற்றிற்கும் இரண்டு பதிப்புகள் வந்துவிட்டால், காகித வேலைகளை மாற்றுவது அவற்றை மீண்டும் ஒன்றாக இணைக்காது.

ஒரு உரிம மாற்றம் எவ்வளவு பாதிப்பை ஏற்படுத்தும் என்பதைத் தீர்மானிக்கும் எண், அறிவிப்புக்கும் நீங்கள் பயன்படுத்தக்கூடிய நிலையான 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
  }
]

ஒவ்வொரு இடைவெளியும் விற்பனையாளரின் பொது அறிவிப்பிலிருந்து fork-ன் முதல் நிலையான release வரை கீழே பட்டியலிடப்பட்டுள்ள தேதிகளைக் கொண்டு கணக்கிடப்படுகிறது. OpenSearch 1.0-க்கு 179 நாட்கள் தேவைப்பட்டன, ஏனெனில் அந்த fork மறுபெயரிடப்பட்டு புதிதாக உருவாக்கப்பட வேண்டியிருந்தது, நகலெடுக்க முந்தைய fork எதுவும் இல்லை. OpenTofu-க்கு 153 நாட்கள் தேவைப்பட்டன. Valkey-க்கு 27 நாட்கள் தேவைப்பட்டன, ஏனெனில் அது Redis 7.2.4-ஐ fork செய்து, அதன் protocol மற்றும் on-disk format-ஐ அப்படியே வைத்திருந்தது. இதில் கவனிக்க வேண்டிய விஷயம் என்னவென்றால், நம்பகமான ஒரு fork இப்போது சில வாரங்களிலேயே கிடைத்துவிடுகிறது, அதனுடன் முதல் நாளிலிருந்தே ஒரு foundation மற்றும் ஊதியம் பெறும் பராமரிப்பாளர்களும் இணைந்துவிடுகிறார்கள்.

Valkey மற்றும் OpenTofu: அதே பாணி, கூடுதல் வேகம்

Redis Ltd, 20 மார்ச் 2024 அன்று Redis-ன் உரிமத்தை 3-clause BSD-யிலிருந்து RSALv2 அல்லது SSPLv1-க்கு மாற்றியது. எட்டு நாட்களுக்குப் பிறகு, Linux Foundation, Redis 7.2.4-லிருந்து பிரிக்கப்பட்ட (forked) மற்றும் BSD 3-clause உரிமத்திலேயே நீடிக்கும் Valkey-ஐ அறிவித்தது. Valkey 7.2.5, 16 ஏப்ரல் 2024 அன்று அதே protocol மற்றும் அதே data files-உடன் வெளியானது. எனவே, பெரும்பாலான நிர்வாகிகளுக்கு இது ஒரு package name மாற்றமாக மட்டுமே இருந்தது. பின்னர், மே 2025-ல் Redis 8-ல் AGPLv3-ஐ மூன்றாவது விருப்பமாக Redis சேர்த்தது. இது OSI வரையறைப்படி மீண்டும் open source-ஆக மாறியது, அதே சமயம் Valkey தனது சொந்த நிர்வாகத்தின் கீழ் தொடர்ந்து செயல்படுகிறது. இதன் வடிவம் Elasticsearch-உடன் நெருக்கமாக ஒத்துப்போகிறது.

Terraform-ம் இதே பாதையில் சென்றது, ஆனால் ஒரு கூடுதல் அத்தியாயத்துடன். OpenTofu, Mozilla Public License 2.0-ன் கடைசி வெளியீட்டைப் பிரித்து, செப்டம்பர் 2023-ல் Linux Foundation-ல் இணைந்தது. 10 ஜனவரி 2024 அன்று 1.6.0 பதிப்பை வெளியிட்டது. 3 ஏப்ரல் 2024 அன்று, BUSL உரிமம் பெற்ற Terraform வெளியீட்டிலிருந்து குறியீடுகள் (code) இந்த fork-ல் நகலெடுக்கப்பட்டதாகக் கூறி, HashiCorp-ன் வழக்கறிஞர்கள் ஒரு cease and desist கடிதத்தை அனுப்பினர். OpenTofu, 11 ஏப்ரல் 2024 அன்று இதற்கு விரிவான மறுப்பை வெளியிட்டது. சர்ச்சைக்குரிய குறியீடு, இரண்டு திட்டங்களும் பகிர்ந்து கொள்ளும் MPL உரிமம் பெற்ற வரலாற்றிலிருந்து வந்தவை என்பதை அது நிரூபித்தது. பொதுவெளியில் இதற்கு மேல் எந்த நடவடிக்கையும் எடுக்கப்படவில்லை. அந்த நிகழ்வில் கவனிக்க வேண்டிய உண்மையான ஆபத்து இதுதான்: ஒரு குற்றச்சாட்டு மட்டுமே ஒரு தொழில்நுட்பத்தின் பயன்பாட்டை ஒரு காலாண்டு காலத்திற்கு முடக்க முடியும். முப்பது ஆண்டுகளுக்கு முன்பு Berkeley வழக்கின் விளைவும் இதுவே.

ஒவ்வொரு fork-ம் உரிம மாற்றத்தினால் தொடங்குவதில்லை. 2022-ல் Gitea-ன் மேம்பாடு ஒரு நிறுவனத்தின் கீழ் சென்ற பிறகு, Forgejo அதிலிருந்து பிரிந்தது. இது உரிமம் சார்ந்த சிக்கலை விட, நிர்வாகம் சார்ந்த சிக்கலாகும். Forgejo தனது 8-வது பதிப்பு வரை MIT உரிமத்திலேயே இருந்தது. பின்னர் 2024-ல் 9.0 பதிப்பிலிருந்து GPLv3 அல்லது அதற்குப் பிந்தைய உரிமத்திற்கு மாறியது. இதனால் அதன் பணிகளை மீண்டும் வணிக ரீதியாகக் கட்டுப்படுத்தப்படும் தயாரிப்புகளுக்குள் கொண்டு வர முடியாது. நீங்கள் self-hosted Git server விருப்பங்களை ஒப்பிட்டுப் பார்க்கிறீர்கள் என்றால், ஒரே codebase மற்றும் இரண்டு வெவ்வேறு கொள்கைகளுக்கு இந்த ஜோடி மிகத் தெளிவான உதாரணம்.

எந்தவொரு தொழில்நுட்பத்தையும் ஏற்றுக்கொள்வதற்கு முன் செய்ய வேண்டிய சோதனை

முதல் நிறுவலுக்குப் பிறகு அல்ல, அதற்கு முன்பே கேட்க வேண்டிய நான்கு கேள்விகள்.

1. பதிப்புரிமை (copyright) யாரிடம் உள்ளது? உரிமத்தை மாற்றுவதற்கு (relicensing) ஒவ்வொரு பதிப்புரிமைதாரரின் அனுமதியும் தேவை. எனவே, நூற்றுக்கணக்கான தனிப்பட்ட பங்களிப்பாளர்களைக் கொண்ட மற்றும் உரிமங்களை மாற்றும் அதிகாரம் யாரிடமும் இல்லாத ஒரு திட்டத்தை நடைமுறையில் மாற்ற முடியாது. ஒரு நிறுவனம் அனைத்தையும் சொந்தமாகக் கொண்ட திட்டத்தை, அதன் நிர்வாகக் குழு கூட்டத்தின் மூலம் உரிமத்தை மாற்ற முடியும்.
2. CLA உள்ளதா, அது எதை வழங்குகிறது? ஒரு நிறுவனம் உங்கள் பங்களிப்பை அவர்கள் விரும்பும் எந்தவொரு நிபந்தனையின் கீழும் மீண்டும் உரிமம் வழங்க அனுமதிக்கும் ஒரு Contributor Licence Agreement (CLA), மேலே குறிப்பிட்ட அனைத்து உரிம மாற்றங்களுக்கும் அடிப்படையான பொறிமுறையாகும். 2004-ல் Linux kernel ஏற்றுக்கொண்ட DCO (developer certificate of origin) எனும் sign-off வரி, எந்தவொரு உரிமையையும் மாற்றாது. ஒரு நிறுவனத்திடம் இருக்கும் CLA-வை விட, ஒரு அறக்கட்டளையிடம் (foundation) இருக்கும் CLA பாதுகாப்பானது, ஏனெனில் நிறுவனங்களை விற்க முடியும்.
3. வர்த்தக முத்திரை (trademark) யாருக்குச் சொந்தம்? Elastic நிறுவனம் Elasticsearch என்ற பெயரைத் தக்கவைத்துக் கொண்டது. எனவே, அதன் fork-க்கு வேறு பெயர் சூட்ட வேண்டியிருந்தது, மேலும் Kibana-வைக் குறிப்பிடும் ஒவ்வொரு runbook-ஐயும் மீண்டும் எழுத வேண்டியிருந்தது.
4. உரிம மாற்றம் உங்களுக்கு என்ன செலவை ஏற்படுத்தும்? தரவு வடிவம் (data format), client libraries, நீங்கள் மீண்டும் எழுத வேண்டிய configuration மற்றும் இணக்கமான fork ஏற்கனவே உள்ளதா ஆகியவற்றைக் கணக்கிடுங்கள்.

இரண்டு கட்டளைகள் இதற்கான பதிலை நொடிகளில் வழங்கும்.

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

ஒவ்வொரு Debian மற்றும் Ubuntu தொகுப்பும் /usr/share/doc/<package>/copyright-ல் ஒரு கோப்பை வழங்குகிறது. இது நீங்கள் நிறுவிய பதிப்பின் உரிமத்தைப் பதிவு செய்கிறது, திட்டத்தின் தற்போதைய உரிமத்தை அல்ல. Ubuntu 24.04-ல் bash-க்கு, அந்த கோப்பு GNU General Public License version 3-ஐக் குறிப்பிடுகிறது. ஒரு source checkout-க்குள் இரண்டாவது கட்டளையை இயக்கினால், உரிமக் கோப்பின் வரலாற்றைப் பெறலாம். கடந்த இரண்டு ஆண்டுகளில் அங்கு ஒரு commit செய்யப்பட்டிருந்தால், அந்தத் திட்டத்தில் எதையும் உருவாக்கும் முன் அதைப் படிப்பது அவசியம். கட்டளை எதையும் காட்டவில்லை என்றால், அந்த repository அதன் உரிமக் கோப்பிற்கு வேறு பெயர் வைத்திருக்கும்; எனவே root directory-ஐப் பட்டியலிட்டுப் பார்க்கவும்.

எந்தவொரு உரிமமும் உங்களை எல்லா விளைவுகளிலிருந்தும் பாதுகாக்காது. கொள்கையின் அடிப்படையில் மட்டும் தேர்ந்தெடுப்பதே மக்கள் ஏமாற்றமடையக் காரணமாகிறது. பதிப்புரிமை பலரிடம் பகிரப்பட்ட அல்லது ஒரு அறக்கட்டளையிடம் உள்ள திட்டங்களுக்கு முன்னுரிமை கொடுங்கள். உங்கள் தரவை நீங்கள் export செய்யக்கூடிய வடிவத்தில் வைத்திருங்கள். பிறகு, நீங்கள் எந்த fork-க்கு மாறலாம் என்பதைக் கண்டறிந்து, தேவைப்படுவதற்கு முன்பே அதன் பெயரை எழுதி வையுங்கள். ஒவ்வொரு வேட்பாளருக்கும் இந்தச் சோதனையைச் செய்ய ஒரு மணி நேரத்திற்கும் குறைவான நேரமே ஆகும். 2026-ல் எதை self-host செய்வது என்று முடிவெடுக்கும்போது, ஒரு upgrade-க்கும் migration-க்கும் இடையிலான வித்தியாசத்தை இதுவே தீர்மானிக்கிறது.

FAQ

MIT உரிமமும் BSD உரிமமும் ஒன்றா?

செயல்முறையில், MIT என்பது 2-clause BSD உரிமத்தைப் போன்றது: பதிப்புரிமை அறிவிப்பு மற்றும் உத்தரவாத மறுப்பைத் தக்கவைத்துக்கொண்டு, மூடிய தயாரிப்பை உருவாக்குவது உட்பட நீங்கள் விரும்பியதைச் செய்யலாம். 3-clause BSD உரிமம் ஒரு விஷயத்தைச் சேர்க்கிறது: அனுமதியின்றி உங்கள் தயாரிப்பை ஆதரிக்க பங்களிப்பாளர்களின் பெயர்களைப் பயன்படுத்தத் தடை விதிக்கிறது. பழைய 4-clause பதிப்பில் விளம்பரப் பொருட்களில் அங்கீகாரம் கோரப்பட்டது, UC Berkeley 22 July 1999 அன்று அந்த நிபந்தனையை நீக்கியது, எனவே தற்போது நடைமுறையில் உள்ளவற்றில் மிகச் சிலவே அதைத் தாங்கி நிற்கின்றன.

Apache 2.0 குறியீட்டை GPLv2 திட்டத்தில் சேர்க்கலாமா?

முடியாது. Apache 2.0, GPLv2 அனுமதிக்காத நிபந்தனைகளைச் சேர்க்கிறது, குறிப்பாக காப்புரிமை முடித்தல் (patent termination) விதி. எனவே, இணைக்கப்பட்ட ஒரு பணி ஒரே நேரத்தில் இரண்டு உரிமங்களையும் பூர்த்தி செய்ய முடியாது. FSF மற்றும் ASF ஆகிய இரண்டுமே இந்த முடிவை வெளியிடுகின்றன. மறுபுறம் இது சாத்தியம்: Apache 2.0 குறியீட்டை GPLv3 திட்டத்தில் சேர்க்கலாம், அதன் விளைவாகக் கிடைக்கும் பணி GPLv3 ஆகும். இதனால்தான் Apache 2.0 குறியீட்டை Linux kernel-ல் இணைக்க முடியாது, ஏனெனில் அது GPL version 2 மட்டுமே.

SSPL ஒரு open source உரிமமா?

இல்லை, இந்த பதிலுக்கு நடைமுறை விளைவுகள் உள்ளன. OSI இதற்கு ஒருபோதும் ஒப்புதல் அளிக்கவில்லை, மார்ச் 2019-ல் MongoDB தனது விண்ணப்பத்தைத் திரும்பப் பெற்றது. டிசம்பர் 2018-ல் Debian, SSPL மென்பொருள் அதன் காப்பகத்திற்குள் சேரவில்லை என்று கூறியது, ஜனவரி 2019-ல் Fedora இந்த உரிமம் இலவசமானது அல்ல என்று தீர்ப்பளித்தது. அதன் பிறகு Red Hat, MongoDB-ஐ Fedora மற்றும் Red Hat Enterprise Linux-லிருந்து நீக்கியது. உங்களைப் பொறுத்தவரை, உங்கள் விநியோகஸ்தர் பராமரித்து வந்த ஒரு தொகுப்பு, இப்போது விற்பனையாளரின் ஆதரவு கால அட்டவணைப்படி அவர்களின் களஞ்சியத்திலிருந்து வருகிறது என்று அர்த்தம். Business Source License-ம் open source என்பதற்குப் பதிலாக source available என்றே கருதப்படுகிறது, இருப்பினும் ஒவ்வொரு வெளியீடும் நான்கு ஆண்டுகளுக்குள் open source உரிமமாக மாறிவிடும்.

உரிம மாற்றம் நான் ஏற்கனவே இயக்கும் பதிப்பிற்குப் பொருந்துமா?

இல்லை. ஒரு வெளியீட்டுடன் வழங்கப்பட்ட உரிமத்தை ஏற்கனவே வெளியிடப்பட்ட பிரதிகளிலிருந்து திரும்பப் பெற முடியாது, இதனால்தான் forks சாத்தியமாகிறது. Elasticsearch 7.10.2-லிருந்து OpenSearch உருவாக்கப்பட்டது, இது Elastic நிறுவனம் Apache 2.0-ன் கீழ் வெளியிட்ட கடைசி பதிப்பாகும். நீங்கள் இழப்பது எதிர்காலத்தைத்தான், ஏனெனில் அடுத்த பாதுகாப்புத் திருத்தம் புதிய நிபந்தனைகளின் கீழ் வரும். தாராளமான உரிமம் கொண்ட கடைசி பதிப்பைப் பயன்படுத்துவது உங்களுக்குச் சில மாதங்களை மட்டுமே பெற்றுத்தரும், இது ஒரு நிரந்தரத் திட்டம் அல்ல.