現(xiàn)在很多用戶都在做數(shù)據(jù)庫國產(chǎn)化改造工作，因?yàn)橛写罅康南到y(tǒng)要遷移，因此保持國產(chǎn)數(shù)據(jù)庫與Oracle的兼容性就十分重要。前幾天有個做國產(chǎn)數(shù)據(jù)庫改造的客戶和我討論應(yīng)用遷移的問題，他覺得如果原有的Oracle上開發(fā)的應(yīng)用什么都不要變，連SQL*NET都兼容就最好了。他發(fā)現(xiàn)現(xiàn)在大多數(shù)客戶端兼容的數(shù)據(jù)庫都是MySQL和PostgreSQL，很少見到與Oracle客戶端兼容的數(shù)據(jù)庫。不過最近他發(fā)現(xiàn)了有幾款國產(chǎn)數(shù)據(jù)庫是與Oracle客戶端完全兼容的，因此他考慮建議領(lǐng)導(dǎo)把這個作為數(shù)據(jù)庫選型的條件，問我是否合適。

我建議他慎重考慮一下，Oracle的SQLNET是一種帶知識產(chǎn)權(quán)保護(hù)的私有化協(xié)議，這個數(shù)據(jù)庫廠商如果沒有獲得Oracle原廠的授權(quán)使用，可能存在侵權(quán)的嫌疑。如果真有數(shù)據(jù)庫廠商這么干了，那么說明這個廠商的法律意識很淡薄。他們認(rèn)為自己并沒有破解Oracle的代碼，只是從網(wǎng)絡(luò)協(xié)議上破解了SQLNET的協(xié)議包，一切都是自主的。實(shí)際上幾年前我和還在經(jīng)營貧民軟件的老樓也探討過這個問題，當(dāng)時很多客戶需要他們提供基于Oracle數(shù)據(jù)庫的OneProxy，當(dāng)時我們討論的結(jié)果是，可以基于JDBC/ODBC/OCI來做這個功能，但是不能直接破解SQL*NET來做，否則容易陷入知識產(chǎn)權(quán)糾紛。

目前一些國產(chǎn)數(shù)據(jù)庫廠商與MySQL/PostgreSQL等客戶端兼容，這一點(diǎn)是沒有什么問題的，因?yàn)檫@些數(shù)據(jù)庫都是開源的，網(wǎng)絡(luò)包協(xié)議也是開源的，這就是目前為什么有很多數(shù)據(jù)庫產(chǎn)品可以直接兼容MySQL/PostgreSQL數(shù)據(jù)庫的客戶端，但是很少看到開源/商用數(shù)據(jù)庫直接兼容Oracle的客戶端的最主要的原因。

基于上述考慮，我個人認(rèn)為，通過破解SQL*NET達(dá)到數(shù)據(jù)庫與Oracle客戶端的兼容，是一種十分危險的知識產(chǎn)權(quán)侵權(quán)行為。如果Oracle的客戶端和JDBC驅(qū)動能夠直接訪問果茶數(shù)據(jù)庫，那么就已經(jīng)說明侵權(quán)已經(jīng)存在了。我們搞國產(chǎn)化數(shù)據(jù)庫，可以學(xué)習(xí)Oracle的先進(jìn)經(jīng)驗(yàn)，可以盡可能在一些語法、用法上和Oracle兼容，但是不能突破知識產(chǎn)權(quán)保護(hù)的壁壘，不能侵權(quán)，這應(yīng)該是我們的廠家應(yīng)該秉持的底線。

實(shí)際上現(xiàn)在國產(chǎn)數(shù)據(jù)庫都在搞與Oracle的兼容性適配，這里面一定有大量的知識產(chǎn)權(quán)方面的陷阱，因此我們的數(shù)據(jù)庫廠商需要多找一些法律方面的專家來協(xié)助分析，否則如果做大了，很容易陷入法律風(fēng)險之中。

前陣子有個數(shù)據(jù)庫廠商和我討論數(shù)據(jù)庫的內(nèi)部視圖，比如DBA_TABLES等做得和Oracle一模一樣，是否存在法律風(fēng)險的問題。我不是知識產(chǎn)權(quán)法律方面的專家，并不清楚這個問題的答案是什么，我想大部分國產(chǎn)數(shù)據(jù)庫的廠家也沒有能力給出準(zhǔn)確的答案。不過我還是希望國家主管部門能夠在這方面做一些工作，為我們的數(shù)據(jù)庫廠商劃出一條知識產(chǎn)權(quán)保護(hù)的紅線來。不過我當(dāng)時給了他們一個打擦邊球的方法，就是把這些系統(tǒng)視圖在RDBMS內(nèi)核里換個名字，而對需要這個功能的用戶提供一個完全兼容視圖的創(chuàng)建腳本，從而既能夠提供最大兼容性，又能最大限度地規(guī)避可能存在的法律風(fēng)險。