PfSense Is Closed Source
github.com
github.com
This happens So. Freaking. Often. Companies take open source software private All The Damn Time. They hire the key devs away with just enough money. Then they release another version under a different license. And before you know it a previously open source project is now all but closed source.
It doesn't even have to be with shenanigans this nefarious. Once you have the two or three devs all you have to do is release a value-added component and all but cripple the community one. It's roughly a million times cheaper than an acquisition.
If you want your hard-earned contributions to avoid this fate, do not contribute to "open source" projects. Find a copylefted project and contribute to that. Otherwise your work will end up being coopted by a profit-seeking enterprise.
Open source is the domain of large companies building fiefdoms. Just look at all those Apache projects and who contributes to them and who they're for. You would have to pay me big bucks to contribute to that ecosystem.
GPL or bust.
GPL software is still open source. The problem is when you contribute to a private company's MIT or Apache licensed software.
I would change that to:
'do not contribute to permissively licensed projects. Find a copylefted project and contribute to that.'
Give money and time to causes you support. Go contribute to the BSDs. Volunteer at your local animal shelter. But don't think that you're going to get rich from it. You'll save some puppies and help some people (and maybe some megacorps) but that's all you can expect.
AGPL3, but your point stands ;-)
GPL or its stronger copyleft counterpart, AGPL, can be later closed source too, afaik, at least under two scenarios:
1. Original developer owns all copyrights (CLAs).
2. There's no other contributor but the original developer.
MPLv2 and EPLv2 resist close sourcing the already open sourced bits to the same extent as xGPL, except xGPL is intrusively more viral than these two.
Also, I read somewhere that GPL lets one impose strange restrictions:
1. A vendor distributes binary of GPLd code to "X" (among other non GPLd things), and can impose upon "X" that if "X" does share vendor's GPL code without approval, "X" would breach contract (not necessarily of GPLd code, but of other non-GPLd things).
2. A vendor "rents" / "lends" binaries to "X", in which case the vendor doesn't have to share the binary's GPLd code.
IANAL.
Edit: Clarification. Ref: https://opensource.stackexchange.com/questions/2338/can-i-us...
2. A vendor can "rent" / "lend" a binary to "X", in which case the vendor wouldn't have to share the code.
I'm pretty sure neither of those are legal. https://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllow...
However, if you have the rights to dual-license the code, either of those would be just fine under whatever second license you'd like to cook up.
This is Traefik in a nutshell. 1.x had built in support for sharing Lets Encrypt certificates among HA nodes. Once they decided to make a company out of the project 2.x was released which axed the feature as being "too hard to implement." Yet somehow it exists just fine in Traefik Enterprise ($5,000/node).
Obviously the company policy is "We just sell stuff, leave us alone.". That's why they "invest millions" in patches which are not yet ready for upstream.
[0] https://forum.netgate.com/topic/121969/where-is-the-pfsense-...
(not affiliated, just friends with the OpnSense team)
Let's say you, zakki, release v1 of a program as the sole author. The code is yours, and you release it under 2-BSD. v1 will remain under 2-BSD forever; however, you are free to:
* sell the same code under a different license (including a closed-source commercial license)
* change the license of v2 to a completely different license – in this case, v1 will remain under 2-BSD in perpetuity but future releases are not.
This would be true for 2-BSD, GPL, whatever license you like.
---
This gets interesting when you are not the sole author. In that case, you either:
+ were fastidious about requiring your contributors to assign copyright to you, in which case the above holds
- accepted all comers, in which case you have to go on a crusade to chase down those people to assign copyright OR to agree to your license change – Mozilla did this (painful) exercise in its past[1].
---
Now, if you were not the sole author but you actually reused or forked code, like OpnSense (based on FreeBSD), your options are different. In that case, the underlying license cannot just "go away": FreeBSD's license carries through. However, as it is a very permissive 2-BSD, there's nothing to say OpnSense couldn't relicense to a proprietary license per the above.
---
Hypothetically, if OpnSense were based on Linux instead, the underlying GPLv2 would be attached. In that case, you could not relicense to a closed-source model because
> You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
(emphasis mine).
Clear as mud? :)
Keep in mind, though, that Linux is only a kernel, so if someone's careful with their components they could build a Linux-based system where Linux was the only component under the GPL, in which case they'd only be obligated to share the kernel source to any user who asks. It would have a slightly unusual-looking userspace in order to avoid GPL components; musl libc, toybox instead of GNU coreutils, no BASH, etc., but this is basically what happened with Android.
(IANAL, of course)
[*]: presuming they care about complying with licenses in the slightest, which many do not.
Only the copyright holder can re-license a copyrighted work. Re-licensing is not the same as sub-licensing. Under copyright law, the copyright holder is granted certain exclusive rights over their work. If the license grants sub-licensing, a licensee can pass on some or all of the rights in the license to a third party.
The license terms for a sub-license must be consistent with the original license terms, although not necessarily the same. The sub-licensor can use different words as in the original license, but they cannot override the terms and conditions that are required by that license. The sub-licensor cannot sub-license more rights than have been granted by the original license.
The BSD 2-clause does not allow sub-licensing. Works released under this license can be included in a larger work with a more restrictive license or modifications can be put under such a restrictive license, but the original license must remain intact.
If this is true, I don't think it's such a disaster as it's made out to be that OSS projects go proprietary, because if the interest is high enough, it can still continue as an OSS project in a fork.
That is correct. Once v2 has been released under the terms of any permissive license – GPL, 2-BSD, MIT – and you get a copy, you are free to continue following the terms of that license. The holder of the copyright cannot retroactively change the old license.
If that's a problem for you, you could try VyOS (LGPL/GPL2/GPL3 mix) or dnxfirewall (AGPL3).
FreeBSD is licensed under the 2-clause BSD license. The OpenBSD folks have a great license page where they explain their take on why two-clause BSD serves them well[1]:
> [...]putting code under an ISC or two-clause BSD license essentially makes the code as free as it can possibly get. Modifying the wording of these licenses can only result in one of the three following effects:
> making the code less free by adding additional restrictions regarding its use, copying, modification or distribution;
> or effectively not changing anything by merely changing the wording, but not changing anything substantial regarding the legal content;
> or making the license illegal by attempting to deprive the authors of rights they cannot legally give away.
PfSense ought not lie about what they do, but it's important to note that they are completely within their rights to take FreeBSD, extend it in any way they wish, and never share that back with the community.
Other licenses[2] feel differently, and before you release code to the world you should carefully consider where you fall.
Alas, the paradox of tolerance. Being 100% free for one generation means you frequently end up being 100% closed in a later generation. Being 99% free (“you can do anything except remove future users’ freedom”) is less pure, but it sticks.
(Believe me, as a several-time CTO, I've wound up in every case deciding that modifying virally-licensed code is way more trouble that it could ever be worth...)
pf in FreeBSD is still maintained, but it's not the pf from OpenBSD that everyone knows and loves.
https://svnweb.freebsd.org/base/releng/12.2/sys/netpfil/pf/p...
What happened and Why ?
Then FreeBSD hard forked pf and made it multithreaded.
Now FreeBSD's pf is the fastest implementation of pf but is missing the latest features/syntax and may have some bugs that were already fixed.
Meanwhile IPFW is still faster than pf anyway, so I don't know why people even care.
But, to what? I like to have a web ui and collectd metrics out of it. And the performance should be good for over twenty devices, VPN and a gigabit network...
pfSense: an established product. Supports kernel level wireguard and easy adblock through plugins. Easy upgrades. Not that great web UI but does its job. Shady OSS practices.
opnSense: no kernel level wireguard yet, but might be coming soon. No good adblocker plugin available. Easy upgrades. Great UI. Better OSS practices at least for now.
OpenWRT: supports kernel level wireguard. Supports LXD so you can install pihole. Good UI. More focused for market routers, meaning an x86 installation and upgrades mean flashing and reinstalling all extra packages.
Edit: seems like recent versions if opnSense handle DNS level adblocking quite well. I might give it a try tonight.
https://www.cjross.net/dns-security-and-adblock-with-opnsens...
I was so impressed with it I tried to rationalize just keeping Ipfire duties but transferring it to a much less power hungry device but couldn't find anything that was modern and wasn't a hobbyist kit (like the Apu2). Other than their own licensed devices that were out of their budget (smallest one is $390 and still needs a separate wifi AP).
Genuine question.
And wow. https://github.com/github/dmca/blob/master/2018/2018-04-30-p...
It looks like there's a RHEL/CentOS sort of thing going on here where the code is (mostly?) open but the branding isn't.
I would guess that pfsense/pfsense should be able to build it, but you probably won't have any luck on !FreeBSD/pfSense.
[0] https://github.com/pfsense/FreeBSD-src
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252894
Asking about it in the official subreddit resulted in responses ranging from unhelpful to hostile.
After looking at this repo more closely, this really is pretty suboptimal. build.sh is incredibly flexible, but yeah- no documentation on what you'd need to build a non-pfsense branded product.
That's pretty weird, given how much of this system seems to be geared towards being generically applicable and has some replacements aimed directly at rebranding some literal occurrences of "pfSense".
I really do enjoy the platform, I have dozens of Netgate SG-series devices deployed to clients and they work great, but I do find it hugely disappointing that it seems very clear that Netgate does not want anyone else producing builds of pfSense-derived software even if it's properly rebranded.
Their official claims that it's purely about the branding falls apart when you compare what's involved in building "nonSense" compared to Chromium, Iceweasel, etc.
I don't know if this realization concerns me gravely though... I would probably be much more frustrated if I had to spend weekends swapping out our networking gear yet again. To be fair, the router we use at our office is really stable. I haven't had to screw with it in over a year.
It goes to show that there is no guarantees that a company is standing by its word.
I imagine in the wild there are a ton of companies who "in theory" are open source, but they're just chunk of useless code by itself, opaque enough to not be obvious.
In reality a lot of companies appear to show off their internal deployment bits, leaving all the IP safely tucked away, whilst looking "open".
But that's no different that people using their github account as a portfolio showpiece, and dipping in as many projects as possible.
Contributor Docs Link: https://docs.netgate.com/pfsense/en/latest/development/pull-...
I'm not opposed to closed source projects, but no one appreciates false advertising.
Out of curiosity, How should a project of this nature properly advertise? Would an asterisk next to "open source" with a clarification be enough?
Netgate recently "sponsored" adding Wireguard to FreeBSD, presumably so that it could be used in pfSense.
https://www.netgate.com/blog/wireguard-for-pfsense-software....
https://svnweb.freebsd.org/base?view=revision&revision=36816...
I can't find the article but it was like "over 500,000 installations of pfsense!" ... turns out they got that number because every copy phones home.
AFAIK the article said that pfsense contacted their site somehow.
Now I am looking to migrate to OPNSense, but unfortunately their backup files are not compatible and OPNSense does not make any effort to facilitate the migration ([2]), which, especially in light of recent pfSense controversies, is IMHO a serous omission . Not that I am saying they should provide a "one click wizard" solution, but at least having a way to tell which of the pfSense backup sections are incompatible with OPNsense and need to be otherwise set up manually would be great.
[1] https://docs.opnsense.org/manual/etpro_telemetry.html [2] https://github.com/opnsense/core/issues/28#issuecomment-1417...
I couldn't find good source on how these entities are connected to each other, anyone kind enough to give more info?
I looked at pfsense and got a weird vibe from their site.
> This branch is 10723 commits ahead, 281789 commits behind devel-12.
It's quite likely that things have changed one way or another since then.