#1024程序员节 | 征文#
太久没有写博文了,最近在研究软件著作权方面的内容,简单上知网看一看最新的论文研究,写写自己的读书体会吧。
简单上知网搜一下相关的论文,找第一篇看看先。
[1]徐美玲.软件著作权侵权“开源抗辩”解析[J].知识产权,2024,(06):18-33.
这一篇是对外经济贸易大学法学院徐老师的文章,简单看了一下,关键词在于开源抗辩,开源抗辩分为广义和狭义,在非法演绎作品的可版权性争议,应秉持“违约-侵权”二分的基本原则,这里摘要提到了完善开源许可证条款(对于这一点应该是指开源许可证条款的订立者),并设立软件著作权集体管理组织(这个应该是指对国家或者协会机构方面的建议)。文章中表1 提到了一些典型案例,关于开源软件是否构成合作作品的问题,是法院在判别的时候争议的一个焦点。我们常说对于一个案件的事实我们要保证主客观的统一,该作者从三个维度进行了分析,第一,项目管理者与贡献者之间是否存在共同的创作合意。第二,项目管理者与贡献者是否存在共同创作的事实。第三,贡献者对开源软件特定版本的贡献是否满足实质性贡献的标准。开源软件具备构成合作作品的可能性。若基于前述三要件的评估,特定开源软件不构成合作作品,则其著作权归属于特定的单一主体;但若特定开源软件被认定为合作作品,则其著作权归属有所不同。
在看到这里就已经开始头痛了,因为后面的内容略微有点复杂,结合了许多的案件。简单的说后续就是讲了《著作权法》和《计算机软件保护条例》抵触时的情况。这里大家可以去扩展阅读,什么是旧法、下位法和特别法,什么是高法优于低法,为什么“特别法优于一般法”和“新法优于旧法”规则只适用于“同一机关”制定的法之间,不适用于不同机关或不同法律位阶之间的法律冲突。
所以看了本文之后的启发就是,利用开源软件开发的派生软件与再派生软件的时候,我们作为开发者应当主动与该开源项目的管理者做好相应的约定,有约从约,就能避免很多的法律风险。
该文还提到了基于“Copyleft型”开源许可证的不侵权抗辩研析,在该作者统计的11起案例中,有7例是抗辩失败的。简单来说(事实不会那么简单的,举个例子而已)就是A公司用GPL 3.0开源的东西造了A软件但是不开源(A公司违反开源协议),有B公司偷偷搞A软件造出B软件被A公司发现告上法庭。B公司可以主张A公司应负有将A软件开源的义务,然后B软件就可以获得A软件源代码的著作权授权,由此说,诶我不侵权。在我国目前的司法实践中来看,法院对这种情况还是要具体案例具体分析的,所以这个就是好问题,可以沿着这个方向做一些实证分析的文章。
文章中还提到增设软件著作权集体管理组织,以降低开源软件著作权的交易成本,这个是一个很好的建议,但是落实起来有难度,因为光是github上面就有数不清的项目了,开源的这种没有ZF背书很难用爱发电,要是真的成立了,又会多了许多流程审核限制。就像【Linux开源社区重磅炸弹!俄罗斯内核维护者被除名,Linus亲自回复: 我同意。】真的把组织的权利下放给开源社区和协会,更应该担心的是看到资本的无序扩展,对于每一个开发者来说其实更希望开源是净土,但是需要良好的土壤,可能现在做不到,以后会做到的吧。
20241024 10:24