※ 引述《liu2007 (薯)》之銘言：
: 感謝PCMan耐心仔細回復，
: 首先這份專案只是我一個人下班時候寫的，背後並沒有公司或組織，當然也不可能營利
: 沒有法務可以諮詢只好求助網路
很多外商公司聘僱合約有明定條款，下班時間所寫，著作權依舊屬於公司。
合約沒特別規定的話，小心跟公司做的東西有沒有重疊，才不會踩到法律問題。
: 因為我還不確定、沒搞懂動態連結的東西，所以以下是我對於我的程式的想像
: 可能奇怪或不可行的地方，請見諒
: 在我的想像中，我的程式不提供dll，
: 但我會去搜尋看我程式的資料夾下面有沒有某個特定的dll
: 如果有的話我就去連結，提供使用者該dll的功能
: 如果沒有，程式依然可以跑，只是就無法提供使用者該dll的功能
這是很合理的作法，這樣一般不會有問題，類似是外掛程式的作法。
你的主程式著作權屬於你，open source 你可選你想要的授權方式，
但釋出的程式裡面不要包涵別人的 dll 就行。
不過，如果對方的 dll 有允許你再散佈，就可以一起釋出
例如如果那個 dll 是來自 LGPL 的專案，你是可以再散佈那個 dll 的，唯一要注意
是一般你提供 LGPL dll 給使用者，你也要能夠提供 dll 的 source code
補充一下，但如果這個 dll 是 GPL，即使是 dynamic linking 也可能算衍生著作
https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries
LGPL 則是可以動態 link dll
: 當然如果可以的話我也希望我的專案裡面不要包括那些要使用dll所需要的標頭檔
: 但好像是不可能的
一個常見規避的方法是用 dlopen() 或 LoadLibrary() (win32 API)
在 runtime 動態才去開啟 dll 檔案，這樣的話你的程式沒有直接衍生自 library
你只是寫了一段 code 當存在某個 dll，你會 dlopen 他，動態載入裡面的某個
function，這是某種外掛，但你沒有直接衍生自這個 library
這樣即使 dll 是 GPL，你也沒有直接使用或衍生自這個 library (但這作法存在爭議)
Header file 不一定需要，如果你 dlopen() / dlsym() 或 GetProcAddress()
這種動態載入的方法，不用 header 也能存取。
另外的作法就是你自己重寫那些 header，不要複製 dll 本來的 .h (但不能直接照抄)
這樣你重新寫的就變成你的著作權，也是一個規避的方法
: (雖然原篇底下推聞有人提到套件管理，但大略搜尋一下，我還是沒開竅，
: 不太清楚使用套件管理跟專案可以不用包含標頭檔的關係是什麼)。
: 以我的想像來說，我應該是
: 1.「非改寫」，甚至沒有直接copy一整份原始檔(cpp)在我的專案裡編譯。
: (但是需要標頭檔)
: 2.純粹想在 runtime的時候使用dll，像呼叫函式一樣，給參數然後得到想要的結果。
: 3.「非複製並散布dll」，我並不提供dll，使用者如果想要「解鎖」一些不是我寫的功能
: ，要自己想辦法生出dll，我才會去執行
: 以上只是我的想像
: 這種情況可以閉源嗎?
用 dlopen 動態載入方式，compile time 沒有直接連結這 library 的話，
一般是不會受到 library 授權方式的規範。
但如果你是 compile-time 就直接跟他 link，並且沒有這個 lib 就不能運作
那視情況可能就會構成衍生著作
GPL 授權就是如此，你就被迫一定要跟著 GPL，所以之前才會有些廠商被告
但 LGPL 就允許只是 link 沒改作的話不一定要用 LGPL
所以還是要看原本授權條款他怎樣寫
: 如果開源的話可以掛MIT而不是用原本LICENSE裡的 LGPL、unRAR、BSD 3-clause的授權嗎?
: 因為我目前還不確定如果我實現了我想像中的動態連結之後，需要掛哪些授權
: 掛MIT這種全開的授權只是圖個方便而已
MIT 非常寬鬆也很方便，他允許 re-license，也就是更改授權。
但是他也允許別人拿你的 code 去改之後，不再 open 變成私有軟體
你如果不介意的話 MIT 最有彈性
: 感謝閱讀
: ※ 引述《HZYSoft (PCMan)》之銘言：
: : 這問題很複雜，如果是你公司的 code，還牽扯著作權歸屬，建議諮詢公司法務
: : 以下講的是一般原則，不一定適合你的狀況
: : 首先看你如何「使用」別人的 library，和對方的 license 如何規定
: : 如果你是拿別人的程式來「改寫」，這算衍生著作，要看對方的 library
: : 是否允許改作以及再散佈，如果不能，那你的也連帶不能 open
: : 如果你只是 runtime 動態 link 他的 dll，你是「呼叫」他提供的 API，
: : 那你並沒有「改寫」他的程式，單純只是執行的時候需要他的檔案，這一般不算
: : 「衍生著作」，所以你的程式碼是你自己的，你要用什麼授權開放都可以。
: : 舉個例子，你的程式呼叫微軟 .NET 的 dll 提供的系統服務，很顯然你的程式
: : 只是呼叫他，但並不是微軟 .NET 的「衍生著作」，所以你的程式想怎樣授權隨你高興
: : 不用跟原本 dll 一樣，就算他是 GPL 也一樣。
: : 但有爭議的是如果你「靜態連結」成單一 exe，則別人的 lib 包進你程式的一部分了
: : 這時候就可能會受到「衍生著作」的規範 (有爭議)
: : 再舉個例子，你軟體用到某個 GPL 的 lib，但你的使用方式是「複製他的 code」
: : 然後做了一些修改，那你的程式就成為衍生著作，要遵守 GPL 規範，所以你的程式
: : 也自動變成要 GPL open source，再散佈也要遵守 GPL 規範。
: : 例外狀況是(這有爭議)，如果你修改的程式架在 server 上，是 web server 後端
: : 那使用者連上你的「網頁」算「使用者」嗎？一般認定是不算，所以連上網站的人
: : 並不能根據 GPL 要求要你網站的程式碼 (否則我們就可以跟很多電商要程式碼了...)。
: : 但如果你的網站系統賣給別人架站使用，那架站的人是「使用者」，根據GPL他可以跟你
: : 要求 server 程式碼。
: : 以上是 code 的授權，但使用別人的 dll 問題不是只有 source code 授權
: : 如果你是 link dll 不會有程式碼衍生問題，但對方的 dll 不一定允許「複製再散佈」
: : 也就是你可以 open 你的程式碼，但使用者拿來編譯需要 library 的 dll，
: : 但那個 dll 不是你的版權，你不一定有權利提供，使用者要自己去買這個 dll
: : 但如果這 dll 是 LGPL 授權，那他是允許再散佈的(但要遵守 LGPL)
: : 另外補充，license 的「授權」跟「著作權」不一樣
: : 你寫的 code 就算用 LGPL 發出來 open，大家有權使用以及改寫再散佈
: : 但原始的「著作權」還是你的，所以「你寫的那部份」code 改天你想改用
: : 別種授權，或是想改回私有，都是可以的，但如果專案摻入別人的 code
: : 那你不能改變別人 open 的部份的授權，只能改你自己寫(擁有 copyright)的部份。
: : 以上如果不清楚，歡迎討論! 希望有點幫助