V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
JamesChen
V2EX  ›  问与答

如果公司基于我的个人开源项目做二次开发,而我又把一些不涉及公司逻辑的内容开源,那该开源行为违法吗?

  •  
  •   JamesChen · 2023-02-22 12:33:50 +08:00 · 1968 次点击
    这是一个创建于 625 天前的主题,其中的信息可能已经有所发展或是发生改变。
    提前说下,我感觉应该是违法,但不确定具体逻辑细节,来跟大伙唠唠。

    背景信息:
    1. 该开源项目比较大,几十万行代码,其中不仅包括自研中间件,也包括大量的业务逻辑;
    2. 在加入新公司之前,该开源项目就已经有几十万行代码了,因此该开源项目的版权目前跟这家新公司完全没关系。
    3. 公司项目组准备基于我的开源项目做二次开发;
    4. 已经跟公司协商好,这是我的个人开源项目,知识产权归我所有,而不是公司的项目。并且公司也允许我继续维护开源项目。
    5. 因为开源项目用的是 Apache 2.0 ,所以公司可以直接修改源代码做二开,不需要进行代码阻断,因此更容易有版权问题。

    但即便如此,如果我在加入新公司之后,继续维护该开源项目,那公司如果哪天想告我,是不是也能告?如果确实是违法的,那有什么办法可以尽量避免违法呢?

    P.S.估计有网友会问我为啥不找律师,我也就突发奇想 想到了这个问题,顺便聊聊而已。
    15 条回复    2023-02-22 17:41:35 +08:00
    cheese
        1
    cheese  
       2023-02-22 12:39:01 +08:00   ❤️ 1
    让公司创建组织,用组织提交公司的内容,你进行 pr 。开源部分需要让新公司的 leader 进行审核授权。
    简单的说就是让公司来提 pr ,不要你自己抄上去
    JamesChen
        2
    JamesChen  
    OP
       2023-02-22 13:10:35 +08:00
    @cheese 感谢提议哈。按我的理解,这方式应该就是以公司的名义(但背后的人还是我)“回馈”上游开源项目吧?
    好像这方式会靠谱些,但我和公司都不太想在开源社区跟我的开源项目扯上关系 hhh 。

    不过好像确实没有既让公司不出现,我又能自在开源(自在指:按自己的节奏开源跟公司逻辑无关的代码)的两全其美的办法。这方法我先收着,谢谢哈,等等看大伙还有没有啥其他妙招。
    coderluan
        3
    coderluan  
       2023-02-22 13:25:06 +08:00   ❤️ 1
    就是违法,除非公司直接允许你把公司代码开源(一楼操作就是满足这种条件),否则你基于什么理由都不成立,允许你维护项目又不是允许你用公司代码维护项目。
    shakoon
        4
    shakoon  
       2023-02-22 14:20:57 +08:00   ❤️ 1
    你所谓的“不涉及公司逻辑的内容”实际上已经是属于公司的成果了,你自己是没有权利拿去更新到你个人的项目上的
    westoy
        5
    westoy  
       2023-02-22 14:24:56 +08:00   ❤️ 1
    原则上职务产出相关的开源项目归属权是公司, 不是你的, 你离职之后这个项目要移交给原来公司的
    oneisall8955
        6
    oneisall8955  
       2023-02-22 14:33:32 +08:00   ❤️ 1
    是不是那个 java 写的 IM 工具?看了下,是个大佬,牛 X 。

    理论上,在上班时间做自己的项目是违法的,参考 nginx 。
    可否签订一份合同,每周或每月多少工作时间内可维护项目?

    对于`把一些不涉及公司逻辑的内容开源`,在合同上也签订,并且加上 1 楼的方式可行吧?
    JamesChen
        7
    JamesChen  
    OP
       2023-02-22 14:50:36 +08:00
    感谢楼上的各位。大概了解了,确实感觉如果公司拿自己项目二开,那自己就是就是在刀刃上起舞,那天就被公司告了。那我还真得“阻止”所在的公司拿我项目二开,哈哈哈,回头再找公司聊聊。再次谢谢各位!

    @oneisall8955 那算是“半个”IM 解决方案了。跟工作时间没关系,开源肯定是下班做了。主要是担心如果公司拿我项目二开,那我给我的开源项目改 Bug/加 Feature ,也等于改公司项目的 Bug/加 Feature ,反之亦然,hhh ,确实麻烦。还是阻止公司做二开相对最靠谱。
    leoleoleo
        8
    leoleoleo  
       2023-02-22 14:52:40 +08:00   ❤️ 1
    如果你要开源工作产出相关的内容,除非公司授权许可,不授权就是违法的,公司可以一告一个准,开发人员泄露公司代码的法律案例网上都能搜到。

    另外一个点是,如果你利用业余时间,自己维护这个项目,万一公司要告你,也会很麻烦,因为你需要举证你业余开发的代码和工作内容无关,但是公司又是基于你的项目做的二次开发,所以这个中间的各种举证和法律问题(技术层面很大概率会需要司法鉴定机构来出报告啥的),应该会很让人头大。

    如果想要继续去维护这个开源项目,一定要提前和公司提前约定好相关条款,签订明确的合同。
    chuckzhou
        9
    chuckzhou  
       2023-02-22 15:17:14 +08:00   ❤️ 1
    建议你定个价格,把源码版权一次性全部卖给公司,自己就别去折腾开源了。
    否则将来某天你跟公司有矛盾,公司告你泄密和盗窃,只要有一行相同的代码,你都脱不了干系。
    跟公司有矛盾是早晚的事,对待遇不满,对领导不满,
    或者领导看你不顺眼,又或者项目不赚钱了,公司想开掉你。
    yolee599
        10
    yolee599  
       2023-02-22 15:32:07 +08:00   ❤️ 1
    这种藕断丝连的关系很难搞的,万一上了法庭,一个字就能判你败诉
    tool2d
        11
    tool2d  
       2023-02-22 15:36:07 +08:00   ❤️ 1
    国外员工标准 github 开源流程,就是洗代码。

    把所有商业和版权代码,都替换成无版权的第三方库。代码一多,工作量还是比较大的。

    楼主这种情况,最好敏感功能写两份不同代码,实现同一个功能。给公司用一份,自己开源一份。这样最安全了。
    min
        12
    min  
       2023-02-22 15:52:35 +08:00   ❤️ 1
    搞个商业授权分支,授权给你公司,与开源版本隔离
    superliy
        13
    superliy  
       2023-02-22 16:51:12 +08:00
    @JamesChen 有这样级别的开源项目 年薪要多少个 w
    superliy
        14
    superliy  
       2023-02-22 16:53:15 +08:00
    大佬,找时间学习学习
    JamesChen
        15
    JamesChen  
    OP
       2023-02-22 17:41:35 +08:00
    @superliy 这开源项目其实在面试的时候基本没啥用,大部分公司压根不认这个,就像之前技术圈很火的“Homebrew 的初创者 Max Howell 因为在面试时不会反转二叉树而被拒”,大部分面试官只认八股文+算法,呵呵了。
    当然,我做开源主要原因就是图一乐,不是为了面试啥的。如果为了面试,倒背八股文+刷算法多香。

    楼上说的搞双协议这招我觉得也行,不过个人目前做开源,主要就图个开心。如果搞个双授权,也会辜负一些给我 Star 的用户,毕竟一些用户就是看上 100%开源+免费+信得过我不会作妖,才用我那开源项目,而作妖的开源项目太多了,整得开源圈子乌烟瘴气。所以尽管中途切双授权的行为也无可厚非(毕竟“人是要吃饭+养家的,靠爱发电没有持续性”),但也会辜负一些老哥的信任,也不是很厚道。所以双授权就算了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2699 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 01:48 · PVG 09:48 · LAX 17:48 · JFK 20:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.