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.