Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide about Contribute License Agreement #4

Open
lukaszwojtow opened this issue Mar 6, 2024 · 4 comments
Open

Decide about Contribute License Agreement #4

lukaszwojtow opened this issue Mar 6, 2024 · 4 comments

Comments

@lukaszwojtow
Copy link
Contributor

I'm not sure how I feel about CLAs. On one hand, they seem to go against the open-source spirit. On the other hand, they take away the main developer's freedom regarding future commercialisation options. I've created this issue mainly to provoke some discussion and to have myself convinced one way or another.

So let's take two hypothetical situations:

  1. There is no CLA
    A developer works on the software and accepts contributions without a CLA. Unfortunately, at some point, he/she is bored with the project, or signs some serious non-compete at their $day_job, or just gets hit by a bus.
    What can the community do? They need to fork the last available version and carry on.

  2. There is a CLA and the software is available under some open-source license.
    A developer works on the software, makes it successful and popular. At some point, they decide to commercialise it.
    So he/she declares that they won't work on free versions anymore and changes the license.
    What can the community do? They need to fork the last available open source version and carry on working on the project.
    Unless I'm seriously mistaken, the MIT/Apache/GPL licenses cannot be taken away, and the last published version will always remain under the old license, with all the benefits. A CLA doesn't affect what the community can do when the owner decides to "pull the rug". And from the other side: the lack of CLA doesn't create any obligations for the owner. He/she can stop working on the project at any time for any reason.

In fact (and I admit it's a bit twisted logic), if I (as the owner) see some options to commercialise the project in the future, I'm more likely to work on it while it's still GPL. Writing the code is fairly simple. Making a project popular is much harder (and so is dealing with crappy PRs, users' entitlement, and such).
And even this assumes that I will get some valuable contributions. Most OSS doesn't get any, or gets something trivial. A very small fraction of OSS is actually developed by the community.

Then there is a question: why would anyone make a PR to contribute to the main repo? After all, they could just fork the repository, make the required changes, and use their fork forever. Instead, they prefer if it's the main developer that deals with maintenance pains. Admittedly, this was my reasoning for my contributions: I just didn't want another piece of software that I needed to maintain. I'm not sure if it's fair to ask the owner of the repo to give up his/her rights just because I fix the bug that hit me personally.

So, to summarise:
With CLA: fewer contributions but more commercialisation options in the future. Project may be developed towards being "more professional".
Without CLA: potentially more valuable contributions, but probably always remain a "pet project".

Any thoughts?

@ShaneCurcuru
Copy link

I can give you the definitive answer: "It depends." 8-)

  • Some groups of FOSS contributors avoid projects with CLAs because 'reasons', so you need to be aware you attract slightly fewer likely contributors with one. The real risk isn't in a CLA; it's in who the CLA is with. Unfortunately you're not the FSF, ASF, or some other well-known FOSS Foundation, so a few people won't trust you to not dual-license or the like later. Most developers won't even notice, other than the hassle of having to sign it (you will be using some CLA helper bot, right?)
  • Long term, the CLA allows the holder to potentially relicense the larger work, since CLA's typically grant the project owner that right. Without CLAs, it's not really possible to (legally) relicense or dual-license in useful ways.

The real question is: which goal is more valuable to your project roadmap? Hopefully collecting a few more contributors without a CLA? Or ensuring that you might be able to better commercialize the whole work later by relicensing/dual licensing?

CLAs with for-profit companies are indeed to be shunned in most cases. CLAs with long-established foundations are fine to use, because the industry can see that the FSF/ASF/PSF and the like use those only for their own legal risk management, and would never abuse the trust. CLAs with indivduals or small projects like this... who knows?

Good luck in any case.

@hunger
Copy link

hunger commented Mar 8, 2024

You can also chose to accept contributions under a permissive license. You (and anyone else, too) can relicense those contributions at any point, without needing a CLA.

Edit: Update to make my intent clearer.

@lukaszwojtow
Copy link
Contributor Author

You can also chose a permissive license. You (and anupyone else, too) can relicense that at any point with or without CLA.

Very valid point. Thank you.

@vednig
Copy link

vednig commented Sep 6, 2024

Rather than using CLA for a webserver, and limiting probability of usage further I would suggest making base code OSS and provide support and other exclusive features

After all, they could just fork the repository, make the required changes, and use their fork forever

Since it's AGPL (and they uphold their side) "theoretically" the source for the fork will always be available for you to be able to copy and paste that code from if you want since it's in public domain.

Also, since commercialization will only prove beneficial when project becomes popular enough, I would suggest having two different orgs one non-profit that maintains code and one for profit that adds more features and provides it as a service, also you can provide their services to improve the project more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants