※ 引述《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)的部份。
: : 以上如果不清楚，欢迎讨论! 希望有点帮助