In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

Bram Moolenaar was Vim's creator/maintainer/benevolent-dictator for life. Early this morning his family shared sad news on the Vim-announce Google Group. "It is with a heavy heart that we have to inform you that Bram Moolenaar passed away on 3 August 2023." Moolenaar was 62 years old, and died from "a medical condition that progressed quickly over the last few weeks."

"Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of."

Anyone who's used Vim has seen evidence of Moolenaar's generosity. "Vim is Charityware," Moolenaar wrote in its pioneering license. "You can use and copy it as much as you like, but you are encouraged to make a donation for needy children in Uganda." Moolenaar pioneered the concept of charityware decades ago, and also helped to popularize its adoption. To this day Vim users can still view the license by typing the command :help Uganda or :help ICCF. And Vim's sponsor FAQ notes that "Each registered Vim user and sponsor who donates at least 10 euro will be able to vote for new features."

Moolenaar's personal web site also includes photos from his travels around the world, and YouTube has some videos of talks and interviews with Moolenaar.

He was still committing changes to Vim up until a month ago.

In the comments below long-time Slashdot reader bads shares a link to a post from long-time Vim contributor Christian Brabandt : Bram was a great leader to the Vim community and I really enjoyed working with him over the past years, since I became involved with the development of Vim almost 20 years ago.

Bram was of great inspiration in creating a great community, helping people with his charity and he was a great mentor. And now he left too soon. We lost a great leader and I regret never having met him in person.

However to all of the community: I will continue and I hope all of the other contributors will also keep up the good work. I do have access to the Vim homepage and the Vim organization (not sure if all the rights, but I am sure we will work on the details in the near future...) I hope together we will be able to continue successfully.

Meta on Wednesday introduced its open-source AI tool called AudioCraft that will help users to create music and audio based on text prompts. Reuters reports: The AI tool is bundled with three models, AudioGen, EnCodec and MusicGen, and works for music, sound, compression and generation, Meta said. MusicGen is trained using company-owned and specifically licensed music, it added. From Meta's press release: The AudioCraft family of models are capable of producing high-quality audio with long-term consistency, and they're easy to use. With AudioCraft, we simplify the overall design of generative models for audio compared to prior work in the field -- giving people the full recipe to play with the existing models that Meta has been developing over the past several years while also empowering them to push the limits and develop their own models.

AudioCraft works for music, sound, compression, and generation -- all in the same place. Because it's easy to build on and reuse, people who want to build better sound generators, compression algorithms, or music generators can do it all in the same code base and build on top of what others have done. Having a solid open source foundation will foster innovation and complement the way we produce and listen to audio and music in the future. With even more controls, we think MusicGen can turn into a new type of instrument -- just like synthesizers when they first appeared.

Some of the largest tech companies, including Adobe, Apple, Autodesk, and Nvidia, have announced the Alliance for OpenUSD (AOUSD) to promote and develop Pixar's 3D Universal Scene Description technology. From the Linux Foundation: The alliance seeks to standardize the 3D ecosystem by advancing the capabilities of Open Universal Scene Description (OpenUSD). By promoting greater interoperability of 3D tools and data, the alliance will enable developers and content creators to describe, compose, and simulate large-scale 3D projects and build an ever-widening range of 3D-enabled products and services. Created by Pixar Animation Studios, OpenUSD is a high-performance 3D scene description technology that offers robust interoperability across tools, data, and workflows. Already known for its ability to collaboratively capture artistic expression and streamline cinematic content production, OpenUSD's power and flexibility make it an ideal content platform to embrace the needs of new industries and applications.

The alliance will develop written specifications detailing the features of OpenUSD. This will enable greater compatibility and wider adoption, integration, and implementation, and allows inclusion by other standards bodies into their specifications. The Linux Foundation's JDF was chosen to house the project, as it will enable open, efficient, and effective development of OpenUSD specifications, while providing a path to recognition through the International Organization for Standardization (ISO). AOUSD will also provide the primary forum for the collaborative definition of enhancements to the technology by the greater industry. The alliance invites a broad range of companies and organizations to join and participate in shaping the future of OpenUSD.

