Softuer me burim të hapur. Llojet e licencave për të drejtën e përdorimit të softuerit me kod të hapur

shënim

Ky artikull fokusohet në përfitimet, konsideratat strategjike, barrierat dhe mundësitë që lidhen me përdorimin e softuerit me burim të hapur në produktet komerciale. Duke përdorur Mjedisin e Zhvillimit të Integruar (IDE) të bazuar në Eclipse si shembull, ne do të diskutojmë ndryshimet midis licencave të kodit burimor të softuerit mbrojtës dhe jombrojtës. Kur integroni ose lidhni kodin me burim të hapur me kodin burimor të mbyllur "pronarë", shpesh kërkohet kujdes dhe kujdes i duhur. Ekzistojnë gjithashtu çështje të ndryshme ligjore për të cilat duhen pasur parasysh, të tilla si potenciali për shkelje të patentave. Ne gjithashtu do të përpiqemi të shpjegojmë pse parimet bazë të softuerit me burim të hapur në mjedisin e teknologjisë së informacionit (IT) nuk zbatohen për produktet e integruara komerciale.

Mjedisi i zhvillimit QNX Momentics si shembull i përdorimit të softuerit me burim të hapur

Duke u kthyer në vitin 2001, kur shumë firma softuerësh po luftonin për të mbijetuar mes kolapsit të përgjithshëm të tregut të aksioneve të IT-së, veçanërisht ato që lidhen me e-biznesin në internet, QNX Software Systems mori një vendim strategjik për të filluar zhvillimin e një mjedisi të ri zhvillimi të integruar (IDE). për tregun.sisteme të ngulitura. Kompania tashmë kishte përvojë solide në zhvillimin e një sërë mjetesh të përdorura në zhvillimin e pajisjeve të integruara, por menaxhmenti i kompanisë kuptoi se krijimi i një IDE do ta ndihmonte atë të qëndronte përpara konkurrencës së ashpër. Vendimi për të krijuar një IDE u nxit gjithashtu nga ndryshimet në kërkesat e klientëve. Gjatë rënies së aktivitetit të biznesit, klientët me para në dorë u bënë më të interesuar për zgjidhje që mund të maksimizonin produktivitetin dhe t'i bënin ata më të lëvizshëm (fleksibël) gjatë kryerjes së punës, gjë që do të përmirësonte efikasitetin e përgjithshëm ekonomik.

Për QNX, zhvillimi i IDE ishte një "bast për të ardhmen", sepse kostoja dhe përpjekja e zhvillimit të projektit ishte përtej mundësive të shumicës së shitësve të mjeteve të sistemeve të integruara në atë kohë. Për fat të mirë, QNX punoi ngushtë me IBM në segmente të ndryshme të tregut të integruar. Nëpërmjet bashkëpunimit të ngushtë, IBM ndau me QNX planet e saj për të lëshuar një mjedis zhvillimi të integruar me burim të hapur që më vonë u bë baza për platformën Eclipse.

IBM propozoi përdorimin e ekspertizës së QNX për të përshtatur teknologjinë IDE me nevojat e zhvilluesve që krijojnë aplikacione të integruara bazuar në gjuhën C/C++. Ekspertët e QNX vunë në dukje pothuajse menjëherë përfitimet bindëse të përdorimit të një IDE me burim të hapur. Për shembull, për një mjedis të tillë do të ishte e mundur:

• eliminoni varësinë nga një shitës i vetëm, i cili zakonisht shoqërohet me nevojën për të licencuar një platformë dritareje;
• ofroni kodin e programit burimor për përshtatje sipas nevojave të klientit;
• të tërheqë lojtarë seriozë industrialë për të ofruar mbështetje dhe për të krijuar një ekosistem teknologjish dhe shtojcash plotësuese;
• t'u sigurojë klientëve një arkitekturë të qëndrueshme që mund të mbështesë diferencimin e produktit;
• u mundëson zhvilluesve të pajisjeve të integruara të përdorin stacionet standarde të punës si një platformë zhvillimi, të përshtatshme për të punuar me aplikacione të teknologjisë së informacionit (në një gamë të gjerë aplikacionesh).

Së fundi, ekzistonte mundësia e veçantë që platforma IDE të fitonte popullaritet dhe të bëhej një standard de fakto, duke lejuar QNX të kapte tregun për ekosistemet e mëdha të zhvilluesve dhe mjetet e palëve të treta përmes një platforme të tillë.

Themelimi i projektit me kod të hapur Eclipse.org

Në nëntor 2001, Borland, IBM, Merant, QNX Software Systems, Red Hat dhe SUSE themeluan Konsorciumin Eclipse. Në fillim të vitit 2004, Bordi i Drejtuesve riorganizoi Konsorciumin Eclipse në një korporatë jofitimprurëse të quajtur Fondacioni Eclipse.

Që në fillim, Eclipse ishte një projekt me të vërtetë me burim të hapur. Projekti ofroi teknologji falas me burim të hapur dhe akses në një komunitet të zhvilluesve më të arsimuar dhe më të avancuar në fushën e tyre. Kështu, kjo teknologji doli të ishte një platformë universale për integrimin e të gjitha llojeve të mjeteve të zhvillimit. Ai bazohet në një arkitekturë të hapur, të zgjerueshme dhe është qartësisht e licencuar si një produkt pa pagesë, pa honorare. Kontributet e komunitetit në projektin Eclipse bazohen në modelin standard të zhvillimit të Softuerit me burim të hapur (OSS), por shumica e anëtarëve kontribuojnë gjithashtu në zhvillime komerciale bazuar në platformën Eclipse.

Projekti i ruajtjes së mjeteve

Në dhjetor 2001, QNX filloi ndërtimin e QNX® Neutrino® RTOS, bazuar në platformën Eclipse IDE. Në vizionin e kompanisë, IDE duhej të kishte funksionalitet më të madh, të fokusohej në punën me gjuhët C/C++ dhe të kishte mjete të integruara thellësisht për korrigjimin, profilizimin, analizimin dhe krijimin e aplikacioneve të integruara. Që në fillim, ekipi QNX e parashikoi atë të ishte një IDE me shumë qëllime, shumë-gjuhëshe që mbështette platforma të shumta mjetesh. Kjo përfshinte:

• disa platforma mjetesh: Windows, Solaris, QNX Neutrino RTOS (zhvillim i vetë-pritur);
• disa arkitektura të synuara: ARM, MIPS, PowerPC, SH-4, x86;
• gjuhë programimi C, C++, Java.

Që atëherë, IDE ka vazhduar të rritet duke përfshirë mbështetjen për platformën Linux dhe mbështetjen për arkitekturat shtesë të procesorëve, duke përfshirë procesorët XScale.

Projekti u lançua në stilin e "programimit ekstrem". Një ekip prej 12 inxhinierësh më të mirë u zgjodh nga kompania. Atyre iu dha një dhomë e veçantë, u izoluan nga çdo shpërqendrim, projekti iu dha plotësisht.

Skuadrës iu dha autoriteti i nevojshëm vendimmarrës dhe iu dha një orar i ngushtë pune me rrezik të lartë për të nxjerrë versionin beta të produktit në 16 javë dhe versionin komercial deri më 4 korrik 2002. Grupi i përmbushi të gjitha afatet e synuara dhe lëshoi ​​një produkt të ri - të quajtur QNX Momentics® IDE - pikërisht sipas planit, duke demonstruar potencialin e softuerit me burim të hapur për të reduktuar kohën në treg.

Nga ideja tek shpërndarja e produktit - më pak se 7 muaj

Duke u bazuar në platformën Eclipse, ekipi QNX përfundoi një IDE shumë të fuqishme dhe gjithëpërfshirëse për zhvillimin e softuerit të integruar në gjashtë muaj. IDE mbështeti zhvillimin ndër-platformë për platforma të shumta mjetesh dhe gjuhë të shumta programimi, dhe gjithashtu mbështeti bordet më të njohura të procesorëve për pajisjet e synuara të integruara. Duke përdorur platformën Eclipse, QNX ishte në gjendje të:

• përdorni përpiluesit GNU dhe mjetet e linjës së komandës për zhvillim të ndërthurur;
• ofrojnë mbështetje për shtojcat e palëve të treta, të tilla si IBM WebSphere për aplikacionet e integruara Java dhe Rational ClearCase për zhvillimin e drejtuar nga modeli;
• krijoni mjete shtesë për ndërtimin e sistemeve, menaxhimin e pajisjeve të synuara, analizimin e kujtesës, profilizimin e sistemeve dhe aplikacioneve, etj.

Në Fig. Figura 1 jep një shembull se si përdorimi i platformës Eclipse redukton koston e krijimit të një IDE, e cila u lejon kompanive të përqendrojnë vëmendjen e tyre në nivelet e larta të zhvillimit, ku krijohen risitë reale. Për shembull, duke përdorur platformën Eclipse, QNX ka qenë në gjendje të krijojë lehtësisht disa mjete inovative vizualizimi që mund të hyjnë thellë në një sistem të integruar dhe të tregojnë sjelljen e tij.

Jepini komunitetit

Fuqia e një projekti të suksesshëm me kod të hapur qëndron në bashkëpunimin e komunitetit të zhvilluesve dhe përmirësimin e vazhdueshëm të bazës së kodit. Nëse një kompani miraton dhe përdor mirë kodin me burim të hapur, atëherë ajo thjesht ka një detyrim të kontribuojë në komunitet. Për këtë qëllim, QNX mori drejtimin e projektit Eclipse CDT në qershor 2002.

Qëllimi i projektit Eclipse CDT (C/C++ Development Tools) është të krijojë një grup të përbashkët mjetesh gjuhësore të ndërveprueshme C/C++ për platformën Eclipse. Eclipse CDT u pozicionua si një projekt me burim të hapur, me të drejta menaxhimi nga Eclipse Corporation. Për të nisur projektin CDT, QNX dhuroi burimet e zhvillimit dhe kodin burimor për projektin QNX Momentics IDE. Rational dhe Red Hat, si anëtarë të komunitetit, gjithashtu dhanë mbështetje të konsiderueshme për projektin.

Oriz. 1. Duke përdorur platformën Eclipse, shitësit e mjeteve mund të përqendrojnë vëmendjen e tyre në nivelin më të lartë të grupit të punës, ku krijohet inovacioni i vërtetë.

QNX vazhdon të mbajë projektin CDT, i cili është rritur nga një numër modest 80,000 rreshtash kodi në mbi 700,000 rreshta kodi. Në fillim të vitit 2006, regjistri i progresit për projektin Eclipse CDT vlerësoi se kontributi i QNX ishte 52%. Më pas erdhi IBM me një kontribut prej 36%. Projekti CDT është projekti i dytë më i popullarizuar i korporatës Eclipse pas vetë platformës Eclipse.

A mund të përballoni të "dhuroni" kodin?

Mund të duket se "dhurimi" i kodit tuaj do të thotë të veprosh në kundërshtim me sensin e përbashkët. Megjithatë, nëse funksionaliteti i produktit tuaj rezulton i dobishëm, atëherë pse të mos kontribuoni në komunitetin me burim të hapur. Duke ndërmarrë këtë hap, ju mund të përfitoni nga kjo ofertë e një zbatimi "standard" së bashku me përdorimin e ekspertizës së mbështetjes së produktit. Ju do të mund të përfitoni nga puna e të gjithë komunitetit që synon përmirësimin e bazës së kodeve. Kjo strategji mund të çlirojë burimet tuaja për të kryer kërkime shtesë të fokusuara në zhvillime inovative për të shtuar funksionalitet shtesë në produktet tuaja.

Për më tepër, ju mund të fitoni njëfarë kontrolli mbi drejtimin e platformës "standarde" - të fituar, natyrisht, përmes shërbimeve tuaja për komunitetin! Nëse po mbani një projekt, silluni si një qytetar i mirë i komunitetit, respektoni mendimet e të tjerëve dhe vlerësoni kontributin dhe këshillat e anëtarëve të tjerë. Mos mendoni se dikush do të përpiqet të "zgjedhë xhepat tuaj" si rezultat i përdorimit të kodit dhe të marrë drejtimin tuaj mbi drejtimin e zhvillimit të platformës.

Për shembull, strategjia e QNX Software Systems është të përfitojë nga pjesëmarrja e saj në Eclipse ndërsa zhvillon funksionalitet të ri përmes pikave të standardizuara të zgjerimit të disponueshme tashmë në platformat Eclipse dhe CDT. Për këtë qëllim, QNX synon të mbetet një anëtar aktiv i komunitetit Eclipse, duke përfituar nga baza ekzistuese e kodit dhe puna e palëve të treta (plug-ins) për të ndihmuar në përmbushjen e nevojave reale të klientëve duke krijuar zgjerimet e veta të pronarit. Strategjia e përshkruar është ilustruar në Fig. 2.

Oriz. 2. Ju mund të kontribuoni në punën e komunitetit me punën tuaj.

Përmbledhje e Përfitimeve

Platforma e veglave të bazuara në Eclipse është fitimprurëse si për zhvilluesit e aplikacioneve si QNX ashtu edhe për klientët që blejnë mjete platformash.

Përfitimi për zhvilluesit është reduktimi i kohës për të nxjerrë produktet e tyre në treg dhe aftësia për të përfituar nga kërkimet e njerëzve të tjerë (me kosto të ulët). Këto rezultate mund të përfshijnë kod me cilësi të lartë të klasifikuar si "IP e pastër" nga firma me reputacion si IBM dhe QNX. Një avantazh tjetër për zhvilluesin është se ai merr një skemë të thjeshtë dhe të qartë licencimi, duke përfshirë të drejtat tregtare dhe disa mbrojtje për patentën. Për më tepër, zhvilluesi merr mundësinë për të punuar në platforma të shumta OS të mbështetura në Eclipse, dhe gjithashtu ka në dispozicion pikat e zgjerimit të mirëpërcaktuara në projektin Eclipse.

Klientët që blejnë një IDE të bazuar në Eclipse përfitojnë nga një platformë veglash e krijuar për zhvillimin e aplikacioneve të integruara, me mbështetje të fortë të ndërthurjes, korrigjim të lehtë dhe shtesa për të menaxhuar sistemet e synuara. Ekipi i zhvillimit të klientit do të vlerësojë shumë veçori që e bëjnë punën më të lehtë, kohën e shkurtër të trajnimit të kërkuar, performancën e mirë të produktit dhe një platformë të fortë që mund të përballojë projekte të mëdha. Klientët mund të përfitojnë gjithashtu nga përdorimi i platformës Eclipse në aplikacionet e tyre (p.sh. RCP, eRCP, etj.).

E ardhmja e Korporatës Eclipse

Eclipse Corporation është një komunitet aktiv dhe i gjallë. Ai prezanton vazhdimisht projekte të reja, vë në dispozicion arkitektura të reja për kompanitë e themeluara, inovative dhe madje edhe kompanitë e vogla mund të përfitojnë komercialisht nga platforma Eclipse duke krijuar me kosto efektive shtojcat e reja që zgjerojnë funksionalitetin ekzistues (shih Figurën 3).

Oriz. 3. Eclipse Corporation është një komunitet i gjallë dhe me rritje të shpejtë të zhvilluesve të shtojcave.

Krahasimi i licencave me kod të hapur

Jo të gjitha licencat e softuerit me burim të hapur janë të barabarta. QNX bëri një lëvizje të zgjuar duke përdorur licencën publike Eclipse. Kjo zgjedhje u nxit pjesërisht nga nevojat e klientëve të saj të integruar dhe pjesërisht nga dëshira për të kontrolluar (dhe për të përfituar) teknologjinë që i dallon produktet e saj.

Iniciativa jofitimprurëse me burim të hapur () ka propozuar një përkufizim të dobishëm me 10 pika të burimit të hapur. Aktualisht ka mbi 50 licenca të miratuara nga OSI në dispozicion në faqen e internetit, duke përfshirë Licencën Publike Eclipse. Këto licenca mund të përmbajnë dallime të rëndësishme për të cilat duhet të keni parasysh. Këto dallime mund të kenë një ndikim të rëndësishëm në pronësinë intelektuale (IP) të zhvilluesve dhe aftësinë e tyre për ta mbrojtur atë. Kjo është më e rëndësishme kur përdorni kodin me burim të hapur (ose derivate me burim të hapur) në pajisjet e integruara.

Leje mbrojtëse dhe jo-mbrojtëse

Sipas kushteve të një licence mbrojtëse, si GPL v2, një vepër derivative mund të shpërndahet vetëm së bashku me kodin burimor përkatës. Licenca e sigurisë garanton që kur kodi burim të bëhet me burim të hapur, ai do të mbetet me burim të hapur në të gjitha gjeneratat pasuese dhe veprat e derivuara. Siç do ta shpjegojmë më vonë, kjo kërkesë çon në probleme të caktuara në rastin e sistemeve të integruara.

Shembuj të licencave jo-mbrojtëse janë licencat origjinale MIT dhe BSD. Licencat jo-mbrojtëse ruajnë të drejtën e autorit të pronarit, por sigurojnë të drejta të gjera për përdoruesit, duke përfshirë të drejtën për të modifikuar dhe shpërndarje të pakufizuar falas (ose përdorim personal) të softuerit.

Çfarë nënkuptohet me "licencë virusi"

Disa njerëz e quajnë GPL një "licencë virusi". Ky emër lindi për shkak të pasigurisë së përkufizimit ligjor të konceptit të "zhvillimit të derivatit". Një interpretim i rreptë i përkufizimit do të thotë që nëse edhe një pjesë e vogël e kodit të licencuar nga GPL është e përfshirë në një aplikacion të pronarit, atëherë i gjithë aplikacioni duhet të licencohet si GPL. Analogjia me një virus vjen menjëherë në mendje.

Pyetje në lidhje me marrjen e kompensimit

Kohët e fundit, Dëmshpërblimi IP (Dëmshpërblimi IP) është bërë një temë kryesore e diskutimit për zhvilluesit. Si përgjigje, disa shitës me kod të hapur kanë njoftuar se do të mbrojnë klientët nga paditë që lidhen me shkeljen e patentave ose të drejtave të autorit. Dhe licencat më të reja me burim të hapur parashikojnë gjoba për përdoruesit që përpiqen të pretendojnë të drejtat e tyre të patentës kundër përdoruesve të tjerë të bazës së kodeve.

Problemet kryesore që hasen gjatë komercializimit të softuerit me burim të hapur

Krahasimi i aplikacioneve të integruara dhe IT

Suksesi i industrisë me burim të hapur është nxitur nga miratimi i Linux nga organizatat e IT. Përfitimet e përdorimit të Linux-it erdhën nga funksionimi në pajisje relativisht homogjene dhe të qëndrueshme (zakonisht familja x86) dhe përdorimi i një platforme kompjuterike fleksibël, të pasur me burime.

Me softuerin e integruar, gjërat janë krejtësisht të ndryshme. Ky softuer funksionon në një numër të madh pajisjesh me një grup funksionesh fikse, duke përdorur një gamë të gjerë pajisjesh me arkitektura të ndryshme. Zhvilluesit e pajisjeve të integruara shpesh e bazojnë avantazhin e tyre konkurrues në një grup karakteristikash specifike, madhësi, performancë, kosto, jetëgjatësi të baterisë, besueshmëri, ndërveprim dhe zgjerueshmëri. Këto veçori dalluese zakonisht zbatohen në softuer të nivelit të ulët, i cili në rastin e Linux kërkon lidhjen direkt me kernelin OS. Përshtatja e softuerit të nivelit të ulët për t'iu përshtatur nevojave të klientit është normë, jo përjashtim, kështu që zhvilluesit shpesh arrijnë funksionalitetin që u nevojitet duke ndryshuar kernelin OS. Metoda e lidhjes direkte duke futur në fragmente kodi përdoret gjithashtu për të ulur koston e krijimit të bibliotekave. Këto praktika, të marra së bashku, e bëjnë shumë të vështirë mbrojtjen e kodit të pronarit sipas licencave të tilla si GPL.

Në mënyrë tipike, këto çështje të licencimit nuk prekin aplikacionet e TI-së, pasi softueri i pronarit, specifik për ndërmarrjet nuk shtrihet përtej ndërmarrjes, duke u përdorur vetëm për nevoja të brendshme. Në rastin e pajisjeve të integruara, softueri derivativ shpërndahet gjithmonë nëpërmjet tyre, duke iu nënshtruar klauzolës “force open” të licencave me burim të hapur, gjë që mund të rrezikojë aspektet kryesore të ofertave të vlefshme me burim të hapur.

Përveç kësaj, produktet e ngulitura shpesh kanë jetëgjatësi të gjatë, si gjatë prodhimit ashtu edhe në përdorim. Një produkt i integruar që është subjekt i kushteve me burim të hapur është subjekt i rreziqeve më të mëdha, duke përfshirë mungesën e mbështetjes teknike afatgjatë, çështjet e mundshme të sigurisë dhe shkeljet e IP.

Çështjet e licencimit

Statusi juridik i pasigurt

Pavarësisht fjalëve qetësuese të mbështetësve të disa licencave me burim të hapur, shumë nga çështjet kryesore për të cilat zhvilluesit e sistemeve të integruara shprehin shqetësimin nuk janë testuar ende gjerësisht në jurisprudencë. Siç u përmend, përkufizimi i "punës derivative" është kyç për zbatimin e klauzolave ​​të caktuara të licencës, megjithatë shumë individë dhe organizata që pranojnë terma me burim të hapur kanë pak kuptim të konceptit ose e injorojnë atë me dashje.

Disa zgjidhje që lejojnë shitësit e produkteve komerciale të prezantojnë drejtuesit "pronarë" në Linux (siç janë modulet e kernelit të ngarkueshëm) mbështeten më shumë në argumentet "tha ai, tha ajo" sesa në referencë të drejtpërdrejtë në tekstin e marrëveshjes së licencës. Në fakt, drejtues të tillë që përdorin module LKM janë të mbushur me anashkalim të rrezikshëm të kërkesave të licencës GPL. Për ta çuar atë në ekstrem, mund ta interpretojmë çështjen si duke thënë se baza e kodeve Linux mund të paraqitet si e padobishme për shumicën e aplikacioneve praktike, nëse nuk përfshin disa nga këta drejtues të pronarit. Kjo situatë mund të zhvlerësojë në mënyrë mjaft efektive idenë e licencës GPL.

Asnjë kompensim për shkeljen e IP

Në shumicën e rasteve të përdorimit me burim të hapur, ekziston një mundësi reale që ju të shkelni pa dashje të drejtat e patentës së dikujt tjetër. Pak licenca me burim të hapur bëjnë referencë të qartë për patentat dhe licencat e nënkuptuara nuk mund të gjykohen. Ju duhet të licenconi veçmas çdo patentë që mbulon, për shembull, kodekët me burim të hapur që zbatojnë algoritme MP3 ose zgjidhje të tjera të pronarit. Ndërkohë, “djemtë e këqij” (përfshirë Microsoft-in) janë të preokupuar me krijimin e një portofoli patentash që, sipas shumë ekspertëve, mund të përdoren për të “qëlluar” ndaj mbështetësve me burim të hapur.

Disa licenca përmbajnë referenca të qarta për patentat. Për shembull, Licenca Publike Eclipse përmend në mënyrë eksplicite të drejtat e patentës dhe përmban një klauzolë për gjobat nëse dikush përpiqet të pretendojë të drejtat e patentës në një mënyrë tjetër. Eclipse gjithashtu bën shumë përpjekje në rishikimin e kodit dhe përcaktimin e burimit të tij nga një perspektivë licencimi, patentimi ose e drejta e autorit.

Përpjekje shtesë për të ruajtur IP

Për të përdorur kodin me burim të hapur, një kompani duhet të shpenzojë përpjekje të konsiderueshme në fushat e mëposhtme:

• menaxhimi i shpërndarjes së produktit;
• menaxhimi i licencës;
• zgjidhjen e konflikteve ligjore lidhur me detyrimet e klientit;
• Kujdesi i duhur ndaj çështjeve ligjore: ruajtja e pastërtisë së të drejtave IP, kontrollimi i të drejtave IP për kodin me burim të hapur, identifikimi i burimit të origjinës së kodit, gjurmimi i ndryshimeve në versionet e licencës, si GPL v3, etj.

Pranimi i kërkesave të klientëve

Disa klientë të mëdhenj, të përballur me kompleksitetin dhe pasigurinë e softuerit me burim të hapur, kanë refuzuar të merren me produkte që përfshijnë kodin me burim të hapur. Nëse dëshironi të punoni me klientë të tillë, duhet t'i merrni ose t'i ftoni ata të përfshijnë kushtet e licencës komerciale për kodin tuaj.

Çështje IP

A mbulojnë kushtet e licencës suaj me burim të hapur pronësinë intelektuale që e bën produktin tuaj të ndryshëm? Nëse po, IP-ja juaj është në rrezik.

Nëse sistemet tuaja të integruara përdorin një përzierje të softuerit tuaj dhe softuerit me burim të hapur, ju duhet të kuptoni natyrën, origjinën dhe marrëdhëniet e të gjithë komponentëve të softuerit të integruar. Pa këtë kuptim të thellë të temës, ju mund të shkelni pa dashje IP-në e dikujt tjetër ose madje të humbni të drejtat për softuerin tuaj.

Pa licencimin dhe kompensimin e patentave, softueri jetëgjatë i sistemeve të integruara, çmimi relativisht i lartë i shitjes dhe vëllimi i shitjeve të pajisjeve të integruara me veçori fikse i bëjnë ata një objektiv të qartë për pretendimet për shkelje të patentave nga djemtë e këqij të lartpërmendur dhe konkurrentët kryesorë.

Siç tregon QNX Momentics IDE, ka shumë përfitime të menjëhershme për softuerin me burim të hapur, duke përfshirë kohën e reduktuar në treg, kostot më të ulëta të zhvillimit dhe lirinë më të madhe për të shtuar funksionalitet dhe inovacion shtesë në produktin tuaj. Nëse e ofroni softuerin tuaj si një shërbim që zgjidh disa probleme të klientit, atëherë klientit nuk i intereson nëse keni përdorur softuer me kod të hapur apo jo, ai thjesht paguan për funksionin që i nevojitet.

Sidoqoftë, duhet të kuptoni ndryshimet midis licencave të ndryshme me burim të hapur dhe të zgjidhni atë që i përshtatet aplikacionit tuaj dhe nevojave të klientit. Për më tepër, jini të përgatitur për të përmbushur detyrimet e licencimit të softuerit që zgjidhni. Duhet të jeni të vetëdijshëm për kërkesat e tjera të IP-së (të tilla si të drejtat e patentës) që lidhen me kodin e softuerit. Kini kujdes nga një bazë kodi që nuk shfaq një mesazh në lidhje me pasojat e shkeljes së IP. Kërkoni projekte që ofrojnë kompensim për dëmet e mundshme dhe ku shfaqet një mesazh në ekran për donacionet monetare për zhvillimin e kodit për të kompensuar kostot që lidhen me shkeljen e të drejtave të autorit ose patentave, etj. Sigurohuni gjithashtu që softueri me burim të hapur që përdorni të jetë në përputhje me politikat tuaja të pronësisë intelektuale dhe shmangni licencat mbrojtëse që mund t'ju detyrojnë të zbuloni pjesë të veçanta të kodit tuaj. Nëse produkti juaj është i përfshirë në sistem, atëherë konsideroni gjithashtu ofrimin e kushteve të licencimit komercial për IP-në tuaj.

Përdorimi i kodit me burim të hapur në pajisjet e integruara çon në probleme më komplekse sesa në rastin e përdorimit të një softueri të tillë në aplikacionet e TI-së, pasi opsioni i parë është më i rrezikshëm. Përpara se të vendosni të përdorni ndonjë softuer me burim të hapur, merrni parasysh koston e tij të vërtetë të pronësisë (TTCO) dhe përshtatshmërinë e tij për projektin tuaj.

Së fundi, bashkohuni me komunitetin me burim të hapur të përdoruesve dhe zhvilluesve për të përfituar sa më shumë prej tij!

Softueri me burim të hapur ka admiruesit e tij, dhe së fundmi, kur bëhet fjalë për zhvillimin e disa produkteve "kombëtare", ata kryesisht nënkuptojnë burim të hapur. Në mënyrë paradoksale, interesimi për këtë lloj softueri ka shkaktuar shumë shtrembërime dhe keqkuptime, të cilat në praktikë pengojnë përhapjen e tij.

Kompania jonë është përfshirë në projekte me kod të hapur që nga viti 2005 - si përmes zhvillimit të zgjidhjeve tona me burim të hapur (projektet OpenVZ, CRIU), duke marrë pjesë në projekte të tjera të hapura (QEMU, OpenStack, libvirt, libcontainer, etj.). Gjatë 10 viteve, ne kemi mbledhur disa nga mitet më të zakonshme rreth softuerit me burim të hapur. Unë do t'ju tregoj për secilin nga konceptet e gabuara dhe do t'ju shpjegoj pse ato janë të gabuara. Me siguri, do të mbani mend të njëjtin numër, por, për mendimin tim, këto pesë janë më "djallëzoret".

Një projekt me burim të hapur është një projekt me burim të hapur.

Çdo projekt softuerësh përbëhet nga shumë objekte: kodi burimor i projektit, informacione për defektet e pakorrigjuara, kodi burimor i testimit, dokumentacioni. Kodi burimor i një projekti është vetëm një pjesë e tij, aksesi falas në të cilin nuk jep të drejtën për ta quajtur të hapur të gjithë projektin. Përveç kodit burimor, objektet e tjera të zhvillimit duhet të jenë lirisht të aksesueshme, dhe sa më shumë artefakte të jenë të hapura, aq më i hapur është projekti për kontribuuesit (njerëzit që duan të kontribuojnë në projekt). Gjithashtu, janë të nevojshme procese transparente ndërmjet të gjithë anëtarëve të komunitetit, komunikime të hapura në projekt, etj. Të gjitha këto masa do të kontribuojnë vetëm në zhvillimin e projektit dhe bashkëpunimin e frytshëm ndërmjet anëtarëve të komunitetit.

Cilësia e softuerit me burim të hapur është më e keqe sepse çdokush mund të shkruajë kod për të

Parimi kryesor i softuerit me burim të hapur - zhvillimi i hapur bashkëpunues - në vetvete është një garanci që kodi, paterica dhe arna me cilësi të ulët thjesht nuk mund të fshihen nga pjesëmarrësit e tjerë. Një person që merr pjesë në këtë lloj projekti është i gatshëm që puna e tij t'i nënshtrohet si analizave ashtu edhe kritikave dhe, për rrjedhojë, ai nuk do t'i presë qoshet. Reputacioni i tij është në rrezik dhe askush nuk dëshiron ta humbasë atë.

Për më tepër, në disa komunitete (për shembull, komuniteti rreth zhvillimit të kernelit Linux) ekziston një parim i rreptë - vetëm kodi më i mirë, i testuar dhe ideal pranohet në kernelin burimor. Një përpjekje për të shtuar ndryshime me cilësi të ulët do të refuzohet; një përpjekje e dytë është e mbushur me humbje të reputacionit për personin ose kompaninë-kontribues.

Domethënë, një projekt i hapur realisht i jep mundësinë kujtdo që të marrë pjesë në shkrimin e kodit, por në projektet serioze, për shkak të pragut të lartë të hyrjes, kodi nuk do të pranohet nga persona me nivel të pamjaftueshëm ekspertize.
Shumica e kompanive të mëdha të IT (IBM, Google, Canonical, Parallels, etj.) kanë departamente të tëra në të cilat paguhen specialistë për të punuar në projekte me kod të hapur dhe në këtë mënyrë indirekt punojnë në produktet e kompanisë.

Vlen gjithashtu të përmendet se kompanitë që zhvillojnë produkte të bazuara në projekte me kod të hapur janë të interesuara për të përmirësuar kodin e projekteve me kod të hapur që përdorin gjatë testimit. Prandaj, të gjitha problemet e zbuluara duhet të korrigjohen dhe të siguroheni që ky rregullim të shtohet në degën kryesore të projektit në mënyrë që të ketë sa më pak ndryshime në kodin tuaj dhe kodin e projektit të hapur. Produktet tona përdorin kode nga projekte të tjera me burim të hapur, kështu që ne rregullojmë problemet e gjetura në kodin e këtyre projekteve dhe i dërgojmë ato në rrjedhën e sipërme. Ky ishte rasti me dobësitë në kernelin RHEL: Red Hat vuri në dukje Vladimir Davydov për zbulimin e dobësive serioze CVE-2014-0203 dhe CVE-2014-4483 në një nga përditësimet e kernelit RHEL6 (problemi i dytë, meqë ra fjala, u gjet duke përdorur një nga testet tona të automatizuara, duke përdorur Linux Test Project). Vasily Averin mori falënderime për zbulimin e gabimit CVE-2014-5045, Dmitry Monakhov - për CVE-2012-4508. Fakti i testimit të mirë të kernelit Linux u vu re madje nga Andrew Morton (kush është ky?): "Unë jam i interesuar. Gjatë muajve të fundit, njerëzit nga @openvz.org kanë gjetur (dhe rregulluar) një mori defektesh të pakuptueshme, por serioze dhe mjaft të lashta. Si i zbuluat këto defekte?”

Fundi

Në fakt, të gjitha mitet e listuara më sipër lindin kryesisht nga përdoruesit që ose sapo kanë filluar të punojnë me softuerin OpenSource ose nuk e kanë provuar fare. Mënyra më e mirë për të hequr qafe paragjykimet është të filloni të punoni ngushtë me vendime të tilla.
Kohët e fundit kemi shpallur procesin e hapur të zhvillimit për një version të ri të produktit tonë Virtuozzo 7. Nëse jeni gjithashtu të interesuar në krijimin e teknologjisë më të mirë të virtualizimit të kontejnerëve, atëherë

I gjithë softueri në LiveCD dhe DVD është softuer pa pagesë dhe me burim të hapur (pa pagesë dhe me burim të hapur), me disa përjashtime (Flash, Opera, Acrobat Reader dhe të tjerë) të vendosura në depo jo-oss. Kur flasim për software i lirë, Do të thotë liria, jo çmimi.

Çfarë është softueri i lirë

