Ask HN: Which open-source license should I use for my project?

[bradteamworks]

I'm building an open-source ERP system because I think I can do some things better than the current state-of-the-art. I've went with open-source because I've been frustrated in the past when things aren't "fixable".

I'm hoping that it becomes both very good, and very useful to people. I'd also like to make money from it somehow.

What license do you recommend? I don't know much about licenses. My current best guess is AGPL v3. But I see a lot of projects I respect using MIT.

The space is currently dominated by big players like SAP, Oracle, and Microsoft. There are other open-source solutions like Odoo (LGPLv3) and ERPNext (GPLv3)

Here is a link to the project: https://github.com/barbinbrad/carbon

[coreyp_1]

I'm actually speaking to a group of University students about this very topic later this week.

In my opinion, permissive licenses such as MIT, BSD, and Apache are best for libraries. A library is not the final product, but is a helpful tool that could be of benefit to many different projects. It can encourage participation for many different sources, including commercial.

A copyleft license, such as anything in the GPL family, is better for a final product in order to keep people from copying the product wholesale and passing it off as their own work. The AGPL is probably the strictest license possible in this domain. A copy left license discourages commercial participation in many circumstances, although not all. The Linux kernel, for example, is GPL version 2, but does benefit from commercial contribution.

For philosophical reasons, some people will say that you should only ever use a copyleft license, regardless of the subject matter. They do this because they believe that everything should be copyleft, and copyleft licenses are infectious. That is, the inclusion of a copyleft piece of code forces all of the code to be copyleft and subject to the distribution requirements. It may also invalidate software patents which, again, some people are strictly opposed to, and therefore they will only recommend copyleft licenses.

There's a lot of nuances to the different licenses, and the license is often reflect philosophical and political beliefs. For me, personally, I have released my code as MIT, which I greatly favor, however I have also written gpl'd libraries for something like drupal because that was the only option as Drupal itself was gpl.

[bradteamworks → coreyp_1]

Thanks! So what does AGPL (or the GPL family) actually restrict?

[coreyp_1 → bradteamworks]

The big difference between a permissive license and a copyleft license is in the obligation of the user when modifications have been made to the code.

A permissive license may require that you make the original source code available to your users, but that does not necessarily apply to your modifications. So if, for example, I have written project X, and license it as MIT, and you add a single feature to it, and now a user wants to see the source code, then you can give them the original code to project X, but you are not required to provide the code for your privately developed feature.

Conversely, with a copyleft license, in the same scenario, you would be required to release the code for your privately developed feature as well to your customer. Moreover, they would then be able to freely distribute that source code as well, including your privately developed feature. That is why the copyleft licenses are often defined as being viral or infectious, because they propagate to whatever code they come into contact with.

So then, the question of boundaries comes into play. What if the software is on another system? For example, you write program Y, and it calls system X across the network. With the GPL version 2, the copy left license does not cross the network barrier. Agpl, however, removes this barrier, making the virality of project X extend to program Y.

In short, copyleft is generally hostile to any proprietary use, and many companies won't touch it for any software that must be distributed to customers. Again, this aligns with some people's political and philosophical wishes, so they do not see a problem with this.

In short, permissive versus copyleft is a fundamental difference in how freedom is defined. The permissive license gives you the freedom to use software however you see fit. The copyleft license tries to eliminate the possibility of proprietary control. It's really two different sides of freedom. Permissive is freedom of the individual from control of the many. Copyleft is freedom of the many from control of the one.

[bradteamworks → coreyp_1]

I think I'm going to use a permissive license. I definitely want companies to be able to use this as a starting point for their own in-house ERP.

[solardev → coreyp_1]

This is a really, really terrific explanation of an often-difficult concept. Thank you for being so clear!

[bradteamworks → coreyp_1]

This is the best explanation I've ever read!

[bruce511]

>> I'd also like to make money from it somehow.

As a general rule, you can assume that if you Open Source it you will never see any money from it. Perhaps beer money here or there but you won't be quiting your day job.

There are exceptions to this rule but they are exceptions. If you figure out how to get Open Source paid for, that will be more valuable than ERP.

ERP systems are also a terrible idea for Open Source. Your target market is Enterprise (the clue is right there in the name.) Selling to enterprise is a long, complicated, expensive cycle. ERP is at the very extreme of that cycle. ERP projects cost millions to implement, require integrations with hundreds, or thousands, of existing in-house projects, and have full time implementation and maintainence staff.

I strongly recommend you find a single enterprise that is even a little bit interested in talking to you before you go down this road (hint: you wont).

They absolutely do not download and try out ERP level software - that's just not how it works.

I say this not to discourage you. Building something can be it's own reward. But I just want you to be clear on your goals. The odds of anyone ever using this are very very slim. The odds of you making any money at all is near zero as makes no difference.

I'm glad though that you are thinking about the license. Its important to choose a license that matches your goals.

[h2odragon]

You going to be upset if someone else makes a fork and charges for use of it? You want that not to happen, or to have you name on it when it does, or to have a share of any money?

I think we need to know more about your goals, what you want to achieve here.

If its just fill your own need, and let the rest of the world use that and maybe even build on it, but you dont really give a shit once your happy, then MIT would be a great choice.

If you're concerned with how people use your code then you probably want something more restrictive.

[bradteamworks → h2odragon]

Hey appreciate you asking!

I guess I'd be very happy if there was someone who was much more ambitious than me, who saw an opportunity to make a lot of money by doing sales on the product. It'd be great to work together with that person in a support-type role. And honestly, I wouldn't mind if they wanted to try it alone.

What would hurt though would be to do a lot of work to get it into a state where it was "the best" in some way, and a big player started selling a cheaper fork.

[gtirloni → bradteamworks]

Sounds like you don't want open source then. It's fine, really.

Even the AGPL allows forking. And there's nothing to sell actually.

If you have plans to self managed solutions and don't want to compete with other players doing the same, look into the source available licenses (BSL and others). They are not open source though, so please don't add those two words to your website.

Open source will get you more traction initially since some people won't even consider proprietary solutions in some cases. But it comes at a cost.

If this project is not expected to be your main income, maybe open source would work. Depends on your goals.

[bradteamworks → gtirloni]

When I say sell, I'm thinking "managed hosting and support" -- not the software itself. That seems like a pretty decent approach to me.

Definitely the main goal is to provide something better to people trying to do manufacturing. I'm not hoping to get rich, but also wouldn't mind making it a full-time thing if there were enough demand for new features/support/etc.