Relicense PcapPlusPlus to MIT? #247
Comments
|
Looks like a good idea. |
|
Looks good to me |
|
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. |
|
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. |
|
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. |
|
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, |
|
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). |
|
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. |
|
@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"... |
|
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: I personally am using these libs which depend on boost: 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. |
|
@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 |
|
One other thing to consider might be what licenses are used by the underlying implementations?
|
|
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. |
|
@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. |
|
No GPLv3? |
As author stated, he was looking for a permissive license. GPLv3 does not fall under that category due to its heavy restrictions and making it unsuitable for a lot of use cases. |
|
I released v19.12 yesterday but I haven't changed the license yet. The reason is that out of the 3 options (Unilicense, BSL and MIT): MIT is less permissive and BSL is much less popular. So although Unilicense has not been approved by OSI yet, it seems to the best compromise at this point which is both permissive and relatively well-known. I'd like to get your feedback and decide together how to take it forward. |
|
@seladb - How is MIT less permissive? Using a less-known license would require the users to read the all the details and look for subtexts and pitfalls, possibly even consult with a lawyer. Even if that's a very permissive license. So if you want your users to just use the library without worrying about the license, the best thing is to choose a very popular license (as permissive/restrictive as you like). |
|
thanks @amirgon for joining this important discussion! I totally agree that choosing a license which is popular and well-known is a very important aspect, maybe the most important one. However in my case, I'd also like it to be as permissive as possible. If I could I'd prefer not to have a license at all, but I came to learn that having no license is even worse. So I choose Unilicesne which is the most permissive I could find, here are some resources I came across: |
I'm not an expert too. As far a I know, the only "limitaion" of MIT is that one should include the original copyright and license notice in the code. Is this the limitation that concerns you? That license notice should be preserved? |
|
That's a good question! |
No, they don't need to do that. They can take your sources (or some of them) and change them as they like, but must leave the copyright notice unchanged. If they take your library, compile it into some closed-source product and distribute it, they don't have to keep any source open. Their only obligation in that case (of distributing closed-source binaries) is to mention somewhere (in a readme, help page or even a manual) that their code uses your library under the MIT license. That's it. In principle you are supposed to put the MIT copyright notice at the beginning of each file, but many people don't bother. It's probably enough to have a "license.txt" file (or something similar) in your repo. The MIT license is one of the most popular permissive open source licenses, together with Apache and BSD (and it's the more permissive among them), and a default choice in many cases where you really want minimal restrictions. (Disclaimer: I'm not a lawyer, the above is according to my limited knowledge) |
|
Stop with this permissive license. Learn from the elastic search fiasco &
license it as GPL v3.
…On Tue, 9 Mar, 2021, 1:45 AM Amir Gonnen, ***@***.***> wrote:
Can you please elaborate on what it means to "include the original
copyright and license notice in the code"? Does it mean that anyone who
uses PcapPlusPlus has to mention the license in every repo/file/project?
What happens if they take only specific parts of the code or if they
changes the code?
No, they don't need to do that.
They simply must not remove the notice from your files.
They can take your sources (or some of them) and change them as they like,
but must leave the copyright notice unchanged.
There is no obligation or limitation on any other file that did not come
from your sources.
If they take your library, compile it into some closed-source product and
distribute it, they don't have to keep any source open. Their only
obligation in that case (of distributing closed-source binaries) is to
mention somewhere (in a readme, help page or even a manual) that their code
uses your library under the MIT license. That's it.
In principle you are supposed to put the MIT copyright notice at the
beginning of each file, but many people don't bother. It's probably enough
to have a "license.txt" file (or something similar) in your repo.
The MIT license is one of the most popular permissive open source
licenses, together with Apache and BSD (and it's the more permissive among
them), and a default choice in many cases where you really want minimal
restrictions.
(Disclaimer: I'm *not* a lawyer, the above is according to my limited
knowledge)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJXD5SQDM2SFMIHIWXY7ZDTCUV6LANCNFSM4I3WR6ZQ>
.
|
|
@bornlibra23 - Could you tell us more about the elastic search fiasco? GPL v3 is more restrictive - it requires the sources remain open source on derived work. |
|
Switch over to dynamic linking. I know that will need some work specially
for this project.
Essentially Amazon forked elastic search & closed its own tree when
original author changed its terms of service.
Google search "elastic search Amazon fight".
I wholeheartedly disagree with permissive licences. They are a wolf in
sheep's clothing as evidenced by the issue noted above. There seem to be
too many licences these days anyway.
…On Tue, 9 Mar, 2021, 3:05 AM Amir Gonnen, ***@***.***> wrote:
@bornlibra23 <https://github.com/bornlibra23> - Could you tell us more
about the elastic search fiasco?
GPL v3 is more restrictive - it requires the sources remain open source on
derived work.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#247 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJXD5SPMJPODQVEGTACUDLTCU7IPANCNFSM4I3WR6ZQ>
.
|
|
@bornlibra23 dynamic linking is a different issue that is being discussed here: #61 😃 @bornlibra23 regarding your comment about the license - I heard about the Elastic vs. Amazon dispute you mentioned. Of course, it's hard to compare between Elastic and PcapPlusPlus. Elastic is obviously much more popular and widely used, which explains why it's being targeted by large cloud providers. PcapPlusPlus is not there yet... But also keep in mind that behind the open-source Elasticsearch project there is a private company (Elastic) that tries to exist and make money out of it, which is not at all the case with PcapPlusPlus. I'm not a profitable organization and I never tried (and don't think I will try) to make money out of PcapPlusPlus. For me - the reward is people using this project, like it, and perhaps even contributing to it - pretty much like most of the open-source projects. Maybe if this project becomes as big and popular as Elasticsearch I'll need to start worrying about licensing issues 😄 @amirgon you make a great point. If I understand correctly the main difference between MIT and Unilicense is that Unilicense doesn't even require the copyright notice, is that correct? |
I think that's correct.
Right. |
|
thanks @amirgon , you make a good point. I'll consider it when releasing the next version of PcapPlusPlus. BTW, do you know what are the pitfalls (if any) in changing an open-source license? Anything I or the users should worry about? Just one more anecdote - Unilicense isn't a new license, it's there for more than 10 years now... |
|
I am back again! Going back to my old comment from one year ago.... I would be totally fine if you went MIT only - as @amirgon noted the only real requirement your adding is people must now add your license file into this distribution. The boost license is a bit less known (I would say in the c++ world its quite well known though) and it functions much like the MIT except you don't have to do ANYTHING when you redistribute your executable. Please please DO NOT go down the GPL route that license would remove you from being usable in closed source commercial applications. There is LGPL as an option but then you MUST dynamic link for closed source compatibility (which could be complicated for this library). TLDR; to answer your question "Anything I or the users should worry about?" Boost - Nothing I am not a lawyer or license expert but this is my understanding from my usage of different libraries through the years. |
|
Thanks @Dysl3xik for your input! Happy to see you here again 😃 As for BSL - according to the little research I've done 1.5 years ago BSL is even less popular than Unilicense which misses the point of choosing a more popular license. I think the best option is to go with MIT. My only concern is that once the license change happens, users who want to upgrade their PcapPlusPlus version might need to add license information to their project to stay compliant with the license. This is probably not a major issue, but something to consider. I'd prefer not to go with the dual license route - it'll make things even more complicated, especially for me 😝 |
|
Agree for MIT License, go for it in 21.05 @seladb :) |
It didn't work out for v21.05, maybe in the next release... 😃 |
|
I'm not a contributor, but I would opt for either BSL or Zlib for least amount of restrictions while still keeping the integrity of the software alive, while also allowing projects using PcapPlusPlus a smoother transition from Unlicense/Public Domain. Zlib's licence can just be included in the root directory of the source since it's so brief and self explanatory, and BSL is popular enough for a 5 second Google search to yield a simple explanation of the content of the license. Not to mention that this library is written for C++, in which BSL is well known. The popularity argument is not good since these license's are not hundreds of pages long. They are merely a paragraph long. Any competent lawyer would know how to interpret such licenses regardless of "popularity". Afterall, these lawyers have access to the same search engines as everyone else. |
|
you can adopt a dual model, GPL for open source projects, and for propietary software, you can relicense it to whatever they want, at a cost. |
@Kreijstal thanks for your response! At this point I don't have plans to make profit out of this project, so everyone can use it for any legit reason, both for open source or profitable organization |
and others
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
The text was updated successfully, but these errors were encountered: