2

One of the main purposes of a CLA (contributor license agreement), as I understand it, is to allow some owner of the software to have full rights to relicense the code if desired. This is rather onerous on both the contributors and the owner. Rather than doing this, couldn't you just add some line at the top of your license, such as:

The following restrictions apply, unless granted explicit permission by <owner name>

(I'm not a lawyer and don't know how to write a license or contract, but hopefully the general idea is clear)

If I were to use a license text with this general idea, could it hold up? Can taking steps to make sure contributors are aware of this, such as by putting it prominently on the contributing page, help the case?

Some things I would want to allow, that seem like they should be fine as long as the general idea holds, possibly requiring some changes to license text:

  • If someone wants to fork a project, they should be able to remove the owner from the license text (but not add a new one), such that the original owner cannot grant rights to derivative work (but contributions that do not remove the license text may still be relicensed by the original owner)
  • The owner should be able to charge money in exchange for granting a closed source license.
Improve this question
12
  • 1
    I just found the very similar opensource.stackexchange.com/questions/7195/… Looking at the specifics of the question I am unsure if the answer is the same. I don't include the problematic "for any purpose", but that seems like it might be implicit, or else problematic to leave out.
    – rtpax
    Commented Mar 6, 2023 at 22:56
  • 1
    @rtpax But which "explicit permission" could the Owner grant in your construction? The Owner can only grant rights which they hold, which requires that they were licensed or transferred to the Owner. My answer in the linked question explains that international copyright laws might have surprising provisions that make overly simplistic CLAs ineffective, and that a CLA being "onerous" is a feature, not a bug.
    – amon
    Commented Mar 7, 2023 at 18:00
  • 1
    There are two potential problems in your construction. (A) What rights are licensed to Skeet? (B) Has a valid license been granted? Once (A) is resolved, your points (1) and (2) seem fine – you can grant whatever rights you want and the license is obviously compatible with itself. However, (2) and (3) do raise the problem (B), that it's difficult to tell whether the purported license is valid. You can't make up arbitrary terms and use them to expropriate rights from other people. Otherwise, everyone who reads this comment now owes me 666 EUR! What makes a license valid depends on jurisdiction.
    – amon
    Commented Mar 7, 2023 at 19:28
  • 1
    I'm not saying that GPL-Skeet is necessarily invalid, just that I have severe doubts that it would work across jurisdictions. I suspect that your construction might work in the US, though it is unlikely that the GPL-Skeet license would form a contract that Skeet could enforce if a contributor intends to withdraw the license. However, I'm fairly certain that (3) would fail if a German forked it, since German copyright law has privileges only for gratis public licenses like the GPL, for example that no signatures and no appropriate compensation is needed.
    – amon
    Commented Mar 8, 2023 at 10:01
  • 1
    Regarding MIT vs GPL-Skeet, consider that MIT and GPL are symmetric. If you distribute modifications under the same license, you're just granting the same rights that you received. You also couldn't have modified the work if you hadn't accepted the license terms. Enforceability of Open Source licenses like the GPL has been confirmed in various jurisdictions. But privileging one actor breaks this symmetry. Unfair license terms might be invalid, and it could be difficult to show that a valid license contract has been formed.
    – amon
    Commented Mar 8, 2023 at 10:02

0

Reset to default