1

Suppose that out there in the web there is a project, let's call it <PROJECT NAME>, licensed under LGPL v 2.1 or, at the end user's discretion, above.

An external contributor (not officially affiliated with <PROJECT NAME>) submit a merge request to the project. "Submit a merge request" means that he writes some code that substantially improves <PROJECT NAME>, uploaded his code on <PROJECT NAME>'s website and asks the maintainers of <PROJECT NAME> (from now on, just "the maintainers") to merge his code with <PROJECT NAME>'s code.

The contributor code starts with the following notice:

This file is part of <PROJECT NAME>.

Copyright 20XX-20YY <CONTRIBUTOR NAME> <CONTRIBUTOR SURNAME> <>

<PROJECT NAME> is free software; you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
published by the Free Software Foundation; either version 2.1 of the
License, or (at your option) any later version.

<PROJECT NAME> is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with <PROJECT NAME>; if not, see http://www.gnu.org/licenses/.

The maintainers don't merge. Suppose that one maintainer demands that the contributor call some functions from <SOFTWARE X>. But the contributor thinks that basing his work on <SOFTWARE X> will substantially decrease the quality of his work. Furthermore, the contributor notices that this maintainer is also a maintainer of <SOFTWARE X>.

After the initial merge request, the contributor continues to work on his code, which, if merged, would substantially improve <PROJECT NAME> capabilities. This goes on for years. The contributor has written a lot of code, millions of lines, over several years, that substantially improves <PROJECT NAME>, while repeatedly asking the maintainers to merge.

After years of code writing, the contributor asks for the final time the maintainers to merge. They don't.

The contributor is finally fed up, remove the merge request, delete his code, and ask for his code not to be used anymore in any way by <PROJECT NAME>.

The contributor is banned from the project and kicked out from the community by the maintainers.

The maintainers, who have saved the contributor's code in their computers, open another pull request with his code. This means that they re-upload on the web what the contributor has deleted. They modify a small portion of the code (2/3 lines) to use <SOFTWARE X>. Then they merge.

  1. Is it legal for the maintainers to do that?

Relevant to answering this question may be the explanation here:

Some open source projects, generally large ones with corporate backing, occasionally have what’s known as a Contributor License Agreement. This document explains any additional requirements and rules for submitting source code to a project, and will usually have a clause explaining that the submitter is granting their copyright to the project’s parent entity

So we will suppose that <PROJECT NAME> does not have any such Contributor License Agreement.

  1. Can be argued in court that the contributor did not offer the license to the public indiscriminately. He did offer his Merge Request and related license to the maintainers. By not merging the pull request, the maintainers did not effectively accepted the license. Now the contributor has withdraw his code, and so there is no licensing offering anymore. Would such argument stands?

  2. If the answer to the previous is no, would the maintainers still be required to keep the original contributor copyright notice?

    Copyright 20XX-20YY <CONTRIBUTOR NAME> <CONTRIBUTOR SURNAME> <<CONTRIBUTOR EMAIL>>

The jurisdiction is United States.

Improve this question
6
  • ... NAL, but probably the initial argument is that, even though the project may not have copyright, the contributor did publish their code under the GPL by including the header, which means it could still be included (...possibly only in places without "moral rights", which might make European distribution difficult). The license couldn't be switched from GPL, though, without permission from the contributor.
    – Clockwork-Muse
    Dec 24, 2020 at 18:58
  • 1
    @Clockwork-Muse I don't understand this comment. What "the project may not have copyright" mean? The project is released under LGPL ver 2.1 or above. The contributor is compelled to submit the code under the same license, per the project's licensing terms. What does it mean "published in places without "moral rights"?. And what NAL means?
    – robertspierre
    Dec 25, 2020 at 7:41
  • "NAL" - "Not a Lawyer". A license is not the same thing as "owning" the copyright; For Windows, for example, Microsoft has copyright because it's a work that the company has written, and distributes the program through a commercial license. Here, the original author has copyright (ownership) over the code, but has granted a license (can use) to the original project and project consumers. If the project wanted to change the project license, they would need to get permission from the author to do so.
    – Clockwork-Muse
    Dec 25, 2020 at 19:29
  • 2
    "Moral Rights" are a thing in some European countries and other jurisdictions. It gives authors of works some additional control even after selling or distributing their works - a big example is painters suing museums for how/where their paintings are displayed. Here, the argument could be that the author could assert moral rights to prevent the inclusion, because it wasn't taken "as they intended it".
    – Clockwork-Muse
    Dec 25, 2020 at 19:35
  • So just to simplify the story. The maintainers accepted the additions contributor, but changed 2 or 3 lines. Yes, that is one of the major goals of (L)GPL; to allow modified versions. For example, if the contributor wants to, he can choose to maintain his own version with those 2-3 lines changed back the way he wanted.
    – Brandin
    Sep 21, 2021 at 13:45

1 Answer 1

Reset to default
3

Yes

There is no explicit provision in the LGPL allowing it to be revoked and, given its nature and intention, it is unlikely a court would find an implicit one. So, the contributor granted the licence in perpetuity.

Future users would need to comply with the licence which includes maintaining the contributor”s copyright notice (clause 1).

Improve this answer
5
  • 2
    This seems to skip over what I thought was the main point of the question, which is whether the contributor's code was ever made available under the LGPL inthe first place. One might argue it could be under a license like "maintainers may distribute this under LGPL if it is merged into the project; otherwise all rights reserved" and although I'm not saying I find that plausible, I suspect it'd be useful for answers to shed some light on why it's not plausible.
    – David Z
    Dec 25, 2020 at 6:42
  • @DavidZ I thought that. Could be argued that the contributor offered the license to the maintainers, and by not merging the code the maintainers did not accept the license in the first place?
    – robertspierre
    Dec 25, 2020 at 7:43
  • @DavidZ in this case, the contribution, merged or not, would be a derivative work of the original, and as such must be licensed under the LGPL to be able to be distributed - if the contributor offered it to the project under a different license, that would be a breach of copyright. Its as simple as that.
    – user28517
    May 23, 2021 at 21:33
  • @Moo Good point, though one might be able to argue a loophole based on the multi-version licensing. In any case, I think the point of the original question still stands if the license were, say, MIT instead of LGPL.
    – David Z
    May 23, 2021 at 23:12
  • 2
    @DavidZ if the contributor contributed code with a different license, ie LGPL 3 rather than the projects LGPL 2.1, they would have to be explicit in the PR to that effect (ie, change the license file). This isn't something you can just go "well, actually, I intended to use a different license" at a later date because the code you PRed contains a specific license file which contradicts you... As for the MIT aspect, I think the collaborator would have even less of a leg to stand on unless they were very specific about presenting the PR with the GPL or a proprietary license.
    – user28517
    May 23, 2021 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .