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.

4
  • ... 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 '20 at 18:58
  • @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 '20 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 '20 at 19:29
  • 1
    "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 '20 at 19:35
0

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).

2
  • 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 '20 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 '20 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.