Relicense PcapPlusPlus to MIT?

[seladb]

As you all know I created PcapPlusPlus as an open source project, with a goal in mind that everyone will be able to use it for any purpose (personal, academic, commercial or other). I'm always keeping this goal in mind and trying to make sure people are not blocked using this software because of licensing issues.

The current license is Unilicense. I'm not a lawyer and have very little understanding of open source licensing. I chose Unilicense because I was looking for the most permissive open source license I could find, and this seemed like a good option. I used this web-site which has an easy-to-understand comparison between the different licenses: https://choosealicense.com/licenses/

I recently came to know that Unilicense has some detractors. For example: it hasn't been fully approved by the OSI (Open Source Initiative). Also it is much less common and popular comparing to other open source licenses (like GPL, MIT, Apache, Mozilla, etc.), which might make lawyers less comfortable in approving software licensed that way.

There is a discussion going on in PcapPlusPlus Google group about this topic: https://groups.google.com/forum/#!topic/pcapplusplus-support/vR5csiyUY1Y

Gareth who started this thread suggested to dual license PcapPlusPlus, but I think it might make things more complex for the average user. So my suggestion is to relicense PcapPlusPlus to a more standard and lawyer-friendly open source license, such as MIT. From some reading I've done (and again - I'm not a lawyer) it seems to be the most permissive open source license out of the popular ones.

As you can imagine I've never went through a process of relicensing a project and my knowledge is very limited so I decided to ask you - PcapPlusPlus contributors and users. I'd really appreciate your thoughts and opinions about this.

If we decide to relicense we can probably do it from the next release of PcapPlusPlus as this thread suggests.

Please let me know what you think.

@echo-Mike @Dysl3xik @vicenterb @gx740 @Lapshin @solvingj @eteran @rpanah @luigino @krepver @gvanem @f-squirrel @bpagon13 @xloem @tomerb @sinall @ncrumbak @max197616 @christinaa @axasoft @MrSiz @lasorda @AndreyBronin

[lgbaldoni]

Looks like a good idea.

[krepver]

Looks good to me

[christinaa]

Zero-Clause-BSD Could be a viable alternative if you're aiming for a public-domain-like license since MIT is still a notice-type license (although permissive in all other aspects), while Zero-Clause-BSD is a modified version of ISC license with the notice clause removed, effectively making it the closest to "most permissive".

Also when looking at MIT, the ISC license is also worth considering as it's basically a stripped down version of the MIT license containing only legally necessary text but otherwise being identical to MIT (from my understanding).

But otherwise looks good to me, MIT is a fine choice too, the notice clause isn't really a big deal.

[garethsb]

I have suggested on the Google Groups thread using the Boost Software License, which is also short, MIT-like, but doesn't require notice in binaries, only source.

https://choosealicense.com/licenses/bsl-1.0/

[Dysl3xik]

I agress with @garethsb-sony

Boost would be good I think, it keeps the requirements on the coder the same as today, i.e. no notification required.

If you switch to MIT or similar you then require people to edit their about, readme, whatever to notify people of the license.

[seladb]

Thanks everyone for your comments. It seems you know much more about open source licenses than me :)

You were mentioning 3 other licensing options in addition to MIT: Zero-Clause-BSD, ISC and BSL,
Could you please provide an overview "for dummies" about the differences between the 4 of them?

@christinaa @garethsb-sony @Dysl3xik

[garethsb]

My 2p. And usual disclaimer: IANAL.

All four are similar.

MIT and ISC both require notice in source and binary distribution. MIT is the most commonly used licence on GitHub (45% in 2015) by a significant margin. On that basis, since common = devs/managers/lawyers have seen it before, I'd prefer MIT over ISC.

Boost requires the license file to be included in source-form copies/derivatives of the software, but not in binaries. It recommends, but does not require, a couple of lines are added at the top of every source file. It's common in the C++ world, so many devs/managers/lawyers will have seen/approved it before.

