在Github上进行分叉时,如何保持与GPL兼容?


13

我最近在Github上创建了一个项目,并对它进行了一些修改,将它们推回到派生的存储库中,并要求原始开发人员进行更改。(我认为这是对Github进行贡献的首选方式。)该项目已获得GPLv3许可。

我是对代码进行更改的作者和版权所有者。只要我遵守原始作者设置的许可,我也可以发布修改后的代码(即原始代码和我的更改的组合-通过将更改推送到我的分支中来完成)。

现在,我遇到了GPL中的以下要求。

该作品必须带有明显的声明,说明您对其进行了修改,并给出了相关的日期。

在法律允许我将更改推送到Github之前,似乎需要进行一些超出实际编码的工作。这项工作需要什么?我如何遵守上述要求?(我是否在修改后的源文件中添加了其他版权声明?我是否创建了Contributors文件并添加了我自己的文件?还是这些提交表明我的所有权是足够的事实?)分支受GPL保护的项目时是否还有其他陷阱?

Answers:


2

这行是与衍生作品有关的,它们与母版分开维护和运输。在这种情况下,您将需要保留这些记录(由源代码控制自动完成)

但是,您所做的不是衍生工作。您已提交更改,并已拉回到主分支。您所做的更改现在已成为原始项目的一部分。

此外,使用源代码控制(公共存储库)意味着您将始终遵守此要求。

存在每个人如何定义“突出”的问题。对于开发人员而言,源代码控制(/ + issue tracker)是查看更改的主要方式,但是,如果您要维护派生作品,则可能需要以非技术格式维护一系列实质性更改。


1
我发现将更改推送到我的仓库中的合法性不太可能取决于原始开发人员是否决定撤回更改。至于“公开回购意味着合规”,对我来说似乎很合理,但是您对此主张有任何支持吗?
avakar 2012年

另外,难道不是“衍生”而不是“衍生”吗?:)
avakar 2012年

@avakar-我并不是说合法性取决于您是否被撤回;我只是针对您的具体情况量身定制答案。如果您没有退缩,那么您将维护派生的作品。源代码管理应该涵盖您,但是我看到的唯一可疑的部分是如何定义“突出”。对于开发人员而言,源代码控制是查看更改的一种主要方式。但是,您可能希望以非技术格式维护重大更改的列表。
Craige 2012年

1
同样,“派生”在语法上是有意义的,但我认为公认的术语是“派生”。我更新了答案,改为使用该术语。
Craige 2012年

@Craige,需要例如在非技术性格式””
Pacerier
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.