这是一个创建于 1690 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景
-
别人的一个 github 的小项目（ 3 个功能文件），fork 出来玩了一下。
-
原代码有不少冗余不必要和错误的部分。本来一共也才几十行。
-
基本重写了大部分，改了部分实现逻辑，完善了类并且加入了参数修改等功能。基本上就是改了个面目全非吧。git 上看没有一行是一样的了。
-
另外该作者的这个本身项目也是基于另一个仓库改的，没有 fork……
提问
-
PR 回去也有点尴尬，毕竟面目全非了。PR 回去都有点挑衅的意思……
-
但感觉又需要尊重作者。可是原本这么小个东西，还加了一堆 license。改完之后就只有一个文件。然后额外有 readme 和两个 license，要用的话还得重写一遍 readme，实在是没啥必要（注释和示例都写代码里了）。
-
对 github 的规矩也不太熟。碰到这种情况，请问下大家，怎么处理比较好？
第 1 条附言 · 2020-03-18 00:59:55 +08:00
说一下后续
- 我一开始fork的项目是一个胡编生成器，现在已经取消fork了。
- 他是基于另一个文章生成器，就狗屁不通什么的，还挺有名。但也没fork。
- 我一开始是改了实现方式，修掉了一些bug，把函数型做成类，增加了一些变量的替换点，增加了类参数的配置修改等一系列东西。然后把语料库改成yaml便于录入，然后还把语料库里的替换规则都改了，素材分组也有增加。主程序里调用语料库的方式和规则也基本全都改了。
- 然后我就有点纠结要不要PR，所以提了这个帖子。
进一步的改动
- 但是刚才又做了一些深入的修改，把语料库的划分搞得更细了一点，自然调用的方式也又改了。
- 然后题材也改了，感觉没必要嘲讽胡编玩。结合工作所需，改成了直播卖货的语料库。明天可能会再完善一下。
- 所以目前来说，从创意到实现已经完全和前两个项目不同了。
- fork回狗屁不通吧，还加了几个语料库，而且实现逻辑整个都改到面目全非了，不大合适。fork回胡编生成器，也基本是同样的问题。
- 考虑下来，我也就作为单独的项目先做着了。目前也就自己小圈子先用着，暂不公开了。
但讨论还是可以继续
- 我觉得我一开始的行为算是完善一个项目，那样的话是PR回去比较好。
- 同样在python下，改良和重构我觉得区别还是挺大的，小改动可能大部分作者不介意，但整个重构的确有点尴尬。如果有人忽然按他的习惯把我的项目重写一遍，我也不知道如何是好。
- 以前也有一次类似的情况，也是重写了绝大部分代码，结果是单独作为一个精简版的新文件给PR回去的，没动人家原本的主文件。反正也是有点尴尬。
- 而连功能诉求都变掉的话，那PR回去也怪怪的。
- 我看他那个项目有人改成网页版或者js版，也就是另开一个项目了。
- 我觉得有一种也许可行的方式是，不方便PR的场景下，readme鸣谢/标识一下原作者。
- 感觉这个边界还是挺模糊的。所以我觉得有兴趣的朋友可以继续讨论看看。
 |
1
llxxxll 2020-03-17 23:04:29 +08:00
PR 回去
|
 |
2
cmdOptionKana 2020-03-17 23:07:36 +08:00
"该作者的这个本身项目也是基于另一个仓库改的，没有 fork"
他改动大不大，或者可以考虑 pr 到原仓库？ |
|
3
cmdOptionKana 2020-03-17 23:11:00 +08:00
另外可以考虑先与原作者联系一下，看他有什么意见。
|
|
4
cmdOptionKana 2020-03-17 23:17:20 +08:00
突然想到，他没有 fork，那么源头仓库用的是什么版权声明？根据版权要求，如果这个“二房东”没有带上“真房东”的版权信息，有可能属于侵权了，不宜在这个二房东的仓库上继续操作。
|
 |
5
Tink 2020-03-17 23:17:36 +08:00 via iPhone
看看开源协议
|
 |
6
hszhakka2ex 2020-03-17 23:19:43 +08:00
既然没有一行代码是一样的了，你就新建一个仓库把它作为你个人的作品就行了。
|
 |
7
qinxg 2020-03-17 23:21:22 +08:00
你就新建一个仓库把它作为你个人的作品就行了
|
 |
8
JCZ2MkKb5S8ZX9pq OP @cmdOptionKana
嗯，他对原项目的改动也谈不上大，本来就是几十行的小东西。 我想还有一种选择就是我管我 fork 的那份放着，也不 PR 了。 毕竟改太多了，提给人家也挺尴尬的，如果对方要接受了，等于我把人家几乎全盘给推翻了。。。好像也有点失礼 还有一种选择是单独作为项目，然后鸣谢一下作者和他引用的原仓库。 |
 |
9
seki 2020-03-17 23:26:26 +08:00
看协议吧，协议允许的话怎么处理都没啥问题，我觉得也没有必要想太多
|
 |
12
wzw 2020-03-18 00:22:16 +08:00
@kamal #11 假设 我写了一个 Python 小工具, 我用了 MIT 协议的 fastapi, 那么这个协议如何算. 谢谢
|
|
14
wzw 2020-03-18 07:53:40 +08:00
@chinvo #13 我上面没有说清楚, 说具体点是:
1. 我不是改造 别人的, 而是 import flask / import pyqt5 2. 如果我引用了 MIT/GPL 等多种协议, 那么我自己开源在 GitHub, ①如何选择协议 ②可以不选吗? |
 |
15
aleung 2020-03-18 09:47:30 +08:00 via Android
联系原作者（包括上游和上游的上游），附上自己的修改的介绍，问问对方是否接受 PR。如果对方接受，就进一步商量如何合并，如果对方说不必了，你在自己项目 readme 里的 credit 里面引用上游项目就可以了。
|
|
16
aleung 2020-03-18 09:48:54 +08:00 via Android
这种做法并不失去礼，是对对方的尊重。语
|
|
17
aleung 2020-03-18 09:51:34 +08:00 via Android
直接沟通是效率最高的方式，不要猜别人的想法和反应，每个人思维方式都不一样。用语礼貌点就行了。
|
1
Select Language