黃同學你好，
自由開源軟體元件可以被自由地取來安裝利用、修改散布，甚至也可以拿來做商業販售，前提是個別條款裡所規定的「義務性規定(obligation)」也必須要被遵守。
所以妳原信提到的「採用自由開源元件在我們開發的系統中，會不會造成未來使用上的限制呢？」
如果我沒有意會錯誤，這邊指的限制應該是「未來技轉或是加值運用上的限制」？
這個問題原則上的答覆是「會」，但是實際受到什麼義務性規定的約制，要看你取用的是哪一類的自由開源授權元件來利用！
一般來說我們把自由開源授權元件分為三個分類：BSD類別(BSD, MIT, Apache-2.0)、GPL類別(GPL-2.0, GPL-3.0, LGPL-2.0, LGPL-2.1, LGPL-3.0, AGPL-3.0)，與其他類別(MPL, CDDL, CPL, EPL…)。
- 首先在BSD類別裡，受到的拘束其實非常的少，原則上拿BSD類別的元件來改作，最重要的義務性規定就是不論程式碼怎麼改作與散布，都要保留原專案作者的「著作權聲明(copyright notice)」與「免責聲明(disclaimer)」，而如果你繼續選用BSD類別的授權方式來散布這個衍生程式，則必須提供該衍生元件的程式源碼，而如果你改用其他的授權方式來釋出這個衍生元件，則也不一定需要再提供衍生元件的程式源碼。
- 接下來是GPL類別，GPL類別的重要義務性規定就是：
- 基於GPL元件衍生的程式，再散布時一定要用GPL授權條款來散布。
- 只要散布了目的碼，就必須同時提供程式源碼的取得途徑。
- 其他類別的授權方式，則介於BSD類別與GPL類別兩者之間，一個普遍的原則是修改了其他類別的元件主體，大抵都要承繼其原來的授權方式，並以提供源碼的方式來散布衍生元件，但是自行編寫的獨立檔案與可區隔模組，則可以使用你自行選定、並且與該其他類自由開源授權條款不衝突的方式來進行散布。
所以你原信所說的「是不是將最終系統的程式源碼公開散布出來即可」？
其實沒有錯、不論是哪一個分類的授權方式，只要改作者願意將程式源碼，在散布程式目的碼之後同時提供出來，那大抵是可以符合任何一款自由開源授權條款的規則的。
當然、細節上，也並不是每一個授權條款都有這樣的要求，所以實際到時候要如果去符合這些義務性規定，就看最後選用了哪些元件來判斷。
你所提到的第二個問題是關於「MATLAB」這個專案，MATLAB是一個專屬軟體(proprietary software)，也就是說、MATLAB提供的開發工具與環境是沒有提供程式源碼的，我猜測你所詢問的是：如果MATLAB本身是不能提供源碼的話，那麼這部份的運用會不會牴觸到自由開源授權條款的相關義務性規定？
答案是「不一定」，但是我覺得產生衝突的爭議性與可能性不高，因為：
- 開發工具不一定影響成本的授權狀態：拿A程式編譯B程式，不必然讓B程式成為A程式的衍生作品，這就像是以MICROSOFT OFFICE來謄打文件或是製作簡報時，這份文件與簡報的權利還是屬於創作者，而不會是MICROSOFT的，所以說、如果你使用MATLAB的方式只是單純將其作為「純工具」使用，而最後產出的元件並沒有夾附其開發工具的程式碼，則所產出的元件、不一定就會受到MATLAB本身的授權規則所拘束。
- 判定兩個程式間是否有衍生關係，要看其實際的互動狀況，尤其是「依賴性(dependency)」的判定更是重要要點。Windows上也有以GPL-2.0授權的GIMP（美工繪圖軟體），但這並不會讓Windows受到GPL條款的拘束，因為該元件是依賴Windows平台來運作，而不是Windows平台一定要依賴GIMP才可以運作，所以一個大原則是，依賴他人程式才能運作的元件，較容易被判定為該程式的衍生元件，從而必須要受到原程式授權方式的拘束，也就是說、如果MATLAB已經是一個成熟的專案，那麼你開發出來的專案，即使取用了GPL-2.0授權的模組，但應不致有讓MATLAB必然依賴這些元件才能運作的狀況，從而可以從解釋上來處理這個授權拘束與擴散的關係。不過這部份並沒有定論、實際還是要看個案上，你所選用的自由開源元件，怎麼和MATLAB專案程式互動，才可以判定出拘束性的最後狀態。
先將一些綱要回在上面，希望這些資訊對你有所幫助，如果後續有細部資訊或再有疑惑的地方，再請接續回信討論。
敬祝 順心健康
20120110 1159 自由軟體鑄造場 林誠夏
TEL: 27883799 EXT.1474
您好 :
不好意思我想請一下,關於自由軟體是否對於我們在系統開發使用的開發軟體有所限制呢?
還是說只要將最終系統的程式程式碼公開出來即可
若有限制 想請教一下可否使用MATLAB開發軟體?
才能符合自由軟體的限制