Earlier this week, Meta announced it has teamed up with Microsoft to launch Llama 2, its "open-source" large language model (LLM) that uses artificial intelligence to generate text, images, and code. In an opinion piece for The Register, long-time ZDNet contributor and technology analyst, Steven J. Vaughan-Nichols, writes: "Meta is simply open source washing an open but ultimately proprietary LLM." From the report: As Amanda Brock, CEO of OpenUK, said, it's "not an OSI approved license but a significant release of Open Technology ... This is a step to moving AI from the hands of the few to the many, democratizing technology and building trust in its use and future through transparency." And for many developers, that may be enough. [...] But the devil is in the details when it comes to open source. And there, Meta, with its Llama 2 Community License Agreement, falls on its face. As The Register noted earlier, the community agreement forbids the use of Llama 2 to train other language models; and if the technology is used in an app or service with more than 700 million monthly users, a special license is required from Meta. Stefano Maffulli, the OSI's executive director, explained: "While I'm happy that Meta is pushing the bar of available access to powerful AI systems, I'm concerned about the confusion by some who celebrate LLaMa 2 as being open source: if it were, it wouldn't have any restrictions on commercial use (points 5 and 6 of the Open Source Definition). As it is, the terms Meta has applied only allow some commercial use. The keyword is some."

Maffulli then dove in deeper. "Open source means that developers and users are able to decide for themselves how and where to use the technology without the need to engage with another party; they have sovereignty over the technology they use. When read superficially, Llama's license says, 'You can't use this if you're Amazon, Google, Microsoft, Bytedance, Alibaba, or your startup grows as big.' It may sound like a reasonable clause, but it also implicitly says, 'You need to ask us for permission to create a tool that may solve world hunger' or anything big like that." Stephen O'Grady, open source licensing expert and RedMonk co-founder, explained it like this: "Imagine if Linux was open source unless you worked at Facebook." Exactly. Maffulli concluded: "That's why open source has never put restrictions on the field of use: you can't know beforehand what can happen in the future, good or bad."

The OSI isn't the only open-source-savvy group that's minding the Llama 2 license. Karen Sadler, lawyer and executive director at the Software Freedom Conservancy, dug into the license's language and found that "the Additional Commercial Terms in section 2 of the license agreement, which is a limitation on the number of users, makes it non-free and not open source." To Sadler, "it looks like Meta is trying to push a license that has some trappings of an open source license but, in fact, has the opposite result. Additionally, the Acceptable Use Policy, which the license requires adherence to, lists prohibited behaviors that are very expansively written and could be very subjectively applied -- if you send out a mass email, could it be considered spam? If there's reasonably critical material published, would it be considered defamatory?" Last, but far from least, she "didn't notice any public drafting or comment process for this license, which is necessary for any serious effort to introduce a new license."

An anonymous reader quotes a report from ZDNet: Meta, formerly known as Facebook, is set to release a commercial version of LLaMA, its open-source large language model (LLM) that uses artificial intelligence (AI) to generate text, images, and code. LLaMA, which stands for Large Language Model Meta AI, was publicly announced in February as a small foundational model, and made available to researchers and academics. Now, the Financial Times is reporting that Meta is prepared to release the commercial version of the model, which would enable developers and businesses to build applications using the foundational model.

Since it's an open-source AI technology, commercial access to LLaMA gives businesses of all sizes the opportunity to adapt and improve the AI, accelerating technological innovation across various sectors and potentially leading to more robust models. Meta's LLaMA is available in 7, 13, 33, and 65 billion parameters, compared to ChatGPT's LLM, GPT-3.5, which has been confirmed to have 175 billion parameters. OpenAI hasn't said how many parameters GPT-4 has, but it's estimated to have over 1 trillion parameters -- the more parameters, the better the model can understand input and generate appropriate output.

Though open-source AI models already exist, launching Meta's LLaMA commercially is still a significant step, due to it being larger than many of the available open-source LLMs on the market, and the fact that it is from one of the biggest tech companies in the world. The launch means Meta is directly competing with Microsoft-backed OpenAI and Google, and that competition could mean significant advancements in the AI field. Closed or proprietary software, like that used in OpenAI's ChatGPT, has drawn criticism over transparency and security.

Long-time Slashdot reader Amiga Trombone shares a report from Phoronix: With Red Hat now restricting access to the RHEL source repositories, AlmaLinux and other downstreams that have long provided "community" rebuilds of Red Hat Enterprise Linux with 1:1 compatibility to upstream RHEL have been left sorting out what to do. Benny Vasquez, Chair of the Board for the AlmaLinux OS Foundation, wrote in a blog post yesterday: After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be Application Binary Interface (ABI) compatible*.

We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL in response to our community's needs, to the extent it is possible to do, and such that software that runs on RHEL will run the same on AlmaLinux.

For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of "bug-for-bug compatibility" with Red Hat, and that means that we can now accept bug fixes outside of Red Hat's release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream."

Steven Vaughan-Nichols writes via ZDNet: I'd been waiting for Oracle to throw its hat into the ring for the Red Hat Enterprise Linux (RHEL) Linux source-code fight. I knew it was only a matter of time. On July 10, Oracle's Edward Screven, chief corporate architect, and Wim Coekaerts, head of Oracle Linux development, declared: "IBM's actions are not in your best interest. By killing CentOS as a RHEL alternative and attacking AlmaLinux and Rocky Linux, IBM is eliminating one way your customers save money and make a larger share of their wallet available to you."

In fact, Oracle now presents itself as an open-source Linux champion: "Oracle has always made Oracle Linux binaries and source freely available to all. We do not have subscription agreements that interfere with a subscriber's rights to redistribute Oracle Linux. On the other hand, IBM subscription agreements specify that you're in breach if you use those subscription services to exercise your GPLv2 rights." As of June 21, IBM no longer publicly releases RHEL source code -- in short, the gloves are off, and the fight's on. But this is also just the latest move in a fight that's older than many of you. [...]

Mike McGrath, Red Hat's vice president of core platforms, explained why Red Hat would no longer be releasing RHEL's code, but only CentOS Stream's code, because "thousands of [Red Hat] people spend their time writing code to enable new features, fixing bugs, integrating different packages and then supporting that work for a long time ... We have to pay the people to do that work." That sentiment is certainly true. But I also feel that Oracle takes the worst possible spin, with Screven and Coekaerts commenting: "IBM doesn't want to continue publicly releasing RHEL source code because it has to pay its engineers? That seems odd, given that Red Hat as a successful independent open source company chose to publicly release RHEL source and pay its engineers for many years before IBM acquired Red Hat in 2019 for $34 billion."

So, what will Oracle do now? For starters, Oracle Linux will continue to be RHEL-compatible through RHEL 9.2. After that release -- and without access to the published RHEL source code -- there are no guarantees. But Screven and Coekaerts suggest that "if an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem." As for Oracle Linux's code: "Oracle is committed to Linux freedom. Oracle makes the following promise: as long as Oracle distributes Linux, Oracle will make the binaries and source code for that distribution publicly and freely available. Furthermore, Oracle welcomes downstream distributions of every kind, community, and commercial. We are happy to work with distributors to ease that process, work together on the content of Oracle Linux, and ensure Oracle software products are certified on your distribution."

America's Federal Trade Commission is soliciting public comments on the business practices of cloud computing providers, trying to understand security risks and competitive dynamics. (Questions include "To what extent are particular segments of the economy reliant on a small handful of cloud service providers and what are the data security impacts of this reliance?") They've already received dozens of comments (including one from Red Hat).

But there's also three questions about open-source software:


"To what extent do cloud providers offer products based on open-source software?"

- "What is the impact of such offerings on competition?"

- "How have recent changes to the terms of open-source licenses affected cloud providers' ability to offer products based on open-source software?"


This has drawn a response from the Free Software Foundation — and they're urging others to join in. "Since it isn't every day that the FTC solicits public comments on subjects in which the free software community is so well-versed, let's take this opportunity to submit comments that support digital sovereignty." The hope is to persuade policy makers to make software freedom and privacy a central part of any future considerations made in the areas of storage, computation, and services. Such comments will be made part of the public record, so any participation promises to have a lasting impact...

[W]e have prepared the following points for consideration:


- When considering rules and regulations in technology that stand to protect people's fundamental civil liberties, it is important to start from the question, "does this decision improve digital sovereignty or diminish it?"

- In the case of computing, (e.g. word processing, spreadsheet, and graphic design programs), the typical options diminish digital sovereignty because the computations are being run on another computer under someone else's control, inaccessible to the end user, who therefore does not have the essential freedoms to share, modify, and study the computations (i.e. the program). The only real solution to this is to offer free "as in freedom" replacements of those programs, so that end users may maintain control over their computing.