Lëvizja e softuerit të lirë u nis nga Richard M. Stallman, i cili themeloi Projektin GNU (akronim rekurziv: GNU's Not Unix) në 1984. Një vit më vonë, ai themeloi Fondacionin e Software-it të Lirë, i njohur gjithashtu si FSF.

Softueri i lirë mund të ndahet në 4 "shkallë lirie" kryesore:

• Liria përdorni programe në çfarëdo mënyre. (liri 0)
• Liria duke studiuar parimet e punës programi, si dhe përshtatja e tij me nevojat tuaja (liria 1) Kjo kërkon qasje në kodin burimor.
• Liria shpërndarja e kopjeve programet. Mund ta ndani me një fqinj. (liria 2)
• Liria përmirësojnë programin dhe publikoni përmirësimet që bëni për të mirën e të gjithë komunitetit (liria 3). Kjo kërkon qasje në kodin burimor.

Softueri jo i lirë quhet softuer pronësor. Është e rëndësishme të mos ngatërroni shareware dhe freeware me softuerin falas, ato janë gjëra të ndryshme.

Çfarë është softueri me burim të hapur

Lëvizja e softuerit të lirë dhe me kod të hapur filloi në fillim të viteve 1990 me njerëzit që theksonin përfitimet teknike dhe ekonomike të kodit të hapur dhe modelit të zhvillimit me kod të hapur të softuerit të lirë. Sidoqoftë, ekziston një sasi e vogël kodi softuerësh që njihet si i lirë nga shoqëria me burim të hapur, kështu që shpesh përdoret termi FOSS (software me burim të lirë dhe të hapur). Sepse, në mënyrë rigoroze, konceptet e “softuerit të lirë” dhe “softuerit me burim të hapur” nuk janë aspak identike, siç mund të mendohet. Për shembull, marrëveshja e licencës së një produkti softuer mund t'ju lejojë të ekzaminoni kodin e tij burimor, por t'ju ndalojë të bëni ndryshime në të dhe/ose të shpërndani kopje të tij. Në këtë rast, produkti është me burim të hapur, por jo falas.

Përfitimet e përdorimit të softuerit të lirë

Softueri i lirë është i dobishëm për një sërë arsyesh, më kryesoret janë renditur më poshtë.

Korrigjimi i gabimit

Nëse një produkt softuerësh është falas, kjo ju jep të drejtën të korrigjoni gabimet e gjetura në të, si dhe ta modifikoni atë për t'iu përshtatur nevojave tuaja. Nëse programi është i pronarit, atëherë nuk mund të korrigjoni në mënyrë të pavarur gabimet e gjetura në të ose të zgjeroni funksionalitetin. Në këtë rast, do të detyroheni të kontaktoni pronarin e produktit softuer me një kërkesë për të bërë korrigjimet e nevojshme dhe për të shtuar veçoritë që ju nevojiten. Megjithatë, nuk ka asnjë garanci që pronari do ta bëjë këtë.

Ndarja

Software-i i lirë ju jep të drejtën të shpërndani kopje të tij, duke ndihmuar kështu miqtë tuaj të përdorin softuerin e lirë pa marrë licenca.

Njihni dhe kontrolloni se çfarë bën programi dhe si e bën atë

Në shumicën dërrmuese të rasteve, nuk keni asnjë mënyrë për të ditur se çfarë bën saktësisht një program pronësor. Kështu, nuk mund të jeni të sigurt se programi bën vetëm atë që ju kërkoni, sepse ai mund të bëjë disa veprime pa dijeninë tuaj (për shembull, të dërgojë informacion për ju si përdorues te krijuesit e tij, ose të ketë aftësi të padokumentuara për karaktere të ndryshme). Sigurisht, nëse përdorni një program falas, jeni plotësisht të siguruar nga telashe të tilla. Në fund të fundit, ju keni në dispozicion kodin burimor të programit, i cili ju lejon të dini saktësisht se çfarë bën programi dhe si e bën atë. Nëse nuk jeni të kënaqur me disa nga aftësitë dhe/ose veçoritë e funksionimit të tij, mund të bëni ndryshimet që ju nevojiten në kod.

Përfitimet teknike

Kodi i hapur i një produkti të softuerit të lirë është i disponueshëm për një numër të madh njerëzish, gjë që u jep atyre mundësinë të korrigjojnë gabimet e gjetura në të; kjo kontribuon në zhvillimin dhe përmirësimin e produktit. Ky sistem i "vlerësimit të ekspertëve" mund të krahasohet me metodën shkencore të kërkimit. Në të kundërt, kodi pronësor i një produkti të pronarit mbahet sekret dhe pothuajse nuk shihet kurrë nga askush jashtë kompanisë së zhvillimit.

Përfitimet ekonomike

Softueri i lirë u jep kompanive mundësinë të ndajnë koston e softuerit që zhvillojnë. Për shembull, Novell dhe RedHat konkurrojnë në zhvillimin e të njëjtave programe, por në këtë mënyrë ndihmojnë njëri-tjetrin. IBM dhe HP janë gjithashtu konkurrentë, por ata gjithashtu dhanë kontribut të rëndësishëm në zhvillimin e kernelit Linux, duke ndarë kështu kostot e zhvillimit. Softueri i lirë lejon një treg konkurrues për mbështetje teknike, dhe për këtë arsye cilësia është zakonisht shumë e lartë. Me softuerin e pronarit, situata është saktësisht e kundërta: vetëm kompania e zhvillimit ka akses në kodin burimor dhe është në gjendje të ofrojë mbështetjen e duhur teknike, dhe kjo përfaqëson një shkallë monopoli. Për më tepër, përfitimet ekonomike përfshijnë koston e blerjes së një produkti softuer. Nëse është falas, mund ta shkarkoni një kopje të tij një herë nga Interneti (ose ta blini në hard disk), ta instaloni në çdo numër kompjuterësh dhe ta përdorni për një kohë të pakufizuar. Nëse produkti është pronësor, atëherë kushtet e marrëveshjes së licencës mund të kufizojnë shumë përdorimin e produktit (për shembull, duke kufizuar numrin e instalimeve dhe/ose kohën e përdorimit).

Unë nuk jam programues. Pse duhet të kujdesem për sa më sipër?

Në të vërtetë, shumica e lirive dhe mundësive të listuara më sipër mund të përdoren vetëm nga programuesit që mund të lexojnë dhe shkruajnë kodin e programit. Sidoqoftë, nuk duhet të mendoni se produktet e softuerit të lirë janë të destinuara ekskluzivisht për programuesit. Nëse ju, duke mos qenë i tillë, dëshironi të ndryshoni programin falas që po përdorni në një mënyrë ose në një tjetër për të zgjeruar funksionalitetin e tij, ju mund (ose vetëm ose duke u bashkuar me përdorues të tjerë) të punësoni një programues që mund ta bëjë këtë për ju. Kjo praktikë është shumë e zakonshme. Përveç kësaj, nuk duhet të jeni vetë programues për të shpërndarë softuer falas.

Shumë njerëz blejnë softuer të ndryshëm ose përdorin versione të hakuara, pirate të tyre. Përdoruesit shohin ndërfaqen grafike të programit, por kodi i produktit zakonisht fshihet. Në këtë drejtim, është pothuajse e pamundur të ndryshohet softueri, i cili garanton mbrojtjen e autorit nga ata që duan të kopjojnë kodin e programit dhe ta përvetësojnë atë për veten e tyre. Por, pavarësisht kësaj, në botën moderne ka gjithnjë e më shumë programe të ashtuquajtura "Open Source". Le të kuptojmë se çfarë janë programet me kod të hapur dhe cilat janë aspektet pozitive dhe negative të tyre.

Çfarë mund të konsiderohet me burim të hapur?

Pothuajse i gjithë softueri arrin te përdoruesi përfundimtar si softuer i gatshëm. Këto janë programe plotësisht funksionale me një ndërfaqe të këndshme dhe të lehtë për t'u përdorur. Nëse kodi i këtij produkti është i hapur, atëherë kushdo mund ta ndryshojë atë, të ofrojë opsionet e veta për korrigjimin e gabimeve të gjetura ose të prezantojë një lloj risi. Kështu, cilësia e këtij produkti përmirësohet me kalimin e kohës. Shembuj të sistemeve operative me burim të hapur janë Linux, Unix, Ubuntu.

Të gjithë janë të njohur me Microsoft Office, një analog i të cilit, por me burim të hapur, është Zyrë e hapur. Shfletuesit Mozilla Firefox dhe Google Chrome janë gjithashtu softuer me burim të hapur. Ka shumë produkte të ngjashme, shumë përdorin një sasi të madhe softuerësh dhe nuk dyshojnë se disa prej tyre mund të jenë një program me burim të hapur.

Karakteristikat e burimit të hapur

Që softueri të quhet program, nuk mjafton që kodi i tij të jetë i hapur për të gjithë. Një program i tillë duhet të jetë absolutisht falas. Për më tepër, për përdorim të mëtejshëm dhe përpjekje për të ndryshuar kodin, përdoruesi gjithashtu nuk duhet të paguajë asgjë. Çdokush ka të drejtë ta shpërndajë lirisht këtë produkt dhe, siç u tha më sipër, ta ndryshojë atë. Programe të tilla nuk kanë kufizime në fushën dhe kohëzgjatjen e përdorimit. Ato mund të përdoren për të bërë biznes, kërkime shkencore, trajnime ose për qëllimet tuaja për një kohë të pakufizuar.

Licenca e softuerit me burim të hapur

Licenca për programe të tilla është gjithashtu falas. Nuk ka absolutisht asnjë kufizim në aplikimin, modifikimin, shpërndarjen, përdorimin me programe të tjera të pajtueshme. Gjithashtu, është teknologjikisht neutral ndaj të gjitha programeve të tjera ekzistuese.

Të mirat dhe të këqijat e programeve me burim të hapur

Ndryshe nga programet klasike të licencuara, ato zhvillohen nga një grup programuesish falas dhe për këtë arsye janë falas.

Avantazhi i dytë i rëndësishëm është se ne mundemi përditësoni të dhënat e programit. Një programues i mirë, duke kuptuar kodin, mund të shtojë opsione të reja në program ose të përmirësojë funksionimin e funksioneve ekzistuese. Për shembull, përdoruesi MacOS nuk mund të ndryshojë sistemin e tij operativ, ndryshe nga Linux, të cilin të gjithë jo vetëm që mund ta personalizojnë sipas gjykimit të tyre, por edhe të shtojnë ndonjë funksion individual. Si rezultat, ai do të marrë një produkt krejtësisht të ri që është shumë i përshtatshëm për t'u përdorur. Nëse programi që rezulton është vërtet i mirë, atëherë ai mund të patentohet dhe madje të shitet (!)

Një avantazh tjetër i pamohueshëm i programeve është mbrojtja e tyre nga viruset. Pothuajse të gjithë viruset janë shkruar për aplikacione Dritaret, dhe malware për të njëjtën gjë Linux një sasi të papërfillshme. Kështu, mundësia për të marrë një virus duke përdorur një sistem operativ me burim të hapur është shumë i ulët.

Sot, shumë organizata po kalojnë në softuer me burim të hapur. Kjo ju lejon të reduktoni kostot dhe të minimizoni gjasat e hakimit të sistemit.

Por, siç e dini, çdo medalje ka dy anë, ne do t'ju themi në lidhje me disavantazhet e Open Source programet.

Nëse hasni ndonjë problem me softuerin, zakonisht kontaktoni mbështetjen teknike. Programet me kod të hapur nuk e kanë këtë. Ky problem ndodh sepse programi është modifikuar nga programues të ndryshëm nga i gjithë vendi apo edhe bota. Kështu që do t'ju duhet të kërkoni një zgjidhje për problemin në internet. Internet ose kuptoni vetë.

Disavantazhi i dytë lind përsëri për faktin se kushdo mund të ndryshojë kodin e programit. Shpesh, pikëpamjet e njerëzve mund të mos përkojnë dhe kjo shkakton konflikte në modifikimin e produktit. Kjo mund të çojë në kolapsin e një projekti për të cilin shumë njerëz kanë punuar për një kohë të gjatë.

Gjithashtu, programet me qëllim të keq shpesh maskohen si kod me burim të hapur dhe ndonjëherë mund të jetë shumë e vështirë t'i dallosh ato nga programet vërtet të sigurta.

Përkundër faktit se programe të tilla kanë disa disavantazhe, gjithnjë e më shumë përdorues janë të interesuar për to. Gjithnjë e më shumë produkte sot krijohen me kod me burim të hapur. Kjo do të thotë se programe të tilla kanë një të ardhme dhe ia vlen t'u kushtohet vëmendje.