Small team is trying to hard fork a whole operating system and improve it. It will end up as yet another GNU Hurd - toy project without any practical use. Whats even worse they intend to GPL3 their code, so even the potentially useful code they create will remain useless for general public as it wont be possible to port it back to *BSD due to license conflict.
Why would forking mean any more work than you want?
The base system won't care.
I can run a fork all on my own, in my spare time. The weekly routine (mostly automated) goes like this: 1. Update my fork with all the changes from the original. 2. Apply my patches. 3. For those that fail, and specifically the lines that fail, do the changes manually and then do a diff to get a new complete patch. 4. Maybe code a bit on my own parts, to add a feature or fix a bug. 5. Commit/
They intend to improve security, remove "tainted" dependencies ("E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies)"). This definitely doesn't look like a small fork with minimal patching but more like a serious rewrite. They even clearly state "we are planning on implementing a completely new OS derived from several BSD implementations.".
They want to use GPL3 licensed code. This means that they can't use Linux modules that don't have that "any future version" line in the license.
If you want to know what's allowed, anything that's allowed by the GPL3 license will be allowed. And possibly a few things that aren't, but which only use subsystems, but don't depend on that.
This is no problem for me, as I prefer the AGPL3 license, and the difference from GPL3 rights isn't something that affects my work. But if you're planning to take it, repack
hopeless (Score:2)
Small team is trying to hard fork a whole operating system and improve it. It will end up as yet another GNU Hurd - toy project without any practical use. Whats even worse they intend to GPL3 their code, so even the potentially useful code they create will remain useless for general public as it wont be possible to port it back to *BSD due to license conflict.
You don't get forking, do you? (Score:2)
The smallest fork is ... a pure name change.
Why would forking mean any more work than you want?
The base system won't care.
I can run a fork all on my own, in my spare time. The weekly routine (mostly automated) goes like this:
1. Update my fork with all the changes from the original.
2. Apply my patches.
3. For those that fail, and specifically the lines that fail, do the changes manually and then do a diff to get a new complete patch.
4. Maybe code a bit on my own parts, to add a feature or fix a bug.
5. Commit/
Re:You don't get forking, do you? (Score:2)
They intend to improve security, remove "tainted" dependencies ("E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies)"). This definitely doesn't look like a small fork with minimal patching but more like a serious rewrite. They even clearly state "we are planning on implementing a completely new OS derived from several BSD implementations.".
Re: (Score:0)
That's what I don't get. Why are they going with BSD if they plan to do substantial rewrites and relicensing to create a stew of BSD/GPL code?
Why not just modify Linux and keep everything GPL? If you're going to fork BSD, keep the BSD licensing intact. Don't confuse the issues.
People who vacillate over whether to use Linux or BSD for their project will look at this and say, "We can't even tell what's allowed with Hyperbola."
Re: (Score:2)
They want to use GPL3 licensed code. This means that they can't use Linux modules that don't have that "any future version" line in the license.
If you want to know what's allowed, anything that's allowed by the GPL3 license will be allowed. And possibly a few things that aren't, but which only use subsystems, but don't depend on that.
This is no problem for me, as I prefer the AGPL3 license, and the difference from GPL3 rights isn't something that affects my work. But if you're planning to take it, repack
Re: (Score:0)