- In the case of storage, today's typical options diminish digital sovereignty because many storage providers only provide unencrypted options for storage. It is imperative that individuals and businesses who choose third-party storage always have the choice to encrypt their storage, and the encryption keys must be entirely within the control of the end user, not the third-party provider.

- In the case of services (such as email, teleconferencing, and videoconferencing), while the source code that runs services need not necessarily be made public, end users deserve to be able to access such services via a free software client. In such cases, it is imperative that service providers implement a design of interoperability, so that end users may use the service with any choice of client.

- Free software allows end users to inspect the software for possible security flaws, while proprietary software does not. Therefore free software is the only realistic option for an end user to achieve verifiable security...


Unfortunately, the FTC's website requires nonfree JavaScript (reCAPTCHA, specifically) to comment on a document, and the FTC has declined repeated requests for instructions for how to submit comments by paper form.

If you're not in the habit of avoiding nonfree JavaScript for the sake of your freedom, which we recommend, you can also leave comments on the FTC's website. While you're there, let webmaster@ftc.gov know about the injustice of proprietary JavaScript and encourage them to respect the freedom of their users...

The deadline to submit is June 21, which is just enough time to publish something meaningful on the topic in support of free software.

TechCrunch's Kyle Wiggers writes: Not to be outdone by Google, Meta has released its own AI-powered music generator -- and, unlike Google, open-sourced it. Called MusicGen, Meta's music-generating tool, a demo of which can be found here, can turn a text description (e.g. "An '80s driving pop song with heavy drums and synth pads in the background") into about 12 seconds of audio, give or take. MusicGen can optionally be "steered" with reference audio, like an existing song, in which case it'll try to follow both the description and melody.

Meta says that MusicGen was trained on 20,000 hours of music, including 10,000 "high-quality" licensed music tracks and 390,000 instrument-only tracks from ShutterStock and Pond5, a large stock media library. The company hasn't provided the code it used to train the model, but it has made available pre-trained models that anyone with the right hardware -- chiefly a GPU with around 16GB of memory -- can run.

So how does MusicGen perform? Well, I'd say -- though certainly not well enough to put human musicians out of a job. Its songs are reasonably melodic, at least for basic prompts like "ambient chiptunes music," and -- to my ears -- on par (if not slightly better) with the results from Google's AI music generator, MusicLM. But they won't win any awards.

Slashdot reader e065c8515d206cb0e190 shared the big announcement from Debian.org: After 1 year, 9 months, and 28 days of development, the Debian project is proud to present its new stable version 12 (code name bookworm).

bookworm will be supported for the next 5 years thanks to the combined work of the Debian Security team and the Debian Long Term Support team...

This release contains over 11,089 new packages for a total count of 64,419 packages, while over 6,296 packages have been removed as obsolete. 43,254 packages were updated in this release. The overall disk usage for bookworm is 365,016,420 kB (365 GB), and is made up of 1,341,564,204 lines of code.

bookworm has more translated man pages than ever thanks to our translators who have made man-pages available in multiple languages such as: Czech, Danish, Greek, Finnish, Indonesian, Macedonian, Norwegian (Bokmål), Russian, Serbian, Swedish, Ukrainian, and Vietnamese. All of the systemd man pages are now completely available in German.

The Debian Med Blend introduces a new package: shiny-server which simplifies scientific web applications using R. We have kept to our efforts of providing Continuous Integration support for Debian Med team packages. Install the metapackages at version 3.8.x for Debian bookworm.

The Debian Astro Blend continues to provide a one-stop solution for professional astronomers, enthusiasts, and hobbyists with updates to almost all versions of the software packages in the blend. astap and planetary-system-stacker help with image stacking and astrometry resolution. openvlbi, the open source correlator, is now included.

Support for Secure Boot on ARM64 has been reintroduced: users of UEFI-capable ARM64 hardware can boot with Secure Boot mode enabled to take full advantage of the security feature.
9to5Linux has screenshots, and highlights some new features: Debian 12 also brings read/write support for APFS (Apple File System) with the apfsprogs and apfs-dkms utilities, a new tool called ntfs2btrfs that lets you convert NTFS drives to Btrfs, a new malloc implementation called mimalloc, a new kernel SMB server called ksmbd-tools, and support for the merged-usr root file system layout...

This release also includes completely new artwork called Emerald, designed (once again) by Juliette Taka. New fonts are also present in this major Debian release, along with a new fnt command-line tool for accessing 1,500 DFSG-compliant fonts.
Debian 12 "bookworm" ships with several desktop environments, including:

• Gnome 43,
• KDE Plasma 5.27,
• LXDE 11,
• LXQt 1.2.0,
• MATE 1.26,
• Xfce 4.18

This week the Linux Foundation and the National Spectrum Consortium "announced formal collaboration" on developing software prototypes and demonstrations for Open RAN (open radio access network):

The two organizations have signed a Memorandum of Understanding to solidify their working relationship and commitment to minimizing barriers to further R&D necessary for OpenRAN acceleration within the United States.

More open and flexible wireless networks ultimately increase vendor diversity and competition, prevent vendor lock-in, increase innovation in wireless networking technology, lower deployment and operational costs, and even increase security and energy efficiency. "We are eager to work with the NSC in creating a stable, open, secure reference stack for Open RAN," said Arpit Joshipura, general manager, Networking, Edge & IoT, the Linux Foundation. "By combining resources, we'll accelerate access to Open RAN and wireless technology across the United States across verticals and into government, academia, and small business."
The collaborations goals include:

• Establish an open source reference software architecture for Open RAN that will kickstart academic and commercial R&D by lowering the cost and complexity of entry

• Rally support from industry with guidance and funds to leap forward in a true open and secure RAN

This week the Linux Foundation announced the publication of The Open Source Opportunity for Microgrids: Five Ways to Drive Innovation and Overcome Market Barriers for Energy Resilience. "The research informs readers about microgrids — groups of distributed energy resources designed to improve energy resiliency, with the ability to operate as part of a larger electrical grid, or separately as an island."

The report highlights the current state of the microgrid market and explores the potential for open source technology to accelerate the adoption of microgrids worldwide... The report concludes that microgrids are an essential tool to improve energy resilience and advance decarbonization, and that the market faces a range of challenges that the open source ecosystem is well positioned to address.
Among other things, the report "examines how participation in relevant open source programs and activities can help address gaps and challenges," according to the announcement, "and accelerate the learning, development, and governance of microgrid initiatives." One focus of the report is "enabling market innovation toward energy resilience at scale, supporting the Energy sector to adopt proven open source-enabled business models, security benefits, and cost reductions demonstrated in the IT and Telecom industries."

And according to the foundation's senior vice president of research and communications, the report also "describes the opportunities for open source to accelerate the proliferation of microgrids as a mechanism for clean energy production and consumption."

Long-time Slashdot reader theodp writes: On the AWS News Blog, AWS Chief Evangelist Jeff Barr has published a kind of obituary for AWS Documentation on GitHub (RIP, 2018-2023). From the blog post:

"About five years ago I announced that AWS Documentation is Now Open Source and on GitHub. After a prolonged period of experimentation we will archive most of the repos starting the week of June 5th, and will devote all of our resources to directly improving the AWS documentation and website."

"The primary source for most of the AWS documentation is on internal systems that we had to manually sync with the GitHub repos. Despite the best efforts of our documentation team, keeping the public repos in sync with our internal ones has proven to be very difficult and time consuming, with several manual steps and some parallel editing. With 262 separate repos and thousands of feature launches every year, the overhead was very high and actually consumed precious time that could have been put to use in ways that more directly improved the quality of the documentation."

"Our intent was to increase value to our customers through openness and collaboration, but we learned through customer feedback that this wasn't necessarily the case. After carefully considering many options we decided to retire the repos and to invest all of our resources in making the content better."

Security guru Bruce Schneier and CS professor Jim Waldo think big tech has underestimated the impact of open source principles on AI research: In February, Meta released its large language model: LLaMA. Unlike OpenAI and its ChatGPT, Meta didn't just give the world a chat window to play with. Instead, it released the code into the open-source community, and shortly thereafter the model itself was leaked. Researchers and programmers immediately started modifying it, improving it, and getting it to do things no one else anticipated. And their results have been immediate, innovative, and an indication of how the future of this technology is going to play out. Training speeds have hugely increased, and the size of the models themselves has shrunk to the point that you can create and run them on a laptop. The world of A.I. research has dramatically changed.

This development hasn't made the same splash as other corporate announcements, but its effects will be much greater. It will wrest power from the large tech corporations, resulting in both much more innovation and a much more challenging regulatory landscape. The large corporations that had controlled these models warn that this free-for-all will lead to potentially dangerous developments, and problematic uses of the open technology have already been documented. But those who are working on the open models counter that a more democratic research environment is better than having this powerful technology controlled by a small number of corporations...

