Open Source மென்பொருளின் வரலாறு மற்றும் அதன் பரிணாமம்

Open source software என்றால் என்ன, அது எங்கிருந்து வந்தது

Open source software-ன் வரலாறு பெரும்பாலும் அதன் உரிமங்களின் (licences) வரலாறே ஆகும். ஏனெனில், மற்றவர் எழுதிய குறியீட்டை (code) நீங்கள் என்ன செய்யலாம் என்பதைத் தீர்மானிக்கும் ஒரே காரணி அந்த உரிமம் மட்டுமே. அந்த உரிமங்கள் எழுதப்படுவதற்கு நீண்ட காலத்திற்கு முன்பே குறியீடுகள் வெளிப்படையாகப் பகிரப்பட்டன. அவை ஒரு பொருளாக (product) மாறியவுடன் பகிரப்படுவது நின்றது; நீதிமன்றத்தில் பகிர்வு முறையானது என்பதை உறுதிப்படுத்தவே இந்த உரிமங்கள் எழுதப்பட்டன.

இது சுருக்கமான வரலாறு. விரிவான வரலாறு முக்கியமானது, ஏனெனில் இன்று நீங்கள் server-ல் இயக்கும் மென்பொருட்கள் அந்த முடிவுகளின் தாக்கத்தைக் கொண்டுள்ளன. அவற்றில் சில முடிவுகள் 1983-ல் எடுக்கப்பட்டன. சில கடந்த ஆண்டு எடுக்கப்பட்டன. எங்கள் self-hosting வழிகாட்டிகளில் உள்ள சில பயன்பாடுகள் ஏன் வெவ்வேறு பெயர்களில் இரண்டு பதிப்புகளாக வருகின்றன என்பதற்கு அந்த முடிவுகளே காரணம்.

மென்பொருள் விற்பனைக்கு வருவதற்கு முன்பே பகிரப்பட்டது

1950-கள் மற்றும் 1960-களில், மென்பொருள் இயந்திரத்துடன் இணைந்தே வந்தது. IBM தனது கணினிகளுடன் source code-ஐ வழங்கியது. 1955-ல் தொடங்கப்பட்ட SHARE போன்ற பயனர் குழுக்கள், நிரல்களை tape மூலம் ஒருவரிடமிருந்து ஒருவருக்குப் பகிர்ந்துகொண்டன. இரண்டு காரணங்கள் இந்த நிலையை மாற்றின. 1969-ல், மென்பொருளை வன்பொருளிலிருந்து தனி விலையில் விற்பதாக IBM அறிவித்தது; இது மென்பொருளுக்கெனத் தனிச் சந்தையை உருவாக்கியது. அதன் பிறகு சட்டங்கள் மாற்றமடைந்தன. 1980-ன் Computer Software Copyright Act, அமெரிக்காவில் கணினி நிரல்கள் பதிப்புரிமைக்கு உட்பட்டவை என்பதை உறுதிப்படுத்தியது. 1980-க்குப் பிறகு, நீங்கள் எழுதாத code இயல்பாகவே closed-source ஆனது; எனவே, அதைப் பகிர ஆசிரியரின் எழுத்துப்பூர்வமான அனுமதி தேவைப்பட்டது.

The Homebrew Computer Club மற்றும் Hobbyists-க்கான திறந்த மடல்

The Homebrew Computer Club தனது முதல் கூட்டத்தை 1975 மார்ச் மாதம் கலிபோர்னியாவின் மென்லோ பூங்காவில் உள்ள ஒரு கேரேஜில் நடத்தியது. உறுப்பினர்கள் வன்பொருள் மற்றும் பேப்பர் டேப்களைக் கொண்டு வந்தனர், மேலும் நகல் எடுப்பது கூட்டத்தின் ஒரு பகுதியாக இருந்தது. பில் கேட்ஸ் மற்றும் பால் ஆலன் எழுதிய Altair BASIC, நகல் எடுக்கப்பட்ட டேப் வடிவில் அறை முழுவதும் பகிரப்பட்டது. 1976 பிப்ரவரி மாதம், கிளப்பின் செய்திமடலில் "An Open Letter to Hobbyists" என்ற தலைப்பில் கேட்ஸ் பதிலளித்தார்.

பெரும்பாலான பொழுதுபோக்கு ஆர்வலர்களுக்குத் தெரிந்திருக்கும், உங்களில் பலர் உங்கள் மென்பொருளைத் திருடுகிறீர்கள்.

Altair உரிமையாளர்களில் பத்தில் ஒரு பங்கிற்கும் குறைவானவர்களே BASIC-க்கு பணம் செலுத்தியுள்ளனர் என்றும், அதை எழுதுவதற்கு செலவிடப்பட்ட கணினி நேரம் 40,000 டாலர்களுக்கும் அதிக மதிப்புடையது என்றும் அவர் எழுதினார். நவீன காலத்தின் அனைத்து விவாதங்களும் அந்த மடலிலேயே ஏற்கனவே உள்ளன. மென்பொருளை நகலெடுப்பதற்கு எந்தச் செலவும் இல்லை, அது நகலெடுப்பவர்களுக்கு உதவுகிறது. ஆனால், அதை உருவாக்குவதற்கு ஒருவரின் வாழ்நாளில் ஒரு வருடம் செலவாகிறது. கீழே விவரிக்கப்பட்டுள்ள ஒவ்வொரு உரிமமும் (licence) இந்த இரண்டு உண்மைகளுக்கும் ஒரே நேரத்தில் பதிலளிக்கும் முயற்சியாகும்.

1983-ல் GNU மற்றும் சட்டப்பூர்வ கண்டுபிடிப்பாக GPL

