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

GPL, MIT மற்றும் 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 மற்றும் அவை எவை அல்ல

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

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

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

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

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

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

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

இந்தக் கதை மேலும் இரண்டு முறை மாறியது. 29 ஆகஸ்ட் 2024 அன்று Elastic நிறுவனம் AGPLv3-ஐ மூன்றாவது உரிம விருப்பமாகச் சேர்த்தது, எனவே தற்போதைய 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 இதை ஒருபோதும் அங்கீகரிக்கவில்லை, மேலும் MongoDB மார்ச் 2019-ல் தனது விண்ணப்பத்தைத் திரும்பப் பெற்றது. டிசம்பர் 2018-ல் Debian, SSPL மென்பொருள் அதன் காப்பகத்திற்குள் இருக்காது என்று கூறியது. ஜனவரி 2019-ல் Fedora இந்த உரிமம் இலவசமானது அல்ல என்று தீர்ப்பளித்தது, அதன் பிறகு Red Hat தனது Fedora மற்றும் Red Hat Enterprise Linux ஆகியவற்றிலிருந்து MongoDB-ஐ நீக்கியது. இதைப் பொறுத்தவரை, உங்கள் distribution பராமரித்து வந்த ஒரு package இப்போது vendor-ன் repository-லிருந்து மட்டுமே கிடைக்கும், அது அந்த vendor-ன் ஆதரவு கால அட்டவணையைப் பொறுத்தது. Business Source License என்பதும் open source அல்ல, அது source available வகையைச் சேர்ந்தது, இருப்பினும் ஒவ்வொரு வெளியீடும் நான்கு ஆண்டுகளுக்குள் open source உரிமத்திற்கு மாறிவிடும்.

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

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