[B]uilding on public models like Meta's LLaMa, the open-source community has innovated in ways that allow results nearly as good as the huge models — but run on home machines with common data sets. What was once the reserve of the resource-rich has become a playground for anyone with curiosity, coding skills, and a good laptop.

Bigger may be better, but the open-source community is showing that smaller is often good enough. This opens the door to more efficient, accessible, and resource-friendly LLMs.
Low-cost customization will foster rapid innovation, the article argues, and "takes control away from large companies like Google and OpenAI." Although this may have one unforeseen consequence...

"Now that the open-source community is remixing LLMs, it's no longer possible to regulate the technology by dictating what research and development can be done; there are simply too many researchers doing too many different things in too many different countries."

Thanks to long-time Slashdot reader mrflash818 for submitting the article

The Red Hat Package Managers for LibreOffice "have recently been orphaned," according to a post by Red Hat manager Matthias Clasen on the "LibreOffice packages" mailing list, "and I thought it would be good to explain the reasons behind this." The Red Hat Display Systems team (the team behind most of Red Hat's desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what's needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.

We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.

Any community member is of course free to take over maintenance, both for the RPMs [Red Hat Package Managers] in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Commenters on LWN.net are now debating its impact.

One pointed out that "You will still find it in GNOME Software, which will install a Flatpak from FlatHub rather than an RPM from the distro."

Linux Foundation Europe "has announced the RISC-V Software Ecosystem (RISE) Project to help facilitate more performant, commercial-ready software for the RISC-V processor architecture," reports Phoronix.

"Among the companies joining the RISE Project on their governing board are Andes, Google, Intel, Imagination Technologies, Mediatek, NVIDIA, Qualcomm, Red Hat, Rivos, Samsung, SiFive, T-Head, and Ventana."

It's top goal is "accelerate the development of open source software for RISC-V," according to the official RISE web site. The project's chair says it "brings together leaders with a shared sense of urgency to accelerate the RISC-V software ecosystem readiness in collaboration with RISC-V International." The CEO of RISC-V International, Calista Redmond, said "We are grateful to the thousands of engineers making upstream contributions and to the organizations coming together now to invest in tools and libraries in support of the RISC-V software ecosystem." RISE Project members will contribute financially and provide engineering talent to address specific software deliverables prioritized by the RISE Technical Steering Committee (TSC). RISE is dedicated to enabling a robust software ecosystem specifically for application processors that includes software development tools, virtualization support, language runtimes, Linux distribution integration, and system firmware, working upstream first with existing open source communities in accordance with open source best practices.

"The RISE Project is dedicated to enabling RISC-V in open source tools and libraries (e.g., LLVM, GCC, etc) to speed implementation and time-to-market," said Gabriele Columbro, General Manager of Linux Foundation Europe.
Google's director of engineering on Android said Google was "excited to partner with industry leaders to drive rapid maturity of the RISC-V software ecosystem in support of Android and more."

And the VP of system software at NVIDIA said "NVIDIA's accelerated computing platform — which includes GPUs, DPUs, chiplets, interconnects and software — will support the RISC-V open standard to help drive breakthroughs in data centers, and a wide range of industries, such as automotive, healthcare and robotics."

An anonymous reader quotes a report from ZDNet: Bluesky Social, the popular new beta social network, is taking a big open-source step forward. On May 15th, 2023, it open-sourced the codebase for its Bluesky Social app on GitHub. This fits well with its plans. From the start, its owner, BlueSky Public Benefit LLC, a public benefit corporation, was building an "open and decentralized" social network.

Unlike Twitter, which is still tripping over its own open source feet, Bluesky client code is for anyone who wants to work on improving the code or use it as the basis for their own social network. Twitter's recommendation code, on the other hand, is essentially unusable. The Bluesky code, licensed under the MIT License, can be used now. Indeed, while it's been out for only about 24 hours, it's already been forked 88 times and has earned over 1,300 GitHub Stars.

While it's specifically the Bluesky Social app's codebase, it's also a resource for AT Protocol programmers. This protocol supports a decentralized social network. Its features include connecting with anyone on a server that supports AT Protocol; controlling how users see the world via an open algorithm market; and enabling users to change hosts without losing their content, followers, or identity. The code itself is written in React Native. This is an open-source, user-interface JavaScript software framework. It's used primarily to build applications that run on both iOS and Android devices.

Long-time open source advocate Matt Asay writes in InfoWorld: OpenSearch shouldn't exist. The open source alternative to Elasticsearch started off as Amazon Web Services' (AWS) answer to getting outflanked by Elastic's change in Elasticsearch's license, which was in turn sparked by AWS building a successful Elasticsearch service but contributing little back. In 2019 when AWS launched its then Open Distro for Elasticsearch, I thought its reasons rang hollow and, frankly, sounded sanctimonious. This was, after all, a company that used more open source than it contributed. Two years later, AWS opted to fork Elasticsearch to create OpenSearch, committing to a "long-term investment" in OpenSearch.

I worked at AWS at the time. Privately, I didn't think it would work.

Rather, I didn't feel that AWS really understood just how much work was involved in running a successful open source project, and the company would fail to invest the time and resources necessary to make OpenSearch a viable competitor to Elasticsearch. I was wrong. Although OpenSearch has a long way to go before it can credibly claim to have replaced Elasticsearch in the minds and workloads of developers, it has rocketed up the search engine popularity charts, with an increasingly diverse contributor population. In turn, the OpenSearch experience is adding a new tool to AWS' arsenal of open source strengths....

As part of the AWS OpenSearch team, David Tippett and Eli Fisher laid out a few key indicators of OpenSearch's success as they gave their 2022 year in review. They topped more than 100 million downloads and gathered 8,760 pull requests from 496 contributors, a number of whom don't work for AWS. Not stated were other success factors, such as Adobe's earlier decision to replace Elasticsearch with OpenSearch in its Adobe Commerce suite, or its increasingly open governance with third-party maintainers for the project. Nor did they tout its lightning-fast ascent up the DB-Engines database popularity rankings, hitting the Top 50 databases for the first time.

OpenSearch, in short, is a bonafide open source success story. More surprisingly, it's an AWS open source success story. For many who have been committed to the "AWS strip mines open source" narrative, such success stories aren't supposed to exist. Reality bites.
The article notes that OpenSearch's success "doesn't seem to be blunting Elastic's income statement." But it also points out that Amazon now has many employees actively contributing to open source projects, including PostgreSQL and MariaDB. (Although "If AWS were to turn forking projects into standard operating procedure, that might get uncomfortable.")

"Fortunately, not only has AWS learned how to build more open source, it has also learned how to partner with open source companies."

Veteran open source report Steven J. Vaughan-Nichols, writing at The Register: We can all agree that securing our software is a good thing. Thanks to one security fiasco after another -- the SolarWinds software supply chain attack, the perpetual Log4j vulnerability, and the npm maintainer protest code gone wrong -- we know we must secure our code. But the European Union's proposed Cyber Resilience Act (CRA) goes way, way too far in trying to regulate software security. At the top level, it looks good. Brussels states that before "products with digital elements" are allowed on the EU market, manufacturers must follow best practices in four areas. Secure the product over its whole life; follow a coherent cybersecurity framework; show cybersecurity transparency; and ensure customers can use products securely. Sounds great, doesn't it? But the road to hell is paved with good intentions. The devil, as always, is in the details. Some of this has nothing to do with open source software. Good luck creating any program in any way that a clueless user can't screw up.

But the EU commissioners don't have a clue about how open source software works. Or, frankly, what it is. They think that open source is the same as proprietary software with a single company behind it that's responsible for the work and then monetizes it. Nope. Open source, as I've said over and over again, is not a business model. Sure, you can build businesses around it. Who doesn't these days? But just as the AWSes, Googles, and Facebooks of the world depend on open source software, they also use programs written by Tom, Denise, and Harry from around the world. The CRA's underlying assumption is that you can just add security to software, like adding a new color option to your car's paint job. We wish!

Securing software is a long, painful process. Many open source developers have neither the revenue nor resources to secure their programs to a government standard. The notional open source developer in Nebraska, thanklessly maintaining a vital small program, may not even know where Brussels is (it's in Belgium). They can't afford to secure their software to meet EU specifications. They often have no revenue. They certainly have no control over who uses their software. It's open source, for pity's sake! As open source developer Thomas Depierre recently blogged: "We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organizations. We are volunteers, writing code and putting it online under these Licenses." Exactly.