0BSD does not require the notice to be included in either source or binary copies/derivatives, but may also have problems for some devs/managers/lawyers (for example).

[christinaa]

I think BSL would be best in this case, besides even in case of Unlicense or 0BSD, the license notice is still commonly checked into the internal repositories for "bookkeeping" (as proof of the fact that the software was provided under these terms).

So yes I agree with @garethsb-sony, I think BSL would be a good compromise since it's well known, doesn't require a notice in binary distributions and checking in and accounting for all license notices/grants is already common practice for most places.

[seladb]

@garethsb-sony @christinaa thanks for explaining the differences between those licenses.

It seems we've narrow down the options to two: MIT or BSL.

BSL seems to be more permissive but MIT is more popular.

Actually I couldn't find BSL in articles comparing the popular licenses used in GitHub projects, both in 2015 as @garethsb-sony shared and also in 2018. Am I missing something here? If BSL is not popular we might end up with the same issue of having a license which is not "lawyer friendly"...

[Dysl3xik]

Trying to pick the most popular license isn't necessarily the best way to look at this problem IMO.

Another way to consider this is what projects are using boost, this list is the easiest for me to find as its provided by boost directly even though its not too long it does show Adobe using it:
https://www.boost.org/users/uses_shrink.html
https://www.boost.org/users/uses_open.html
https://www.boost.org/users/uses_inhouse.html

I personally am using these libs which depend on boost:
https://github.com/PointCloudLibrary/pcl
https://github.com/apache/avro/tree/master/lang/c%2B%2B
https://github.com/chriskohlhoff/asio - now supports non boost variant too

I don't have the time to do it, but I think if you searched you could find many projects people are using which may not be boost licensed themselves, but which depend on boost, and therefore mean people are using the boost license without any issues.

If you are really worried about it go dual license MIT + Boost.

I personally think boost is the most compatible with the existing license as it maintains no requirements for an official release, whereas MIT will require a notice or readme to be included.

[seladb]

@Dysl3xik thanks for your comment. The reason I'm worried about license popularity is because one of the main reasons we're doing this whole exercise is to choose a license which is more well-known than Unilicense so people will feel more comfortable with it.

If BSL is not one of the 10 most popular licenses in GitHub than I'm a little concerned...

Regarding dual license - I prefer not to go that route because it will make things even more complicated for the average user.

To summarize so far - it seems @christinaa @garethsb-sony @Dysl3xik are in favor of BSL over MIT.

What about other people?

@echo-Mike @vicenterb @gx740 @Lapshin @solvingj @eteran @rpanah @luigino @krepver @gvanem @f-squirrel @bpagon13 @xloem @tomerb @sinall @ncrumbak @max197616 @axasoft @MrSiz @lasorda @AndreyBronin

[garethsb]

One other thing to consider might be what licenses are used by the underlying implementations?

• libpcap appears to be 3-clause BSD (https://www.tcpdump.org/license.html)
• WinPcap however identifies portions that are 4-clause BSD (https://www.winpcap.org/misc/copyright.htm)
• DPDK seems mostly to have user-space code as 3-clause BSD and kernel code as GPLv2 (http://git.dpdk.org/dpdk/tree/license/README)
• PF_RING also claims kernel code is GPLv2, and user-space code is LGPLv2.1 (https://www.ntop.org/products/packet-capture/pf_ring/)

[echo-Mike]

Hi, @seladb and other contributors. I am personally releasing all my open source projects under MIT license as I find it more applicable all around the globe.
At my country the open source licensing is not respected by most companies (except the huge ones) as here are no legal precedents that lay to some actions against one that broke open source license aggrement and the law base is not ready to deal with open source licensing.

[lgbaldoni]

@selab and everyone else: I'm no expert on OSS licensing, so if you need my consent for any small contribution I might have given, whatever you decide is good for me.