What kind of open source license should I use for my project?

#opensource #license #question #help

I am building an open source project, which allows the users to download the build (version) of application, self-host anywhere and use it for either personal or business use.

Restrict:

Resell the application build or source code
Rebranding
Distributing the modified version

Allowed:

Private use
Business use
Modification (use the modified code on your own or contribute back to original source code)
Distribution (only the official application build or source code)

I do want to leverage the power of open-source, while avoid mis-use of source code.

Please let me know a license which can fulfil these set of conditions.

Thanks

Top comments (7)

Austin S. Hemmelgarn • Sep 9 '20

What you are describing is not open source software, it's source available software. The difference, which is often overlooked, is that users can create their own version of open source software as an independent project, which your terms functionally disallow by only allowing for private usage of modified versions of the software.

This kind of restriction is not going to attract contributors, and will in fact potentially scare off possible users as well (at least, the smart ones).

The question of what the correct approach is here comes down to what you mean by 'misuse of source code'.

If you're worried about patent trolls, you can protect against that to some extent by careful use of licensing terms (the Apache License and MPL do this).
If you're worried about misrepresentation of your brand, that's also possible to cover, just add license terms to require rebranding for any redistribution that includes any type of modifications.
If you're worried about people doing stupid things with your code and then blaming you for the results, that's trivially covered by every serious FOSS license in existence. It's actually harder to find a license that doesn't explicitly state a lack of warranty of any kind.
If you're worried about potentially being in legal trouble yourself for illegal activity of your users involving your software, then it's a bit more complicated. In most jurisdictions, you're only on the hook if the software is designed to enable illegal activity, not if a user just happens to use it for such a purpose that it wasn't designed for that happens to be illegal. So if you're designing this to help people break the law, just don't release it, otherwise you're covered by the same clause mentioned in the point above about people doing stupid things with your software.
If you're worried about someone bypassing some business model you have to make money off of this software, you need to reevaluate your business model against the practical benefits of being open source. Essentially, either go open source and free for the software but let users buy support contracts, or go closed source andlive with it (or go hybrid and properly split out your components so that the proprietary stuff is separate from the open source stuff, and make sure the open source stuff is usable by itself).
If you're worried about something else, chances are that you're either overthinking things, or open source is not the correct choice for you (and source available probably is not either).

Ricardo Sueiras • Sep 11 '20

As above, what you describe cannot be done as open source. Some organisations have tried to implement partial elements of what you are trying to achieve, using an open core model. Open sourcing the core of your product, but then keeping other parts under commercial license. You have to weigh up how this will impact adoption, community, etc before you decide the right thing for you.

Yashu Mittal • Sep 10 '20

If a license allows distribution, restricting the user for resell will not help much. Right?

Austin S. Hemmelgarn • Sep 10 '20

It depends on what your goal is.

If you're trying to make sure people come to you to get the software and pay you for doing so, you by definition can't allow for third-party distribution (at least, not without royalties), but that's no longer open source.

If you are just trying to sell support contracts, it depends on what it is you're trying to do (RedHat and SUSE are making significant amounts of money on support contracts for RHEL and SLES respectively, espite FOSS equivalents existing, but they're managing to do this because they are offering products enterprise users care about).

For a hybrid approach, it kind of depends on how you split it out. It's not all that hard to have a FOSS offering and then have a third-party component it can load that is not FOSS (possibly paid). VirtualBox does this (the core code is FOSS, but some of the hardware emulation capabilities are handled in plugins that are not), and there are other things that do it as well (for example, hardware acceleration for some video codecs on the Raspberry Pi works like this too, all the user-space stuff is FOSS, but you have to buy a license key that gets loaded into the GPU on boot by the firmware to be able to actually use the hardware codecs). The important part is to keep the proprietary/paid stuff isolated as plugins (and make sure that you can actually use the FOSS component to a reasonable degree without it, otherwise you will have a harder time getting users in the first place, and an even more difficult time getting FOSS contributors (because they won't be as easily able to test their changes)).