Choosing an open source license

[Heiso]

There are only about a million webpages out there that explain the differences between all of the license options and people's opinions as to which one is best. Most of which basically say if you're selecting from among the most permissive ones it's all personal choice.

I hope to release an open source LabVIEW version of a NATS (https://nats.io/) client soon, and I'm struggling on choosing a license. The developers of the server have released clients in a few languages as Apache 2.0, most other developers are releasing their clients under MIT, and a couple of others have done different versions of the BSD. I'm leaning towards MIT just to conform with the majority of other client authors, but I see the OpenG library uses BSD-3 and documentation on vipm.io suggests using some form of BSD. Moreover, I see all the new stuff that Francois has been releasing via the Open Source LabVIEW Project is BSD-0, so I'm almost to the point where I'm going to throw a dart at the wall and see where it lands.

I remember there was some conversation at a CLA summit 4-5 years ago regarding wanting to redo some of the licensing for a number of the OpenG packages but there was concern about getting all the developers to sign on, etc. I don't remember if it was to<->from BSD or what. What was the reasoning behind that and did it ever happen? It came up during someone's presentation on the Unlicense I think (which coincidentally in conversation  was the first time I'd ever heard of the DBAD license... definitely my favorite).

Is there a particular permissive license that gives you all heartburn that might preclude you from using it in your own code? The non-promotion part in the BSD-3 appeals to me, but again, I'd like to stick with the herd of other NATS client developers (who mostly use MIT) and unless I suddenly become incredibly famous I highly doubt anyone's going to use my likeness to market anything so maybe BSD-3 doesn't really matter.

[ShaunR]

20 minutes ago, Heiso said:

Is there a particular permissive license that gives you all heartburn that might preclude you from using it in your own code?

Any strong copy left licence.

20 minutes ago, Heiso said:

and unless I suddenly become incredibly famous I highly doubt anyone's going to use my likeness to market anything

It's not so much about that. For most open source licences it is primarily about someone taking your software, claiming it as their own, then sticking a new licence on it. You can get into a situation where someone that copies it, claims they wrote it and then comes after you for copyright infringement when you wrote the stuff. I had something like this on the NI forum where someone removed all the copyrights and proffered the toolkit as theirs. NI wouldn't remove it until I pointed out that it violated the licence which stated that all copyright had to remain intact and showed them the original toolkit (which had the licence text).

Secondary to that, it enables good faith actors to know exactly how to distribute the software and comply with your wishes.

Edited June 24, 2022 by ShaunR

[Rolf Kalbermatter]

Personally I think the differences between MIT, BSD, Apache and Commons like licenses are fairly small. And unless your project ends up being a huge success that storms the world (fairly small chance in the LabVIEW world for that 😁) you won't notice a real difference between them.

The ones that clearly stand apart from these are the GPL and LGPL licenses which, while open source too, try to force any user of it (to some smaller degree with the LGPL) to open source their entire code too. 

[JKSH]

You mentioned a number of different permissive licenses; Shaun and Rolf also mentioned copyleft licenses.

Here is a simplistic ranking of the "forcefulness" of different open-source licenses, from most copyleft (#1) to most permissive (#5):

1. GPL
2. LGPL
3. MPL 2.0
4. MIT/BSD-3/Apache 2.0
5. BSD-0/Unlicense (virtually Public Domain)

 

On 6/24/2022 at 11:00 PM, Heiso said:

Most of which basically say if you're selecting from among the most permissive ones it's all personal choice.

That's a fair statement.

I agree with Rolf: In terms of the common permissive licenses, MIT, BSD-3, and Apache 2.0 are very very similar in intent. Your project will probably end up in the same place no matter which of these 3 you pick (unless you or your project become super famous, as you said). Apache 2.0 is considered more complicated that the others though.

BSD-0 and Unlicense are even more permissive; they are virtually at the level of public domain.

 

On 6/24/2022 at 11:00 PM, Heiso said:

The non-promotion part in the BSD-3 appeals to me

Apache 2.0 has a similar clause.

 

On 6/24/2022 at 11:16 PM, ShaunR said:

Any strong copy left licence.

How strong is strong for you?

• GPL is the ultimate copyleft license: all software that uses a GPL library must also be published under GPL.
• You can release your software under any license you want if it only uses LGPL libraries, but you must still allow your users to swap out the LGPL'ed part for a different version. This makes it difficult to use a LabVIEW library under LGPL, because it's not trivial to write a LabVIEW application that lets users replace certain VIs.
• MPL 2.0 is a middle ground between LGPL and MIT. And it is easy for LabVIEW devs to use MPL 2.0 libraries.

 

15 minutes ago, Rolf Kalbermatter said:

The ones that clearly stand apart from these are the GPL and LGPL licenses which, while open source too, try to force any user of it (to some smaller degree with the LGPL) to open source their entire code too.

The difference exists because GPL is primarily concerned about freedoms for the end-users, while the permissive licenses are more about making developers' lives easier.

LGPL does not require you to open-source your code at all.

Edited June 26, 2022 by JKSH

[Rolf Kalbermatter]

28 minutes ago, JKSH said:

LGPL does not require you to open-source your code at all.

Only if you make absolutely no changes to the library and use some form of dynamic linking.

If you make any change to the LGPL portion, you are obligated to distribute that change to any user of your software who asks for it.

And if you don't use dynamic linking, your entire project gets part of the "work" that the LGPLed library presents. There exists no broadly accepted technology that lets you replace static linked libraries in an end product with some other libraries.

LabWindows/CVI has/had a technique that lets you load actually lib files as if they were shared libraries, but that was a highly CVI specific feature that no other compiler that I'm aware of really supports.

Edited June 26, 2022 by Rolf Kalbermatter

[ShaunR]

21 minutes ago, Rolf Kalbermatter said:

If you make any change to the LGPL portion, you are obligated to distribute that change to any user of your software who asks for it.

You are also required to supply the source and compile environments of the vanilla LGPL code even when just dynamic linking and that can be quite big in size. While one may argue it's merely a maintenance overhead, never-the-less, it is an overhead keeping track of (and version control of) other peoples source AND the specific compilation environment one used.

Edited June 26, 2022 by ShaunR

[Rolf Kalbermatter]

9 minutes ago, ShaunR said:

You are also required to supply the source and compile environments of the vanilla LGPL code even when just dynamic linking and that can be quite big in size. While one may argue it's merely a maintenance overhead, never-the-less, it is an overhead keeping track of (and version control of) other peoples source AND the specific compilation environment one used.

I would think a link to the original projects website that has the downloads available could also suffice. Of course that leaves you in a bit of a bind if the original developer site goes down or is otherwise made unavailable.

[ShaunR]

1 minute ago, Rolf Kalbermatter said:

I would think a link to the original projects website that has the downloads available could also suffice. Of course that leaves you in a bit of a bind if the original developer site goes down or is otherwise made unavailable.

Quote

Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.

I'll let you fight your argument in court. Until then, I'll just offer anyone who wants the code a zip file of my build.

[Rolf Kalbermatter]

22 hours ago, ShaunR said:

I'll let you fight your argument in court. Until then, I'll just offer anyone who wants the code a zip file of my build.

i'm not going to fight anyone. I simply don't use LGPL software. 😁

[Francois Normandin]

0-BSD is the only OSI-certified license that gives the same level of restrictions as Public Domain, while still, as you well know from those other presentations you referred to, being recognized in (almost) all countries. Public domain and The Unlicense are not recognized universally.

Like Shaun points out, the biggest worry is that someone can claim my work as theirs because the license is open enough that you can copy any part, or the whole, without attribution. 

Honestly, I don't think the prospect of someone claiming I cheated would meet any level of credibility, since all the development is done in a 3rd-party public repository and I never squash my commits. Easy to prove I went through the development process and I couldn't temper with the commit hashes/timestamps of those commits. You can see all the mistakes, dead-ends, reworks, fixes... Anyway, whether or not you use a more restrictive license would not prevent someone from falsely claiming their work predates yours. If that were to happen, I trust the LabVIEW Community will hold the reputation of the original developer. 

If the work you want to release is owned by a company, I would recommend to not use 0-BSD. Make sure there is at least an attribution clause.
 

Edited June 30, 2022 by Francois Normandin