I feel like by this point, in 2021, if you are a developer making contributions to "open source," and you're still getting surprised by these sorts of shenanigans, you only have yourself to blame.
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.
Much of the internet makes fun of "choosing beggar" "influencers" who want to pay people with "exposure" instead of money. Permissive licenses are the reverse: they're asking others to pay you only in "exposure" instead of money. If expect to gain any return (other than some CV padding and personal satisfaction) due to contributing to permissively licensed projects you're a sucker. Permissively licensed software is charity work. It's good, useful work in many cases, but it's not going to make you money.
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.
I thought the scare quotes around "open source" in my first statement were enough to convey that. But point taken, I'll adjust my messaging in the future.
If your company lets you sign the FSF legal papers. Most will not, and in the end you will not be able to contribute to GNU projects. It also needs weeks to clear the FSF paper work. About 1% of my users did it successfully.
> all you have to do is release a value-added component and all but cripple the community one
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).
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.
1. If a vendor distributes binary of GPLd code to "X", they can impose upon "X" that if "X" does distribute vendor's GPL code without approval, "X" would breach contract.
2. A vendor can "rent" / "lend" a binary to "X", in which case the vendor wouldn't have to share the code.
Just look at this inane spam from the netgate moderators[0]. Post at Oct 27, 2017, 12:04 AM by ivor
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.
This, like most intersections of law and software, is tricky.
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.
> 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
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.
Yup, cheap routers go this path as well[*]: you get a tarball of Linux sources, sometimes completely unchanged from the mainstream release. Keep your special sauce userspace only and you're just fine.
[*]: presuming they care about complying with licenses in the slightest, which many do not.
>very permissive 2-BSD, there's nothing to say OpnSense couldn't relicense to a proprietary license per the above.
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.
This is absolutely correct, and I did not do a good job of trying to draw the distinction I was going for: FreeBSD's 2-BSD license will remain and must be respected, but OpnSense could move their contributions to a new proprietary license which includes the core FreeBSD code.
But can you retroactively change a license? If you release v1 and v2 under GPL and then switch to a proprietary license for v3, I'm assuming v2 can still be forked, since many people now have started using that code under the license they were offered at the time?
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.
> If you release v1 and v2 under GPL and then switch to a proprietary license for v3, I'm assuming v2 can still be forked, since many people now have started using that code under the license they were offered at the time?
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.
What about legal demands on the original authors? In this case, say an end user has a copy of v2 but only in binary form, can they then legally demand the (v2) source code from the company and claim breach of contract if they refuse? AFAIK it’s a central part of the GPL to be able to request source code, and presumably especially so in the hypothetical case where you have bought it from them?
This is definitely "ask a lawyer" territory but I'd expect those demands to be seen favorably by courts: the clear intent of the GPL is that someone who is allowed to have the v2 binary is also entitled to the v2 source.
They can change it to closed source, and anyone can start a closed-source fork. The contributors I know wouldn't stick around after such an event, however.
If that's a problem for you, you could try VyOS (LGPL/GPL2/GPL3 mix) or dnxfirewall (AGPL3).
What functionality are you referring to? pfSense Plus will be what was called pfSense FE (what's loaded on your Netgate appliance). So initially it will be the exact same as pfSense CE 2.5. As it moves forward it will diverge and more more features such as API, new GUI, multi-instance management, etc.
This + all the hullabaloo around Amazon / Elastic should really remind developers to carefully consider the license that they apply to their software.
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.
It also significantly deters people from ever modifying that code and using it commercial applications, even if they are willing to open it up sometime in the future.
(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...)
If you want a great firewall, try OpenBSD. That's where pf(4) came from, and is actually maintained. Not even FreeBSD has an up-to-date version. Also despite being the basis for the success of their product, and in their product name, pfsense/Netgate and its CEO "gonzo" have been actively hostile towards to the OpenBSD project and developers for many years.
The FreeBSD implementation of pf is derived from OpenBSD 4.5. It was modified to be capable of running in multi-threaded kernel. The implication of it not being maintained isn't quite right.
pf in FreeBSD is still maintained, but it's not the pf from OpenBSD that everyone knows and loves.
OpenBSD kept making snide remarks at FreeBSD for not keeping the pf codebase in sync. FreeBSD also didn't import the newest version the last time they synced because a slightly older version was faster.
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.
I ran PfSense for a year or two and thought it was an ok product. Then I started looking for the sources because I wanted to fix some bugs and discovered it's not an actual open source project so I was dismayed and went back to using another product. I'll have to check out opnsense as there are quite a few things I'm not doing as well as I'd like in my current network.
I'm currently evaluating pfSense, mostly due to it supporting WireGuard in the kernel level and having a good adblocker plugin. I run the router in a lab setting, so now it's the time to still change the os if needed.
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.
I recently threw https://www.ipfire.org/ onto an old PC to cover router duties for a small biz that had it's current old consumer Netgear die. I was really impressed with Ipfire. Up and running in about 20 minutes.
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).
The link says: "You cannot build pfSense®™ 2.4.x from source code. No, not even with the official tools - those will just sabotage you. The repository claimed to be "FreeBSD src with pfSense changes" does not contain the source code of the kernel shipped with pfSense®™ 2.4.x, and other changes done to FreeBSD code are also being selectively ommited from that repository." It's from a few years ago so the situation may have changed.
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 haven't tried it, but this doesn't seem to be the case anymore. Notably, [0] is clearly a pretty up-to-date copy of the stable/12 that they're almost certainly running given some of the recent direct commit references (e.g., patch pulled from [1]) and that it has a wireguard kmod that hasn't actually been ported to this branch upstream.
I would guess that pfsense/pfsense should be able to build it, but you probably won't have any luck on !FreeBSD/pfSense.
I'm not sure about the kernel alone, but the last time I tried to build the entire pfSense system (a few years ago, but still in the 2.4.x era) using the build.sh in the pfsense/pfsense repo it fell apart due to references to Netgate internal package repositories with no information on how to replicate these.
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 did see someone linked documentation for how they did a build recently in the pfSense subreddit when this same article was posted there, so I guess it is in fact possible, but the process was certainly nowhere close to straightforward.
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.
Damn. I talked us into getting netgate appliances because I was led to believe that pfsense was open source.
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.
I just glanced at their contributor docs. It seems they get around providing a full build by using their patch system. The changes must be submitted via PR then referenced in a running pfsense build. Seems like a painfully slow workflow, but I could be wrong (never tried it myself).
And it's just a port of the kernel wg(4) driver from OpenBSD, which was contributed by the Wireguard developers. It shipped in the OpenBSD 6.8 release in October. FreeBSD hasn't included it in a release yet.
The author calling pfsense, "overpriced," has never actually purchased business grade network equipment. Netgate devices are remarkably affordable for what you pay for them in comparison to most of their competitors.
Thanks for letting us know, I was considering pfSense/NetGate in the future and now I can guarantee you I will never bother. Maybe I will look into OpenWrt devices instead.
I researched OPNSense vs pfSense a year or so ago when I was making a choice migrating from my Linux-based firewall. I ended up chosing pfSense, because I thought it offered a better support. I regret now, especially that I only recently learned that OPNsense offers a free ET Pro (Telemetry)[1] subscription for Suricata, which is otherwise available to pfSense on a paid basis only.
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.
Stuck at home for Covid and was looking for projects to make my home network better. Sold my Ubiquiti security appliance and put an Opnsense router in its place. Aside from services that aren’t well documented, I’ve been able to set it up enough that I’d consider dumping my Cisco equipment in the office in favor of this as our firewall.
I looked at pfsense and got a weird vibe from their site.
This is airing dirty laundry from literally years ago. I actually don't know what the current situation is, but it's lear that the argument presented at the github link is four years old now.
It's quite likely that things have changed one way or another since then.
Well that's unfortuante, although maybe they should update their website because as of 26.1.2021 at 2:58 AM it still says "pfSense® - World's Most Trusted Open Source Firewall". My last job used their firewalls all over the place.
This repo was created and last updated 3 years ago, the pfSesnse FreeBSD repo was last updated 19 hours ago (as of 09:34 UTC) I don't think this is relevant anymore but I don't have time to try to build / test it at the moment.
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.