Add LICENSE file for Locust Cloud and reference it from the main license

[cyberw]

In the future, Locust Cloud files will be added under /proprietary instead of having them in a separate repo.

[cgoldberg]

I know it doesn't break any licensing terms... but I think it's disappointing to have proprietary code mixed into this repo. I'd much rather have it completely separate so there is no confusion about what is or isn't open source. This kind of feels like a takeover of what was once a community based free open source project. I think this is kind of offensive to the community that built this project and also hinders future adoption.

[cyberw]

Hi Corey! I dont have time to write a detailed response right now as I'm heading out.

The idea here is definitely not to take anything over.

The only thing we'll be adding into the "proprietary" directory is the locust-cloud CLI tool for launching distributed runs on our infrastructure (and possibly, in the future, other things that relate to communicating with the commercial offering/SaaS solution), we're not removing or moving any code/existing features there.

We could possibly maintain that in a separate repo and just have it as a dependency, but this way is easier to maintain and also more transparent (for the users of Locust Cloud) what is open source and what is just ”source available”.

Also remember that the stuff we're doing in Locust Cloud is going to greatly benefit users of the open source project as well - its a win for everyone :)

I asked @heyman to weigh in when I made this PR, lets see what he thinks.

[cgoldberg]

@cyberw thanks for the clarification.

I just think it's better to keep the entire repo open source and MIT licensed with any "source available" stuff kept separate. If I'm evaluating a project, the first thing I usually do is check the license. As soon as I see anything proprietary or overly restrictive, I basically just immediately move on. I know others aren't as strict and are fine with source available, but I think adding this is a turn off to some users.

But yea... interested to hear what others think.

[heyman]

To me it sounds more simple and clean to keep the proprietary code in a separate repository.

Based on the license, it also seems like including it in the open-source repo might not be a good fit. For example:

This software and associated documentation files (the "Software") may only be used in production, if [...] and otherwise have a valid Locust Cloud subscription.

This suggests that there could be code within the open-source repository that users aren't even allowed to execute, which feels a bit off.

This License applies only to the part of this Software that is not distributed as part of Locust Core

This sounds like the License invalidates itself if it's included in the Locust repository (depending on how you interpret "Locust Core").

[mbeacom]

Hello everyone,

I share sentiments similar to @cgoldberg. Introducing these new license changes, especially by fragmenting the repository’s licensing structure, seems likely to encourage forking. It also risks confusing community members and potential contributors about what is and isn’t truly open source.

I’m not sure why the pull request for the latest license change (#3019) is gone, but the commits (e.g., 944b7f8 and 522af43) reflect modifications to the effective license holders leading into these changes that could lead to long-term fragmentation. Of course, under standard open source norms, the original MIT license terms remain valid indefinitely for all contributions made prior to these changes.

On a personal note, I had hoped Locust might return to its community-driven roots, which attracted many of us to contribute in the first place. However, these recent changes appear to commercialize the project and move it closer to a BSL-like model. While the repository may remain “source available,” it’s arguably no longer purely open source under widely recognized definitions.

Regards

[cyberw]

Hi everyone!

I have taken your comments to heart and will not be making any changes to the license.

Instead we will make locust-cloud (the code used to communicate with the Locust Cloud service, currently in a private repo) public and available under an MIT license and add it as a dependency to Locust. That way Locust will not depend on anything that isn't open source.

I guess I underestimated how important the "purity" of the repo was for contributors, thinking that I could draw a line between the directories and add new things there, without anyone feeling cheated.

I still think commercial backing has been great for Locust, and in fact necessary for its long term survival. Since Locust Technologies was started, there have been security patches, UI improvements and a lot more deep work than just a small fix here or there (we've just started building proper support for asyncio, for instance). In the last year we made 27 releases of Locust, a much higher pace than before, when I was maintaining Locust on basically nights and weekends.

Best regards,
Lars

[cgoldberg]

Thanks Lars... I think that's a great move.