> • Linux kernel forcing adaption of DRM, including HDCP.
This links to a Linux kernel patch which allows but does not require turning on HDCP in video output. Is that really so bad?
> • Linux kernel proposed usage of Rust (which contains freedom flaws
“freedom flaws” here means a Firefox-like trademark policy. This does not really affect software freedom in the traditional sense?
That’s not the point though. These kinds of people just consistently seek conflict and are bending the reality to fit their narrow field of view.
And yet, they don’t see why no one use their projects.
Anyway, this article was probably written on a computer booted with a proprietary bios, typed on a keyboard with a proprietary firmware, a proprietary CPU microcode and what else.
There’s no code base to “hard fork” to sell as their own nor really something to make outrage of so they don’t care though.
In reality, that’s more of a religious issue than anything else. Fingers are pointed at those that are not extremist enough for their taste.
Real freedom is letting people do what they want with software. Most so-called free software licenses are actually really restrictive and absolutely not freedom inducing.
I guess it’s very important to create confusion not to say exclusion and throw around licences so complex that you actually almost require a lawyer to understand if you can use the software or not so organizations that produce nothing of real importance can exist and preach the “real freedom”.
Ah ok, let's give up then.
This seems especially silly in light of the fact that the patch doesn't even implement HDCP -- HDCP support is typically a hardware function, and the patch is providing a common interface for drivers to expose that functionality. HyperbolaBSD's description of the patch as "forcing adaptation of DRM" is a wild mischaracterization of the facts.
There was nothing "hard" about this fork, it's funny how a few GNU aficionados think that deleting a few freely redistributeable firmware files constitutes significant "new code" contributions.
It's in the same vein as projects like "libertybsd" or "libreboot"-- misleading people into thinking they are anything but a agenda driven project, onboarding like-minded and inexperienced new users, meanwhile offloading most (if not all) the support/technical burden on other communities.
Neither the BSD or GPL license families grant a trademark license.
Therefore, Hyperbola should immediately cease distributing all software that doesn't have an explicit "You may use the name of this software for whatever you like" license and where the original authors might want to go into business with that software, on the grounds that such software is non-free, just the same as it would judge software with no copyright license as non-free. That Rust and Firefox have trademark policies does not make them less free than un-trademark-licensed names anymore than having a BSD license makes code less free than unlicensed code.
Unless you register, you cannot sue for damages and you are limited to state courts.
So how do you prevent people from using your mark?
You apply for an injunction. You would have to do this in every state where you want to enforce the mark. If you target multiple states, you would likely need multiple lawyers. How many of those free software authors will want to pay for this legal expense?
Until you succeed in getting your injunctions, and there is no guarantee you will succeed, there is no incentive for someone to stop using an unregistered mark. Whatever damage they cause cannot be recovered under a claim based on trademark law.
It's quite clear that Mozilla isn't interested in suing Hyperbola or any other free software distro for being a distro and doing distro things, and that in the worst case, they'd send a nice message first and Hyperbola could choose to discontinue distributing Firefox and Rust. Yet Hyperbola wants to take the "explicit permission" principle to an extreme and discontinue distributing them now, proactively. They should be consistent and cease distributing everything else.
I've been hearing this argument for 20 years now. What's different today?
About 300 system calls.
The opposition to Rust is also strange. Yes, the trademark restriction is annoying, but it's not fatal: the existence of projects like Pale Moon and Waterfox show that forking projects in the presence of trademark restrictions is viable. (I still think Mozilla is really shitty for applying these restrictions in the first place though.)
Technically, Rust is a good thing. A way to structurally prevent memory safety defects is a major advance that occurs only rarely. Rust is the only game in town for memory safety if you also want low-level control over the machine. Giving that up over a trademark is just luddism.
> Grsec is no longer free software
I really hate how various corporate forces in the Linux world have made is socially unacceptable to sue people out of existence for blatant GPL violations.
I doubt that they regard that as a flaw; no shared cache is an effective mitigation against cache-based attacks (cache poisoning or information leaks).
I don't know why they waited so long to do this. While it's a good choice to switch to the OpenBSD kernel, I'm not quite sure if doing it now makes sense. This involves recompiling everything, probably a new toolchain, plus adapting software to work with the new kernel, or even worse: A Linux compatibility layer for existing software / drivers.
This doesn't seem like the right time to move to a new kernel for an existing Linux distro. They might as well have created a new Hyperbola from scratch from the side or started with OpenBSD from the start.
A bit ironic for a project that claims it's more stable than Linux…
If they have any desire to be good free software citizens they'd release the OpenBSD modifications under the ISC license or something else suitably copyfree so that OpenBSD can use those modifications.
Also, I fail to see how a copyfree-licensed binary blob is non-free. Sometimes code only exists as binary code (i.e. if it's been written by hand). Whether or not that's the case here is beyond my skillset/expertise, but it seems silly to declare code to be inherently non-free if it's not human-readable, actual license terms be damned. As long as you have the freedom to use it / modify it / distribute it (verbatim or modified) / etc., then that's free.
Like, if someone wrote a device driver in Brainfuck, I probably wouldn't be able to make sense of it, either, but that doesn't make that Brainfuck code inherently non-free; it just means I don't know how to read Brainfuck code.
Then what's this Linux subsystem that Windows ships?
> Linux ABI is large and fast-evolving and underdocumented
You don't have to keep up with the latest ABI. You don't need to match tip-of-tree. You only need to match some version of Linux that programs still target, and that version can be pretty old, since enterprise customers scream bloody murder when you force them up upgrade kernels to run new programs.
Using a VM for WSL means that it'll never be possible to write a program that's simultaneously a good win32 GUI citizen and a Unix API user. WSL1 (AFAIK) didn't allow this use case, but there was a path to get there. There's no path from a VM to a native USER32 process.
The bright side is that at least Cygwin won't die. Cygwin allows for precisely this use case.
You might want to look up all of the reasons why they made this choice, including but not limited to the amazing impedance mismatch between Linuxy I/O operations and Windowsy I/O operations.
Running the Linux kernel in a VM and doing all sorts of integration tricks ends up being a better end-user experience, even if it's not as cool and clever as what WSL0 and WSL1 are.
Yeah, this right here is the most problematic. It's fairly easy to implement the proactor pattern of the Windows asynchronous IO APIs using reactor implementations common on Linux, the opposite is not so true. Seeing as this is a fundamental design choice of the NT kernel itself, and not just the Win32 subsystem it's rather difficult to properly emulate the Linux API's without a similar amount of indirection that a hypervisor layer adds.
Could you provide a link to this?
The point of WSL isn't to just run some Linux code on Windows. You've been able to do that for literally decades. The point is to create a tightly integrated environment that gives you Linux and Windows views onto the same workspace and that makes Linuxy and Windows processes peers.
Using a VM here feels like a "safe" and "sustainable" uninspired corporate choice that gives Windows a checkbox feature without expanding the bounds of what's possible. You can tell me all day that switching from innovation to crank-turning is right for the business, but I personally want nothing to do with crank-turners.
But again, the problem is that Microsoft wanted to have binary compatibility. That would mean containers w/ Linux ABI emulation, or a proper VM. Well, Linux ABI emulation has been tried by many people:
- Sun (twice)
- Joyent (once, based on earlier tech from Sun)
- Microsoft (WSL1)
- probably others
I'm not a Windows developer but I have a Windows laptop that I'd like to be able to run linux on and WSL2 scratches that itch, so your complaint doesn't register for me.
 National Novel Generation Month
But yes, I was referring precisely to WSL2 being VM-based.
It may be a less pure design, but it solves my needs better than anything else out there.
Yeah, and WSL1 did not.
It's now a full Linux kernel running in a hypervisor.
BSD ideology will only accept permissive licenses. Anything less pure is unwelcome.
Programmers have to eat; permissive licensing is the best compromise between openness and needing to make a living. History has shown that eventually the code comes out rather than being socked away in proprietary hell.
It's also true that Linux has gotten contributions from companies like Facebook (and Netflix?) that are not redistributing Linux itself and so are not actually under any compulsion to release sources.
I've seen enough cases of private contributions to BSD code not getting released, even when they're clearly not a competitive advantage anymore, that I don't think waiting it out is reliable. There's a particular vendor product we used at my last company that was based on an extension to some FreeBSD kernel code. In the next version, they switched to a userspace app, it sucked, and I'm pretty sure they never released their old kernel implementation. (In fact there are plenty of well-known cases of license-violating private contributions to GPL'd code being a pain to compel through the legal process.)
When people talk about reforming copyright there is usually a comment about GPL with a standard answer: copyright escrow. If we just have rules in places that guaranties that the code eventually comes out rather than being socked away in properietary hell then 99% of the purpose of copyleft has been served.
Last Friday in tech news there was an entry about a deal between a DRM company and a game company that expires, so "owners" of the game can no longer install the game. Proprietary code for games do not usually come out, so there is some real worry that the games are now closed down forever.
I wonder how supportive Juniper, Comcast, EMC, and Netflix would be to copyright escrow.
Oh wait... they do!
- async sendfile
- rewrite of the pbuf system
- unmapped mbufs
- kernel TLS
- RACK TCP
- BBR TCP
- TCP high precision timer system (TCP pacer)
- various NUMA improvements, which allow us to stream in excess of 200Gb/s of TLS encrypted video traffic from a single server
- Metric tons of fixes
Contributing stuff back makes it easier to work with other folks, and makes our jobs easier. We merge from upstream FreeBSD-current every few weeks. The smaller the diff we carry forward, the easier our jobs are.
It would be nice in this kind of threads if both sides were just honest in presenting how things work. Companies will decide on contributing back BSD code based on competitive advantages of doing so. It is a business decision. They can reducing costs by having the code maintained by upstream and reduce integration costs, or they can get advantage over their competitors by keeping the code proprietary.
I see similar discussing when companies talk about paying taxes. The press releases will talk about contributing back to society and being responsible citizen, while at the same time employing lawyers who do "tax management" in order to pay as little tax as possible. It is true that they do contribute back with numbers that looks impressive, and paying some taxes is easier than paying no taxes, but a honest description would call it a calculated business decision that balance benefits and drawbacks between compliance and tax avoidance.
i’m not sure that’s exactly true is it? 
or at least it seems quite murky (case-by-case, state-by-state) 
The difference here is Netflix can choose which part to contribute back. In most cases the CDN work is not their core competitive advantage, their Quality Content are. Which means Netflix can contribute back everything they have done.
I'm still bitter at how they murdered KHTML.
(Before someone comments "But KHTML is LGPL!": I know. That's the point. The GPL doesn't have these problems. The LGPL is too weak to be meaningful.)
Murdered? Thanks in large part to the work Apple did to transform KHTML into WebKit, WebKit and its derivatives (like Blink) have utterly dominated the browser marketplace. I have a hard time reconciling your characterization of Apple's action with the facts.
Yes, we know that a certain subset of Free Software zealots prefer preventing non-Free software to promoting Free software.
> What happened wasn't, though.
Why exactly is the creation of a set of F/OSS browser engine cores which have essentially completely extinguished the proprietary cores to dominate the space not “fine”?
Apple forked one in a hostile fashion, and later used it to release proprietary software.
A substantial volume of web browsers, including the largest two (Chrome, Safari), are proprietary software, directly because of this.
It made the WWW less free, and hurt users.
I guess you are the 0.0001% of the internet who consider Chrome and Safari to be proprietary software, when it has an Open Source version freely available.
Not that I'm entirely against the general idea, I think it's scary how common corporate-ware is getting these days compared to early Linux. For example, I'd much prefer a language that's not controlled by a commercial entity (and without a "BDFL", while we're at it), preferably with several implementations for example.
I'm also a little confused about their problems with Rust (https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...) Firefox also has the same trademark issues, but there are multiple forks/distributions of it with the trademarked material removed. It seems like a petty thing to bring up on an "about" page.
Also, it feels weird that they complain that linux is including some things they don't like (e.g. HDCP), but at the same time just gloss over that the BSDs are they base of many proprietary products where you can't get the source at all. I mean, I hate DRM and things like HDCP as much as anyone, but it just feels like an _off_? argument?
That said, I don't understand how that is in violation of freedom 3. It is just saying, "if you want to redistribute it, don't call it rust so that nobody gets confused and we don't get stuck supporting your fork." I think that there is a higher barrier for something like firefox due to the graphics, but Rust only has a simple copy and paste. And if your whole purpose is to hard fork, why is that a problem?
I think that the requirement for internet access to build might be harder for Hyperbola's goals, but shrug
> You are correct that we intended the trademark to apply when
> distributing a package or other binary called "Rust" -- and in
> particular that if modifications are made, then we would expect a
> trademark request outlining the sorts of changes being made (as the
> policy notes though, we are inclined to accept such a request).
This thread in the project's (hyperbola) issue tracker seems silly and needlessly exclusive, given what seems to be a relatively minor restriction: https://issues.hyperbola.info/index.php?do=details&task_id=7...
It's strange, isn't it? The Sony PlayStation applies HDCP to some (all?) game content, and you can't disable it given its OS is based on FreeBSD, which isn't copyleft, so they don't have to release the source. Whereas, if it were hypothetically based on the copyleft kernel Linux, then you might stand a chance of disabling HDCP and recompiling it. Quite unlikely in practice though.
No. It's an endorsed distribution of Linux by the FSF. The BSD fork will need to be evaluated by the FSF too.
Has this ever happened before
The kernels are FreeBSD but userland is all GNU as far as I understand it?
I'm not sure how well supported they are, or if anyone ever used them beyond proof of concept
Hyperbola was based on Arch but was trying to use Xenocara (https://en.wikipedia.org/wiki/Xenocara) as the X display server
Seems like an enormous effort for very little benefit.
But at least Terry actually went out and wrote his own OS (in his own JIT-compilable programming language!) instead of pretending that stripping binary blobs out of a BSD-licensed codebase and slapping the GPL on it counts as a "hard fork" or is in any way being a good free software citizen.
That is: it's all the ridiculousness, but with none of the technical merit.