cross-posted from: https://lemmy.ndlug.org/post/1401792

This report summarizes insights from the inaugural 2024 Open Source Software Funding Survey, a collaboration between GitHub, the Linux Foundation, and researchers from Harvard University. The objective of the survey was to better understand how organizations fund, contribute to, and otherwise support open s ource software.

Survey Respondents 159 respondents to the survey collectively contribute $1.7 billion (2023 USD) in annual value to open source. 86% comes in the form of contribution labor by employees. Extrapolating survey to all organizations active in open source Using the survey responses on contribution, we estimate that organizations contribute $7.7 billion annually to OSS.

This report summarizes insights from the inaugural 2024 Open Source Software Funding Survey, a collaboration between GitHub, the Linux Foundation, and researchers from Harvard University. The objective of the survey was to better understand how organizations fund, contribute to, and otherwise support open s ource software.

Survey Respondents 159 respondents to the survey collectively contribute $1.7 billion (2023 USD) in annual value to open source. 86% comes in the form of contribution labor by employees. Extrapolating survey to all organizations active in open source Using the survey responses on contribution, we estimate that organizations contribute $7.7 billion annually to OSS.

Bcachefs lead developer Kent Overstreet published a Patreon post this evening entitled "Trouble in the kernel" where he explained:

"TLDR: the future of bcachefs in the kernel is uncertain, and lots of things aren't looking good.

Linus has said he isn't accepting my 6.13 pull request, per "an open issue with the CoC board", and at this point I have no idea what's going on with the CoC board. I, for my part, have felt for quite some time that there are issues about our culture and the way we do work that need to be raised, and that hasn't been going anywhere - hence this post."

It appears that the source of this violation can be found in this Linux kernel mailing list thread.

Yes, this nifty workflow wonder is finally able to automatically tile newly opened windows based on the currently active tiling layout (and as you may sick of me re-emphasising: you can switch between different layouts ad-hoc, and create and save your own).

Windows auto-tile to the best vacant slot in the layout. But what’s ‘best’? Tiling Shell developer Domenico Ferraro says this will be the ‘vacant tile nearest to the center of the screen’.

With the addition of automatic tiling you no longer need to tile windows manually.

I saw plenty of efforts that aim to create a Linux distribution for non-enthusiasts, for people who just want to use their computers, and not care about the details - A Desktop for All on the GNOME blog, most recently. While I commend the effort, my own experience is that these efforts are futile, and start off from a fundamentally wrong premise: that people are willing (let alone wanting) to manage their own operating systems.

...

My family is using Linux because that’s the system I can maintain for them. Apart from my Dad, they never installed Linux, and never will. They don’t install software, they don’t upgrade, they don’t change settings either. All of that is something I do for them. And to do so effectively, I need a distribution I am familiar with, one that is also flexible enough to fine-tune for every member of the family, because they prefer fundamentally different things!

...

The common pattern between all these three is that neither of them maintains their own systems. I do. As such, how beginner friendly the distribution is, is meaningless. The users of the system don’t care, they’ll never see those parts. They’ll have a preconfigured system maintained by someone else, and that’s exactly what they want. To make this work, I’m using distributions I am familiar with. For my parents, that’s Debian, because I was a Debian person when their systems were installed. For my Wife, it is NixOS, because I’m a NixOS person now. For the Twins, it will likely be NixOS too.

A new patch series posted today to the Linux kernel mailing list would block kernel modules/drivers from TUXEDO Computers from accessing GPL-only symbols in the kernel.

TUXEDO Computers maintains a set of kernel drivers currently out-of-tree for their various laptops for additional functionality around power profiles, keyboard backlight controls, WMI, sensor monitoring, the embedded controller, and other functionality. They have said they want to eventually mainline these drivers but in the name of allowing for rapid hardware support they maintain them out-of-tree and ship them with their Ubuntu-based TUXEDO OS and also have the driver sources available via GitLab.

The issue at hand though is that these kernel drivers marked as GPLv3+ and that conflicts with the upstream Linux kernel code licensed as GPLv2. There was a commit to change the driver license from GPLv3 to GPL(v2) but was reverted by TUXEDO Computers on the basis of "until the legal stuff is sorted out."

Update: TUXEDO Computers Relicenses Some Of Their Drivers To GPLv2

As of yesterday, TUXEDO Computers has now been able to re-license their driver consisting of fully in-house code from GPLv3 to GPLv2+. These are the TUXEDO Computers drivers where it's all written by TUXEDO employees and not having to worry about code from any third-party developers or other vendors.

The gxtp7380, ite_8291, ite_8291_lb, ite_8297, stk8321, tuxedo_compatibility_check, tuxedo_nb02_nvidia_power_ctrl, and tuxedo_tuxi drivers are the initial ones able to be moved to the GPLv2+ licensing for satisfying upstream Linux kernel developers. Moving the other drivers to GPLv2+ will take longer due to needing to check with the associated parties that contributed to those drivers.

Whether you just downloaded Firefox, or you’ve been with us since the beginning, you are a vital part of helping us make the internet a better place. Here's a sneak peak at what's coming next!

If you love exploit mitigations, you may have heard of a new system call named mseal landing into the Linux kernel’s 6.10 release, providing a protection called “memory sealing.” Beyond notes from the authors, very little information about this mitigation exists. In this blog post, we’ll explain what this syscall is, including how it’s different from prior memory protection schemes and how it works in the kernel to protect virtual memory. We’ll also describe the particular exploit scenarios that mseal helps stop in Linux userspace, such as stopping malicious permissions tampering and preventing memory unmapping attacks.

Memory sealing allows developers to make memory regions immutable from illicit modifications during program runtime. When a virtual memory address (VMA) range is sealed, an attacker with a code execution primitive cannot perform subsequent virtual memory operations to change the VMA’s permissions or modify how it is laid out for their benefit.

...

mseal digresses from prior memory protection schemes on Linux because it is a syscall tailored specifically for exploit mitigation against remote attackers seeking code execution rather than potentially local ones looking to exfiltrate sensitive secrets in-memory.

...

From the disallowed operations, we can discern two particular exploit scenarios that memory sealing will prevent:

• Tampering with a VMA’s permissions. Notably, not allowing executable permissions to be set can stop the revival of shellcode-based attacks.
• “Hole-punching” through arbitrary unmapping/remapping of a memory region, mitigating data-only exploits that take advantage of refilling memory regions with attacker-controlled data.

...

There are likely many other use cases and scenarios that we didn’t cover. After all, mseal is the newest kid on the block in the Linux kernel! As the glibc integration completes and matures, we expect to see improved iterations for the syscall to meet particular demands, including fleshing out the ultimate use of the flags parameter.

Drivers passing through San Francisco have a new roadside distraction to consider: billboards calling out businesses that don't cough up for the open source code that they use.

The signs are the work of the Open Source Pledge – a group that launched earlier this month. It asks businesses that make use of open source code to pledge $2,000 per developer to support projects that develop the code. So far, 25 companies have signed up – but project co-founder Chad Whitacre wants bigger firms to pay their dues, too.

Over the past 3 years the pace of development in APS has steadily fallen off as maintainers including myself have moved on to other things. I no longer have time and motivation to dedicate to this project, and in the absence of significant external contributions there is no-one else I can offer the project's stewardship to.

To that effect, I will be archiving the repository on Monday, October 14th 2024 at 7AM GST. In the situation that a serious and viable fork emerges, I will help them as much as I can with the transition. The criteria for what counts as "serious and viable" is entirely vibes-driven for now, and may become more specific in the future. In case I determine that a fork does not live up to my made up standard, they will have to come up with a slightly more creative name than "Android Password Store" and watch low 4 figures of cash wither away in OpenCollective's bank account.

Pull request #10974 introduces the @bitwarden/sdk-internal dependency which is needed to build the desktop client. The dependency contains a licence statement which contains the following clause:

You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.

This violates freedom 0.

It is not possible to build desktop-v2024.10.0 (or, likely, current master) without removing this dependency.

We are excited to announce the launch of a dedicated fund aimed at providing financial assistance to Free/Libre and Open Source Software (FOSS/FLOSS) projects globally, with an annual commitment of $1 million. I will use the FOSS acronym in this post hereafter.

...

For us, FLOSS/fund is about hacker goodwill, reciprocity, and common sense business strategy. We invite you to apply for funding. If you would like to understand the motivations behind this, a bit of storytelling lies ahead.

...

To initiate and give this experiment a serious shot, FLOSS/fund will accept funding requests from projects through a publicly accessible funding.json file hosted on their respositories or websites. This file is not meant to convey everything there is to know—an impossible task—but to solicit interest and communicate enough to ensure discoverability which would not be possible otherwise. Refer to the funding.json docs to know more.

Applications that come through to the FLOSS/fund will be indexed and published on the dir.floss.fund directory / portal, making them publicly discoverable by anyone interested in supporting projects. This is going to be an interesting experiment. Fingers crossed!