Richard Stallman 1983 செப்டம்பர் மாதம் Usenet-ல் GNU-வை அறிவித்தார். இது இணையத்திற்கு முன்பிருந்த செய்திக்குழு பிணையமாகும். GNU என்பது "GNU's Not Unix" என்பதன் சுருக்கமாகும். எவரும் நகலெடுக்கவும் மாற்றவும் கூடிய முழுமையான Unix-இணக்கமான அமைப்பை உருவாக்குவதே இதன் திட்டமாக இருந்தது.

இலவச Unix! இந்த நன்றி செலுத்தும் நாள் (Thanksgiving) முதல், நான் GNU (Gnu's Not Unix என்பதன் சுருக்கம்) என்று அழைக்கப்படும் முழுமையான Unix-இணக்கமான மென்பொருள் அமைப்பை எழுதப்போகிறேன். இதைப் பயன்படுத்தக்கூடிய அனைவருக்கும் இதை இலவசமாக வழங்கப்போகிறேன்.

Free Software Foundation (FSF) 1985-ல் தொடங்கப்பட்டது. அதன் இலவச மென்பொருள் வரையறை (Free Software Definition) நான்கு சுதந்திரங்களை பட்டியலிடுகிறது, அவை பூஜ்ஜியத்திலிருந்து எண்ணப்படுகின்றன: எந்தவொரு நோக்கத்திற்காகவும் நிரலை இயக்குதல், அதை ஆய்வு செய்து மாற்றுதல், நகல்களை மறுவிநியோகம் செய்தல் மற்றும் நீங்கள் மாற்றியமைத்த பதிப்புகளை விநியோகித்தல். சுதந்திரம் 1-க்கு source code தேவைப்படுகிறது, ஏனெனில் ஒரு binary-ஐ நடைமுறையில் யாரும் ஆய்வு செய்ய முடியாது. இங்கே "இலவச" (Free) என்பது சுதந்திரத்தைக் குறிக்கிறது, விலையல்ல. FSF-ன் சொந்த சொற்றொடர், இது பேச்சு சுதந்திரத்தைப் போன்றது, இலவச பீர் போன்றதல்ல.

அறிவிக்கை (manifesto) கண்டுபிடிப்பு அல்ல, உரிமமே (licence) கண்டுபிடிப்பு. GNU General Public License (GPL) பதிப்புரிமையைப் (copyright) பயன்படுத்தி, பகிர்வதைத் தடுப்பதற்குப் பதிலாக, பகிர்வதை கட்டாயமாக்குகிறது. நீங்கள் நான்கு சுதந்திரங்களையும் ஒரு நிபந்தனையுடன் பெறுகிறீர்கள்: நீங்கள் யாருக்கு மென்பொருளை வழங்குகிறீர்களோ, அவர்களும் அந்த சுதந்திரங்களை source code-உடன் பெற வேண்டும். Stallman இதை copyleft என்று அழைத்தார். இது முதலில் 1985-ல் GNU Emacs-உடன் வெளியிடப்பட்டது, 1989-ல் GPL பதிப்பு 1 ஆகவும், 1991 ஜூன் மாதம் பதிப்பு 2 ஆகவும் மாறியது.

GPL பதிப்புரிமைச் சட்டத்திற்கு எதிராகச் செயல்படாமல், அதன் அடிப்படையில் செயல்படுவதால் இது வேலை செய்கிறது. உரிமம் இல்லாமல் ஒருவருடைய code-ஐ விநியோகிக்க உங்களுக்கு எந்த உரிமையும் இல்லை. GPL அந்த உரிமையை வழங்கி, அதனுடன் நிபந்தனைகளை இணைக்கிறது. எனவே, ஒரு router-க்குள் மாற்றியமைக்கப்பட்ட GPL code-ஐ விநியோகித்துவிட்டு, source code-ஐ வழங்க மறுக்கும் ஒரு விற்பனையாளர், வாக்குறுதியை மீறவில்லை. அவர்கள் பதிப்புரிமையை மீறுகிறார்கள், இதை ஒரு பதிப்புரிமைதாரர் நீதிமன்றத்திற்கு எடுத்துச் செல்ல முடியும். இதனால்தான் அமலாக்கம் சாத்தியமாகிறது; 2000-களில் Harald Welte-ன் gpl-violations.org வழக்குகள் முதல், 2021-ல் Vizio-விற்கு எதிராகத் தொடரப்பட்ட Software Freedom Conservancy வழக்கு வரை இது பொருந்தும். அந்த வழக்கு, தொலைக்காட்சியை வாங்கிய ஒரு நபர் source code-ஐக் கோர முடியும் என்று வாதிடுகிறது.

Linux கணினியை நிறைவு செய்தது

1991-ஆம் ஆண்டிற்குள் GNU திட்டம் compiler, C library, shell மற்றும் பெரும்பாலான கருவிகளைக் கொண்டிருந்தது. ஆனால், அதனிடம் இயங்கக்கூடிய kernel இல்லை. ஏனெனில், GNU-வின் சொந்த kernel-ஆன Hurd, திட்டமிட்டதை விட அதிக காலம் எடுத்துக்கொண்டது. 1991 ஆகஸ்ட் மாதம், ஹெல்சின்கியைச் சேர்ந்த ஒரு மாணவர் comp.os.minix newsgroup-ல் பின்வருமாறு பதிவிட்டார்:

நான் 386(486) AT clones-க்காக ஒரு (இலவச) operating system-ஐ உருவாக்குகிறேன் (இது வெறும் பொழுதுபோக்குதான், gnu போல பெரியதாகவும் தொழில்முறை சார்ந்ததாகவும் இருக்காது).

Linux 0.01, 1991 செப்டம்பர் மாதம் Linus Torvalds சொந்தமாக எழுதிய உரிமத்தின் (licence) கீழ் வெளியானது; அது விற்பனையைத் தடை செய்தது. 1992-ன் தொடக்கத்தில் அவர் அதை GPLv2 உரிமத்திற்கு மாற்றினார். இதுவே தனது சிறந்த முடிவுகளில் ஒன்று என்று அவர் கூறியுள்ளார். இந்த உரிமம் தான் பெருநிறுவனங்களின் பங்களிப்பைப் பாதுகாப்பானதாக்கியது: ஒரு நிறுவனம் தனது பொறியாளர்களை kernel உருவாக்கத்தில் ஈடுபடுத்தும்போது, ஒரு போட்டியாளர் அந்த மேம்பாடுகளைத் தனியாக்க முடியாது என்பதை அவர்கள் அறிந்திருந்தனர்.

பெர்க்லியில் ஏற்கனவே ஒரு இலவச Unix இருந்தது. Linux, BSD (Berkeley Software Distribution)-ஐ விட முன்னிலை பெற்று இயல்பான இலவச Unix-ஆக மாறியதற்கு ஒரு வழக்கு முக்கிய காரணமாகும். Unix System Laboratories, 1992-ல் Berkeley Software Design மீது வழக்கு தொடர்ந்தது; அந்த வழக்கு 1994-ன் தொடக்கம் வரை நீடித்தது. அந்த இரண்டு ஆண்டுகளும் BSD அமைப்புகள் சட்டரீதியான அபாயத்தைச் சந்தித்தன, ஆனால் Linux எந்த அபாயமும் இன்றி இருந்தது. அந்த காலகட்டத்தில்தான் பயனர்கள் Linux-க்கு வந்தனர். Linux என்பது kernel மட்டுமே, அதைச் சுற்றியுள்ள பெரும்பாலான கருவிகள் GNU-வைச் சேர்ந்தவை என்பதால், ஒருங்கிணைந்த அமைப்பை GNU/Linux என்று அழைக்குமாறு FSF கேட்டுக்கொள்கிறது. பெரும்பாலான மக்கள் இதை Linux என்றே அழைக்கின்றனர். இரண்டு பெயர்களும் ஒரே மென்பொருள் தொகுப்பையே குறிக்கின்றன.

1998: open source மறுபெயரிடல் மற்றும் ஆறாத பிளவு

1998 ஜனவரியில், தனது browser-ன் source code-ஐ வெளியிடப்போவதாக Netscape அறிவித்தது. இத்தகைய செயலைச் செய்த மிகப்பெரிய நிறுவனம் அதுவே, இது ஒரு நடைமுறைச் சிக்கலை வெளிப்படுத்தியது. ஆங்கிலத்தில் "free software" என்ற சொற்றொடர் "விலையில்லா மென்பொருள்" (software that costs nothing) என்று பொருள்படுவதால், நிறுவன நிர்வாகிகள் அதை அப்படியே புரிந்துகொண்டனர். சிறந்த ஒரு சொல்லைக் கண்டறிய 1998 பிப்ரவரியில் Palo Alto-வில் ஒரு குழு கூடியது. அப்போது Christine Peterson "open source" என்ற சொல்லைப் பரிந்துரைத்தார். சில வாரங்களிலேயே Eric Raymond மற்றும் Bruce Perens ஆகியோர் Open Source Initiative (OSI)-ஐ நிறுவினர். 1997-ல் Perens எழுதிய Debian Free Software Guidelines-ஐ அடிப்படையாகக் கொண்டு, Open Source Definition-ஐ அவர்கள் ஏற்றுக்கொண்டனர்.

Open Source Definition பத்து அளவுகோல்களைக் கொண்டுள்ளது. அவற்றில் இரண்டு, தற்கால விவாதங்களில் பெரும்பான்மையானவற்றைத் தீர்மானிக்கின்றன: source code கிடைக்க வேண்டும், மேலும் அந்த மென்பொருளை யார் பயன்படுத்தலாம் அல்லது எதற்காகப் பயன்படுத்தலாம் என்பதில் உரிமம் (licence) எந்தக் கட்டுப்பாட்டையும் விதிக்கக்கூடாது. "இதை நீங்கள் வணிக ரீதியான சேவையாக வழங்கக்கூடாது" என்று கூறும் ஒரு உரிமம், அது வேறு எதை அனுமதித்தாலும், இந்தச் சோதனையில் தோல்வியடைகிறது. இந்த வாக்கியத்தை நினைவில் கொள்ளுங்கள். இன்றைய source-available உரிமங்கள் மீறும் எல்லை இதுதான்.

1998-ல் உருவான பிளவு, எந்த உரிமங்கள் ஏற்கத்தக்கவை என்பது பற்றியது அல்ல, மாறாக அதற்கான காரணங்கள் பற்றியது. FSF-ன் வாதம் அறம் சார்ந்தது: ஒரு மென்பொருளை மாற்ற முடியாத பயனர், தனது சொந்த கணினியைக் கட்டுப்படுத்த முடியாது. Raymond-ன் "The Cathedral and the Bazaar" என்ற கட்டுரையின் மூலம் வணிக நிறுவனங்களிடம் முன்வைக்கப்பட்ட OSI-ன் வாதம் நடைமுறை சார்ந்தது: வெளிப்படையான மேம்பாடு (open development) சிறந்த மென்பொருளை உருவாக்குகிறது, ஒரு நிறுவனம் அதைச் சாதகமாகப் பயன்படுத்திக்கொள்ளலாம். Stallman-ன் பதிலுரையான "Why Open Source Misses the Point of Free Software" இன்றும் gnu.org-ல் உள்ளது; அவர் புதிய சொல்லை ஒருபோதும் ஏற்றுக்கொள்ளவில்லை. அதை உருவாக்க உதவிய Perens, இந்த இயக்கம் free software-லிருந்து விலகிச் சென்றுவிட்டதாகக் கூறி 1999-ல் OSI வாரியத்திலிருந்து விலகினார்.

நடைமுறை ரீதியாக இவற்றுக்கு இடையேயான இடைவெளி எவ்வளவு சிறியது என்பதைத் துல்லியமாகப் புரிந்துகொள்வது அவசியம். FSF-ன் free licences பட்டியலும், OSI-ன் அங்கீகரிக்கப்பட்ட உரிமங்களின் பட்டியலும் GPL, MIT, Apache 2.0 மற்றும் BSD உள்ளிட்ட அனைத்திலும் கிட்டத்தட்ட உடன்படுகின்றன. இரண்டு அர்த்தங்களையும் ஒரே நேரத்தில் பயன்படுத்த விரும்பும் எழுத்தாளர்கள் FOSS (free and open source software) அல்லது FLOSS (free/libre and open source software) என்ற சொற்களைப் பயன்படுத்துகின்றனர்.

நிறுவனங்கள் எவ்வாறு code-ஐ வெளியிடுவது என்பதைக் கற்றுக்கொண்டன

1999-ல் Red Hat பங்குச்சந்தையில் பட்டியலிடப்பட்ட நிகழ்வு, மென்பொருள் பிரதிகளை விற்பதை விட, ஆதரவு (support) மற்றும் தொகுப்பு (packaging) சேவைகளில் அதிக வருவாய் இருப்பதை நிரூபித்தது. 2001-ல் IBM நிறுவனம் Linux-க்காக ஒரு பில்லியன் டாலர்களை முதலீடு செய்வதாக அறிவித்தது. 2001-ல் Microsoft-ன் தலைமை நிர்வாக அதிகாரி Linux-ஐ "ஒரு புற்றுநோய்" என்று விமர்சித்தார்; ஆனால் அதே நிறுவனம் 2016-ல் Linux Foundation-ல் பிளாட்டினம் உறுப்பினராக இணைந்தது. பின்னர் 2018-ல் 7.5 பில்லியன் டாலர் மதிப்புள்ள பங்குகளை வழங்கி GitHub-ஐ வாங்கியது. 2019-ல் IBM நிறுவனம் 34 பில்லியன் டாலர்களுக்கு Red Hat-ஐ வாங்கியது. இவை அனைத்தும் உரிமங்கள் (licences) குறித்த கொள்கை மாற்றங்கள் அல்ல; மாறாக, வருவாய் ஈட்டும் வழிமுறைகளில் ஏற்பட்ட மாற்றங்களே. ஒரு operating system என்பது பகிரப்பட்ட செலவாக இருக்கும்போது, அதைத் தனியாகப் பராமரிப்பது அதிக செலவை ஏற்படுத்தும். எனவே, அனைத்து விற்பனையாளர்களும் அதற்கு மேலேயுள்ள அடுக்கில் (layer) போட்டியிடவே விரும்புகின்றனர்.

நிறுவனங்களின் உரிமை மாற்றம் எதிர்மறையான விளைவுகளையும் ஏற்படுத்தியுள்ளது. 2010-ல் Oracle நிறுவனம் Sun-ஐ வாங்கியபோது, MySQL மற்றும் OpenOffice.org ஆகியவையும் அதனுடன் சேர்ந்தன; இதனால் அந்த இரண்டு சமூகங்களும் வெளியேறின. MySQL-லிருந்து MariaDB உருவானது, 2010 செப்டம்பரில் OpenOffice.org-லிருந்து LibreOffice பிரிக்கப்பட்டது (forked). ஒரு பயனர் சமூகம் கொண்டிருக்கும் ஒரே அதிகாரம் இந்த fork மட்டுமே; அந்த அதிகாரத்தை உரிமங்களே (licence) சாத்தியமாக்குகின்றன.

நீங்கள் self-host செய்யும் சில செயலிகளுக்கு ஏன் forks உள்ளன

2018-ஆம் ஆண்டு முதல், ஒரு குழு நிறுவனங்கள் தாங்கள் ஏற்கனவே வெளியிட்ட மென்பொருட்களின் உரிம நிபந்தனைகளை மாற்றின. ஒவ்வொரு முறையும் சூழல் ஒன்றாகவே இருந்தது. ஒரு நிறுவனம் பெரும்பாலான மென்பொருள் உருவாக்குநர்களைப் பணியமர்த்தியிருந்தது; ஒரு பெரிய cloud provider அதே மென்பொருளை நிர்வகிக்கப்படும் சேவையாக (managed service) விற்பனை செய்தது; சிறிய நிறுவனம் தனது போட்டியின்மைக்கு உரிமமே காரணம் என்று முடிவு செய்தது.

• MongoDB அக்டோபர் 2018-ல் Server Side Public License (SSPL)-ஐ ஏற்றுக்கொண்டது. நீங்கள் மென்பொருளை மற்றவர்களுக்குச் சேவையாக வழங்கினால், அந்தச் சேவையை வழங்க நீங்கள் பயன்படுத்தும் அனைத்தின் source code-ஐயும் வெளியிட வேண்டும் என்று SSPL கூறுகிறது. OSI இதை open source-ஆக ஏற்கவில்லை, எனவே 2019-ல் MongoDB இதை மறுஆய்விலிருந்து திரும்பப் பெற்றது.
• Redis 2018 மற்றும் 2019-ல் சில தொகுதிகளுக்குப் பயன்பாட்டுக் கட்டுப்பாடுகளைச் சேர்த்தது, பின்னர் மார்ச் 2024-ல் பதிப்பு 7.4 உடன் முதன்மை server-ஐ dual source-available நிபந்தனைகளுக்கு மாற்றியது. கடைசியாக BSD-உரிமம் பெற்ற வெளியீட்டின் fork, Valkey என்ற பெயரில் சில நாட்களுக்குப் பிறகு Linux Foundation-ன் கீழ் தோன்றியது; இதற்கு Amazon, Google மற்றும் Oracle உள்ளிட்ட நிறுவனங்கள் ஆதரவளித்தன. மே 2025-ல் Redis, OSI-ஆல் அங்கீகரிக்கப்பட்ட Affero General Public License version 3 (AGPLv3)-ஐ Redis 8-க்கான மூன்றாவது விருப்பமாகச் சேர்த்தது.
• Elastic ஜனவரி 2021-ல் Elasticsearch மற்றும் Kibana-வை Apache 2.0-லிருந்து மாற்றி, dual SSPL மற்றும் Elastic License நிபந்தனைகளுக்குக் கொண்டு வந்தது. Amazon, OpenSearch-ஐ fork செய்தது. ஆகஸ்ட் 2024-ல் Elastic, AGPLv3-ஐ மூன்றாவது விருப்பமாகச் சேர்த்தது, மேலும் செப்டம்பர் 2024-ல் OpenSearch, OpenSearch Software Foundation என்ற பெயரில் Linux Foundation-க்கு மாற்றப்பட்டது.
• HashiCorp, Terraform மற்றும் அதன் பிற கருவிகளை ஆகஸ்ட் 2023-ல் Business Source License (BUSL)-க்கு மாற்றியது. BUSL நடைமுறையில் இருக்கும்போது அது open source உரிமம் அல்ல, ஏனெனில் அது போட்டியிடும் வணிகப் பயன்பாட்டைத் தடை செய்கிறது. ஒவ்வொரு வெளியீடும் நான்கு ஆண்டுகளுக்குப் பிறகு ஒரு குறிப்பிட்ட தேதியில் open உரிமத்திற்கு மாறுகிறது. OpenTofu சில வாரங்களிலேயே fork செய்யப்பட்டது, அதுவும் இப்போது Linux Foundation-ன் கீழ் உள்ளது.

இதில் இரு தரப்பிற்கும் நியாயமான காரணங்கள் உள்ளன, யாரும் தவறான எண்ணத்துடன் செயல்படவில்லை. ஐம்பது பேருக்குச் சம்பளம் வழங்கும் ஒரு நிறுவனம், அதைவிடப் பெரிய நிறுவனம் தனது உழைப்பை மறுவிற்பனை செய்யும்போது சிக்கலைச் சந்திக்கிறது; அதை நல்லெண்ணத்தால் சரிசெய்ய முடியாது. Apache 2.0 நிபந்தனைகளின் கீழ் கட்டமைப்பை உருவாக்கிவிட்டு, திடீரென புதிய நிபந்தனைகளின் கீழ் விழித்தெழுந்த பயனருக்கும் சிக்கல் உள்ளது, அவர்களிடம் யாரும் முன்னரே கேட்கவில்லை. இந்த நிகழ்வுகளில் இரண்டில் அடுத்து என்ன நடந்தது என்பதைக் கவனியுங்கள். Forks உருவான பிறகு, Elastic மற்றும் Redis ஆகிய இரண்டுமே வலுவான copyleft உரிமத்தை மீண்டும் சேர்த்தன. Copyleft அசல் புகாருக்குப் பதிலளித்தது, ஏனெனில் AGPLv3 ஒரு சேவை வழங்குநர் தான் இயக்கும் மாற்றங்களை வெளியிட வேண்டும் என்று கட்டாயப்படுத்துகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இரண்டு திட்டங்களும் இரண்டு forks-களும் இன்னும் செயல்பாட்டில் உள்ளன; இதுவே உரிமங்கள் அனுமதிக்க வடிவமைக்கப்பட்ட முடிவாகும்.

உரிமத்தை (licence) மாற்ற யாருக்கு அதிகாரம் உண்டு

ஒரு திட்டத்தின் அனைத்துப் பகுதிகளின் பதிப்புரிமையும் (copyright) ஒரு தரப்பினரின் கட்டுப்பாட்டில் இருந்தால் மட்டுமே, அந்தத் திட்டத்தின் உரிமத்தை மாற்ற முடியும். நிறுவனங்கள் இரண்டு வழிகளில் இந்த உரிமையைப் பெறுகின்றன. Copyright assignment மூலம் ஒவ்வொரு பங்களிப்பின் உரிமையும் நிறுவனத்திடம் ஒப்படைக்கப்படுகிறது. Contributor licence agreement (CLA) முறையில், உரிமையாளர் நீங்களாகவே நீடிப்பீர்கள், ஆனால் உங்கள் பணியை மறு உரிமம் (relicense) செய்யும் அளவுக்கு விரிவான உரிமைகளை அந்த நிறுவனத்திற்கு வழங்குகிறீர்கள். உங்கள் முதல் pull request-ல் ஒரு bot இடும் இணைப்பைச் சொடுக்குவதன் மூலம், இவை இரண்டில் ஏதேனும் ஒன்று பொதுவாகக் கையொப்பமிடப்படுகிறது.

Linux-க்கு CLA கிடையாது. பங்களிப்புகள் GPLv2 மற்றும் Developer Certificate of Origin ஆகியவற்றின் கீழ் வருகின்றன, மேலும் பதிப்புரிமை ஆயிரக்கணக்கான நபர்கள் மற்றும் நிறுவனங்களிடையே பரவியுள்ளது. அந்த அனைத்துக் கையொப்பங்களையும் யாராலும் திரட்ட முடியாது என்பதால், Linux-ன் உரிமத்தை யாராலும் மாற்ற முடியாது. பல சுதந்திரமான பதிப்புரிமைதாரர்களைக் கொண்ட எந்தவொரு திட்டத்திற்கும் இதே பாதுகாப்பு பொருந்தும். இது ஒரு வாக்குறுதியை விட வலிமையான பாதுகாப்பு, ஏனெனில் இது யாருக்கு எது சொந்தம் என்ற உண்மையை அடிப்படையாகக் கொண்டது.

எனவே, நீங்கள் பயன்படுத்தத் திட்டமிடும் மென்பொருளைப் பொறுத்தவரை, அது இன்று open source-ஆக உள்ளதா என்பது முக்கியமல்ல. அதை யாரால் மாற்ற முடியும், அவர்களால் தனித்து அதைச் செய்ய முடியுமா என்பதே நீங்கள் கேட்க வேண்டிய கேள்வி.

ஒரு foundation உங்களுக்கு உண்மையில் என்ன வழங்குகிறது

ஒரு foundation சொத்துக்களைப் பாதுகாக்கிறது மற்றும் முடிவுகள் எடுக்கப்படும் விதத்திற்கான விதிகளை நிர்ணயிக்கிறது. Apache Software Foundation, Linux Foundation, அதற்குள் இருக்கும் Cloud Native Computing Foundation மற்றும் Software Freedom Conservancy ஆகிய ஒவ்வொன்றும் அந்தப் பணியின் ஒரு வடிவத்தைச் செய்கின்றன. ஒரு foundation மந்திரத்தால் நடுநிலையாக இருப்பதில்லை. உறுப்பினர்கள் தங்கள் இடங்களுக்குப் பணம் செலுத்துகிறார்கள், மேலும் ஒரு பெரிய foundation திட்டத்தில் முழுநேரமாகப் பணிபுரியும் பெரும்பாலானவர்களுக்கு உறுப்பினர் நிறுவனங்களே ஊதியம் வழங்குகின்றன. நீங்கள் பெறுவது குறுகியதாக இருந்தாலும் அதிக மதிப்புடையது: வர்த்தக முத்திரை (trademark) மற்றும் release process ஆகியவை ஒரே விற்பனையாளருக்குச் சொந்தமானவை அல்ல, எனவே எந்தவொரு தனி நிறுவனமும் அந்தத் திட்டத்தைத் தனியாக்க முடியாது.

வர்த்தக முத்திரை என்பது மக்கள் கவனிக்கத் தவறும் ஒரு பகுதியாகும். குறியீடு (code) உரிமம் பெற்றது. ஒரு பெயர் என்பது வர்த்தக முத்திரை, மேலும் வர்த்தக முத்திரை குறியீட்டு உரிமத்தின் கீழ் வராது. நீங்கள் எப்போதும் குறியீட்டை fork செய்யலாம். ஆனால் பொதுவாக அந்தப் பெயரைத் தக்கவைக்க முடியாது. இதனால்தான் இந்த வரலாற்றில் உள்ள forks, Valkey, OpenSearch, OpenTofu மற்றும் Forgejo என்று அழைக்கப்படுகின்றன.

பராமரிப்பாளர் சிக்கல்

நவீன உள்கட்டமைப்பு ஒன்று அல்லது இரண்டு ஊதியம் பெறாத பராமரிப்பாளர்களைக் கொண்ட திட்டங்களையே நம்பியுள்ளது; இத்திட்டங்களில் ஏற்படும் தோல்விகளே இச்சிக்கலை வெளிச்சத்திற்குக் கொண்டுவருகின்றன. 2014-ல் OpenSSL-ல் கண்டறியப்பட்ட Heartbleed பிழை, இணையத்தின் குறியாக்கம் செய்யப்பட்ட traffic-ல் பெரும் பகுதியைச் சுமந்து நின்ற ஒரு library-யைப் பாதித்தது. அது மிகக் குறைந்த நிதியுதவியுடன் ஒரு சில நபர்களால் மட்டுமே பராமரிக்கப்பட்டு வந்தது. 2021 டிசம்பரில் ஏற்பட்ட Log4Shell பாதிப்பு, Apache Log4j திட்டத்தில் இருந்த ஒரு சிறிய தன்னார்வலர் குழுவின் மூலம் உலகளாவிய incident response நடவடிக்கைகளைத் திசைதிருப்பியது.

2024 மார்ச் மாதம் கண்டறியப்பட்ட XZ Utils backdoor இதற்கு மிக முக்கியமான உதாரணமாகும், ஏனெனில் இந்தத் தாக்குதல் code-ஐக் குறிவைக்காமல் பராமரிப்பாளரையே குறிவைத்தது. ஒரு கணக்கு, Linux distributions முழுவதும் பயன்படுத்தப்படும் ஒரு compression library-யில் சுமார் இரண்டு ஆண்டுகளாக உண்மையான பயனுள்ள பங்களிப்புகளைச் செய்தது. பிற கணக்குகள், சோர்வடைந்திருந்த அந்த ஒரே பராமரிப்பாளரை உதவி பெறும்படி வற்புறுத்தின. அந்தப் புதிய இணை-பராமரிப்பாளர், SSH (secure shell) daemon-ஐ liblzma-வுடன் இணைக்கும் system-களைக் குறிவைத்து, release archives-ல் ஒரு backdoor-ஐப் புகுத்தினார். login செய்ய ஏன் வழக்கத்தை விட அரை வினாடி கூடுதல் நேரம் ஆகிறது என்று ஆய்வு செய்தபோது ஒரு developer இதைக் கண்டறிந்தார். இது ஒரு தற்செயலான நிகழ்வு என்பதை இதில் சம்பந்தப்பட்ட அனைவரும் பகிரங்கமாக ஒப்புக்கொண்டுள்ளனர்.

நிதியுதவி கிடைக்கத் தொடங்கியுள்ளது: 2019 முதல் GitHub Sponsors, Open Collective, 2022 முதல் ஜெர்மனியின் Sovereign Tech Fund மற்றும் OpenSSF-ன் Alpha-Omega திட்டம் ஆகியவை இதில் அடங்கும். இந்த நிதி சீரற்ற முறையில் கிடைக்கிறது, மேலும் ஏற்கனவே புகழ்பெற்ற திட்டங்களுக்கே இது முன்னுரிமை அளிக்கிறது. ஒழுங்குமுறை விதிகளும் வரத் தொடங்கியுள்ளன. ஐரோப்பிய ஒன்றியத்தின் Cyber Resilience Act 2024 டிசம்பரில் நடைமுறைக்கு வந்தது, அதன் பெரும்பாலான கடமைகள் 2027 டிசம்பர் முதல் அமலுக்கு வருகின்றன. ஆரம்பகால வரைவுகள் ஊதியம் பெறாத தன்னார்வலர்கள் மீது உற்பத்தியாளர் பொறுப்பைச் சுமத்தியிருக்கும், எனவே அறக்கட்டளைகள் மற்றும் distributions நீண்டகாலமாக மேற்கொண்ட வாதங்களுக்குப் பிறகு, இறுதி உரையில் "open source software steward" என்ற இலகுவான வகை உருவாக்கப்பட்டுள்ளது.

உங்கள் VPS-ல் உள்ள மென்பொருளுக்கு திறந்தநிலை மென்பொருள் (open source) வரலாறு எதைக் குறிக்கிறது

எங்கள் self-hosting வழிகாட்டிகளில் உள்ள ஒவ்வொரு application-ம் இந்த முடிவுகளின் தொடர்ச்சியாகவே அமைகின்றன. Nextcloud ஒரு fork-ன் காரணமாகவே உருவானது: 2016-ல் ownCloud-ன் நிறுவனர் மற்றும் குழுவின் பெரும்பகுதியினர் வெளியேறி, AGPLv3 உரிமத்தின் கீழ் திட்டத்தை மீண்டும் தொடங்கினர்; அன்றிலிருந்து இரண்டு தயாரிப்புகளும் இணையாக இயங்கி வருகின்றன. அந்த வரலாறுதான் கருத்தில் கொள்ள வேண்டிய Nextcloud மாற்றுகள் மற்றும் அவற்றுடன் போட்டியிடும் self-hosted Dropbox மாற்றுகள் ஆகியவற்றின் பின்னணியாகும்.

இதே பாணிதான் Git hosting-லும் தொடர்கிறது. Gitea, 2016-ல் Gogs-ன் fork-ஆகத் தொடங்கியது. 2022-ன் இறுதியில் திட்டத்தின் வர்த்தக முத்திரை மற்றும் domains ஒரு நிறுவனத்திற்குச் சென்றன; அந்த ஆண்டின் டிசம்பரில் Codeberg, Forgejo-வை fork செய்தது. 2024-ல் பதிப்பு 9-உடன் Forgejo, MIT உரிமத்திலிருந்து GPLv3-க்கு மாறியது. இவை இரண்டும் self-hosted Git server விருப்பங்கள் பகுதியில் விவரிக்கப்பட்டுள்ளன; உரிம வேறுபாடுகளே அவை தொடர்ந்து பிரிந்து செல்வதற்கான முக்கிய காரணமாகும். இதற்கிடையில், பெரும்பாலான free software-கள் Microsoft-க்குச் சொந்தமான மூடிய தளமான GitHub-ல் உருவாக்கப்படுகின்றன. இது இரு தரப்பிலும் வலுவான வாதங்களைக் கொண்ட ஒரு பழைய விவாதம்: GitHub உண்மையில் என்ன என்பதைப் பார்க்கவும்.

ஒரு திட்டத்திற்காக server-ஐ ஒதுக்கும் முன், பத்து நிமிடங்களில் நான்கு சோதனைகளைச் செய்வது நல்லது.

• marketing பக்கத்தைப் பார்க்காமல், repository-ல் உள்ள LICENSE கோப்பை வாசிக்கவும். கோப்பில் உள்ள விதிமுறைகள் மாறிய பிறகும், பக்கங்கள் நீண்ட காலம் "open source" என்று கூறிக்கொண்டே இருக்கலாம்.
• CLA அல்லது copyright assignment உள்ளதா என்று பார்க்கவும். அப்படி ஒன்று இருந்தால், ஒரே உரிமையாளர் எதிர்கால releases-ன் விதிமுறைகளை மாற்ற முடியும்.
• copyright யாரிடம் உள்ளது என்பதைக் கண்டறியவும்: ஒரு நிறுவனம், பல பங்களிப்பாளர்கள் அல்லது ஒரு அறக்கட்டளை.
• செயலில் உள்ள maintainers-களின் எண்ணிக்கையைக் கணக்கிடவும். ஒருவரால் மட்டுமே நிர்வகிக்கப்படும் திட்டம், உங்களுக்கு மட்டுமின்றி அந்த நபருக்கும் ஒரு ஆபத்தாகும்.

இதன் பொருள் single-vendor மென்பொருளைத் தவிர்க்க வேண்டும் என்பதல்ல. அவற்றில் பல மிகச்சிறந்தவை; பணம் பெறுவதாலேயே அவை பராமரிக்கப்படுகின்றன. இது நீங்கள் எத்தகைய அபாயங்களுக்கு உள்ளாகிறீர்கள் என்பதை உங்களுக்கு உணர்த்துகிறது. எதை self-host செய்வது என்று நீங்கள் முடிவு செய்யும்போது, memory தேவைக்கு இணையாக உரிமத்தையும் ஒப்பிட்டுப் பாருங்கள்.

இந்த வரலாற்றின் ஒரு பகுதியை உங்கள் முன்னால் உள்ள கணினியிலேயே நீங்கள் வாசிக்கலாம். Debian அல்லது Ubuntu system-ல் உள்ள ஒவ்வொரு package-ம் அதன் சொந்த விதிமுறைகளைக் கொண்டுள்ளது:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

முதல் எண் எத்தனை installed packages copyright கோப்பைக் கொண்டுள்ளன என்பதைக் குறிக்கிறது; ஒரு சிறிய VPS-ல் இது பொதுவாக சில நூறுகளாக இருக்கும். இரண்டாவது கட்டளை bash-க்கான கோப்பின் தொடக்கத்தை அச்சிடுகிறது, அது GNU General Public License version 3-ஐக் குறிப்பிடுகிறது. ஒரு கோப்பு விடுபட்டிருந்தால், அந்த package Debian கொள்கையின்படி உருவாக்கப்படவில்லை என்று பொருள்; இது அரிதானது, அதை நம்புவதற்கு முன் ஒருமுறைக்கு இருமுறை சரிபார்ப்பது நல்லது.

FAQ

Free software மற்றும் open source ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

இவை கிட்டத்தட்ட ஒரே மாதிரியான உரிமங்களை (licences) உள்ளடக்கியவை, ஆனால் அந்த உரிமங்கள் ஏன் முக்கியம் என்பதில் கருத்து வேறுபாடு கொண்டுள்ளன. "Free software" என்பது 1985-ல் Free Software Foundation உருவாக்கிய பழைய சொல்; இதன் வாதம் அறம் சார்ந்தது: ஒரு நிரலை மாற்ற முடியாத பயனர் தனது கணினியைக் கட்டுப்படுத்த முடியாது. "Open source" என்பது பிப்ரவரி 1998-ல் நிறுவனங்களுக்கு இந்த உரிமங்களை எளிதாக விளக்குவதற்காக உருவாக்கப்பட்டது; இதன் வாதம் நடைமுறை சார்ந்தது. GPL, MIT, BSD மற்றும் Apache 2.0 ஆகிய உரிமங்கள் இரண்டு அதிகாரப்பூர்வ பட்டியல்களிலும் உள்ளன. இரண்டையும் ஒரே நேரத்தில் குறிக்க விரும்புவோர் FOSS அல்லது FLOSS என்ற சொற்களைப் பயன்படுத்துகின்றனர்.

Source-available மென்பொருளும் open source மென்பொருளும் ஒன்றா?

இல்லை. Source-available என்பது நீங்கள் நிரலை (code) வாசிக்க முடியும் என்று மட்டுமே குறிக்கும். Open Source Definition-ன்படி, open source என்பது மென்பொருளை யார் பயன்படுத்தலாம் அல்லது எதற்காகப் பயன்படுத்தலாம் என்பதில் உரிமம் எந்தக் கட்டுப்பாட்டையும் விதிக்கக்கூடாது என்பதையும் குறிக்கும். SSPL மற்றும் Business Source License ஆகிய இரண்டுமே வணிக ரீதியான போட்டியைத் தடுப்பதால், அவை நிரலை வெளியிட்டாலும், அந்த வரையறையின்படி open source ஆகாது. நீங்கள் உங்களுக்காக மட்டுமே self-host செய்கிறீர்கள் என்றால், இந்தத் தடைகள் உங்களைப் பாதிக்காது. ஒரு தயாரிப்பை உருவாக்க விரும்பினால், முதலில் உரிமத்தின் உரையை கவனமாகப் படிக்கவும்.

ஒரு நிறுவனம் ஏற்கனவே வழங்கிய open source உரிமத்தைத் திரும்பப் பெற முடியுமா?

ஏற்கனவே வெளியிட்ட நிரலுக்கு இது பொருந்தாது. அந்தப் பதிப்பு எந்த உரிமத்துடன் வெளியிடப்பட்டதோ, அதே உரிமத்தின் கீழ்தான் இருக்கும். இதனால்தான் Valkey மற்றும் OpenTofu போன்ற forks, கடைசியாக அனுமதிக்கப்பட்ட உரிமம் கொண்ட commit-லிருந்து தொடங்க முடிந்தது. ஒரு நிறுவனம் செய்யக்கூடியது என்னவென்றால், எதிர்காலப் பதிப்புகளைப் புதிய நிபந்தனைகளின் கீழ் வெளியிடுவதுதான். திட்டத்தின் முழு பதிப்புரிமையையும் (copyright) ஒரு நிறுவனம் தனது கட்டுப்பாட்டில் வைத்திருந்தால் அல்லது contributor licence agreement மூலம் பெற்றிருந்தால் மட்டுமே இதைச் செய்ய முடியும். Linux போன்ற பல சுயாதீன பதிப்புரிமைதாரர்களைக் கொண்ட திட்டங்களை யாராலும் மறு உரிமம் (relicense) செய்ய முடியாது.

Self-hosted மென்பொருளில் எந்த உரிமத்தை நான் கவனிக்க வேண்டும்?

நீங்கள் சொந்தமாக இயக்கும் மற்றும் மறுவிற்பனை செய்யாத மென்பொருளுக்கு, GPL, AGPL, MIT அல்லது Apache 2.0 போன்ற OSI-அங்கீகரிக்கப்பட்ட எந்த உரிமமும் உங்களுக்குத் தேவையான அனைத்தையும் வழங்கும். பதிப்புரிமை யாரிடம் உள்ளது என்பதைச் சரிபார்ப்பது மிகவும் முக்கியம், ஏனெனில் பிற்காலத்தில் நிபந்தனைகள் மாறுமா என்பதை அதுவே தீர்மானிக்கிறது. ஒரு அறக்கட்டளையாலோ அல்லது பல சுயாதீன பங்களிப்பாளர்களாலோ நிர்வகிக்கப்படும் திட்டத்தை பயனர்களுக்கு எதிராக மறு உரிமம் செய்ய முடியாது. ஒரு contributor licence agreement கொண்ட single-vendor திட்டத்தை அவ்வாறு மாற்ற முடியும். இரண்டுமே நல்ல மென்பொருளாக இருக்கலாம். ஆனால், ஒரு நிறுவனம் மட்டுமே தன்னிச்சையாக விதிகளை மாற்ற முடியும்.