"Linux creator Linus Torvalds has agreed to include Paragon Software's NTFS3 kernel driver, giving the Linux kernel 5.15 release improved support for Microsoft's NTFS file system..." reports ZDNet, adding that the driver "will make working with Windows' NTFS drives in Linux an easier task — ending decades of difficulties with Microsoft's proprietary file system that succeeded FAT...."

"But he also had some process and security lessons to offer developers about how to code submissions to the kernel should be made." "I notice that you have a GitHub merge commit in there," wrote Torvalds.

He continued: "That's another of those things that I *really* don't want to see — GitHub creates absolutely useless garbage merges, and you should never ever use the GitHub interfaces to merge anything...GitHub is a perfectly fine hosting site, and it does a number of other things well too, but merges are not one of those things."

Torvalds' chief problem with it was that merges need "proper commit messages with information about [what] is being merged and *why* you merge something." He continued: "But it also means proper authorship and committer information etc. All of which GitHub entirely screws up."
TechRadar supplies some more context: One of the shortcomings Torvalds highlighted are GitHub's concise, factually correct, but functionally useless, commit messages. For instance, GitHub's commit message for Paragon's merge read "Merge branch 'torvalds:master' into master", which didn't impress Torvalds one bit...

Torvalds also had some pertinent security advice, perhaps useful in light of recent software supply chain cyberattacks that the Linux Foundation wants to address by improving supply chain integrity through tools that make it easier to sign software cryptographically. As Torvalds points out, this is particularly important for new contributors to the Linux kernel. "For GitHub accounts (or really, anything but kernel.org where I can just trust the account management), I really want the pull request to be a signed tag, not just a plain branch," Torvalds explains...

Torvalds suggests Paragon do future merges from the command-line.

Five years ago Linus Torvalds commemorated Linux's 25th anniversary in an interview with ZDNet's Steven J. Vaughan-Nichols. Now that Linux is celebrating its 30th birthday, Vaughan-Nichols interviewed Torvalds again, who makes an important philosophical point: Trying to look at the bigger picture, Torvalds now thinks the period in early 1992 — when Linux switched to using the Gnu Public License version 2 (GPLv2) — was especially important. He recalls, "It wasn't the original license, but I'm convinced it's a big part of why Linux became so widespread. Not everybody loves the GPL, and I've had my own issues with the FSF [Free Software Foundation], but I do think the GPLv2 has been a huge deal, and people shouldn't dismiss the licensing issues."

He adds:

"I think the companies getting involved has been hugely important — and that may sound so obvious as to be trite and stupid, but some corners of the open-source community have been fairly negative to any commercial involvement."
Torvalds points out that from its earliest days Linux has experienced "fairly continual" interest from major companies.

The interview also revisits Linux's version control systems and the name Torvalds had originally chosen for the operating system back in 1991. ("Freax," for "Free Unix.") But 10 years ago, the same reporter got a surprise when he'd asked Torvalds where he thought Linux would be on its 40th birthday. Torvalds' answer?

"Bah. I don't plan that far ahead. I can barely keep my calendar for the next week in mind. I really have no idea."

So this week Steven J. Vaughan-Nichols instead asked Torvalds how he's envisioning his own future: Looking ahead, Torvalds sees himself keeping on. "I'm 51 years young, I enjoy what I'm doing. What would I do if I didn't do Linux? Puttering around in the garden? Not bloody likely.
Slashdot reader juul_advocate shares some context. Torvalds was also contacted by IT Wire to get his thoughts on the 30th birthday of Linux. "There's literally a few people who are still active and around that got involved in '91..." Torvalds told them: "I like having been around for that long, and it's also nice how many other people have actually been around for almost that long...

"But I just don't have anything new to say about it, I'm afraid. And while today is an anniversary date, it's not even the only one. This was the anniversary of the first public announcement, but it wasn't actually the actual first code drop. That came later — 17 September.

"And even that second anniversary isn't the 'last' anniversary, because the Linux 0.01 code drop on 17 September was only privately announced to people who had shown some interest from the first announcement.

"So the first actually public and real *announced* code drop was 5 October 1991, which is when 0.02 was dropped. So I actually have three anniversaries, and they are all equally valid in my mind."

Slashdot has confirmed with the U.S. Bankruptcy Court for the District of Delaware that after 18 years of legal maneuvering, SCO's bankruptcy case (first filed in 2007) is now "awaiting discharge."

Long-time Slashdot reader rkhalloran says they know the reason: Papers filed 26 Aug by IBM & SCOXQ in U.S. Bankruptcy Court in Delaware for a proposed settlement, Case 07-11337-BLS Doc 1501:

By the Settlement Agreement, the Trustee has reached a settlement with IBM that resolves all of the remaining claims at issue in the Utah Litigation (defined below). The Settlement Agreement is the culmination of extensive arm's length negotiation between the Trustee and IBM.

Under the Settlement Agreement, the Parties have agreed to resolve all disputes between them for a payment to the Trustee, on behalf of the Estates, of $14,250,000. For the reasons set forth more fully below, the Trustee submits the Settlement Agreement and the settlement with IBM are in the best interests of the Estates and creditors, are well within the range of reasonableness, and should be approved.
The proposed order would include "the release of the Estates' claims against IBM and vice versa" (according to this PDF attributed to SCO Group and IBM uploaded to scribd.com). And one of the reasons given for the proposed settlement? "The probability of the ultimate success of the Trustee's claims against IBM is uncertain," according to an IBM/SCO document on Scribd.com titled Trustee's motion: For example, succeeding on the unfair competition claims will require proving to a jury that events occurring many years ago constituted unfair competition and caused SCO harm. Even if SCO were to succeed in that effort, the amount of damages it would recover is uncertain and could be significantly less than provided by the Settlement Agreement. Such could be the case should a jury find that (1) the amount of damage SCO sustained as a result of IBM's conduct is less than SCO has alleged, (2) SCO's damages are limited by a $5 million damage limitation provision in the Project Monterey agreement, or (3) some or all of IBM's Counterclaims, alleging millions of dollars in damages related to IBM's Linux activities and alleged interference by SCO, are meritorious.

Although the Trustee believes the Estates would ultimately prevail on claims against IBM, a not insignificant risk remains that IBM could succeed with its defenses and/or Counterclaims
The U.S. Bankruptcy Court for the District of Delaware told Slashdot that the first meeting of the creditors will be held on September 22nd, 2021.

Programmer Ryan C. Gordon (also known as icculus) is a former employee at Loki Software, one of the first companies to port videogames from Microsoft Windows to Linux, according to his Wikipedia page. He's still hosting many Loki software projects at icculus.org, "as well as several new projects created by himself and others."

He's also Slashdot reader #32,040, and dropped by this week with a very special announcement: I took Zork 1 and made it into a multiplayer game!

You can try it yourself by telnetting to multizork.icculus.org with some friends. Telnet seemed appropriate for a game from 1980, at least until I can figure out how to efficiently send everyone a 300 baud modem.

A detailed technical explanation about hacking the Z-Machine to make this work is over here and source code is, of course, available. Enjoy, and don't get eaten by a grue!

ByteDance, TikTok's parent company, has joined the Open Invention Network (OIN), the world's largest non-aggression consortium that protects Linux and related open-source software and the companies behind them from patent attacks and patent trolls. ZDNet reports: The OIN recently broadened its scope from core Linux programs and adjacent open-source code by expanding its Linux System Definition to other patents such as the Android Open Source Project (AOSP) and the Extended File Allocation Table exFAT file system. By becoming a licensee and community member of OIN, ByteDance will be sharing its other patents to Helo, Resso, and the Chinese specific programs Toutiao, Douyin, and Xigua.

Why is ByteDance doing this? Because, like many other companies, including Microsoft, they consider "Linux and adjacent open source software as key elements for our business," said Lynn Wu, ByteDance's Chief IP Counsel. Wu continued, "ByteDance's participation in the OIN community shows our consistent commitment to shared innovation. We will continue to support it with patent non-aggression in core Linux and other important open-source software technologies." ByteDance may also have joined because its biggest fellow Chinese rival, Kuaishou, recently joined the OIN. In recent years, many Chinese firms, such as hardware giant Inspur, have joined forces with the OIN.

"One of the oldest and most renowned distributions of Linux has been released!" âwrites Slashdot reader Washuu2. Phoronix reports it took "just over two years in development." Debian 11 brings many new features as outlined this morning with the big upgrade to Linux 5.10 LTS, exFAT file-system support, control groups v2, yescrypt for password hashing, and a plethora of updated packages. GNOME 3.38, KDE Plasma 5.20, and Xfce 4.16 are among the desktop options for Debian 11.
Debian.org adds: Do you want to celebrate the release? We provide some bullseye artwork that you can share or use as base for your own creations. Follow the conversation about bullseye in social media via the #ReleasingDebianBullseye and #Debian11Bullseye hashtags...
Around the world, there were even several in-person and online release parties — with a few more upcoming!

LTTng has been called "the killer app for system-level debugging and performance tuning." And now long-time Slashdot reader compudj writes: It's the official release of LTTng 2.13 — Nordicité! LTTng is a kernel and user-space tracer for Linux. The most notable features of this release are:

- Event-rule matches condition triggers and new actions, allowing internal actions or external monitoring applications to quickly react when kernel or user-space instrumentation is hit

- Notification payload capture, allowing external monitoring applications to read elements of the instrumentation payload when instrumentation is hit.

- Instrumentation API: vtracef and vtracelog (LTTng-UST)

- User space time namespace context (LTTng-UST and LTTng-modules).

In January ElasticSearch made what it calls "an incredibly hard decision" — to change the licensing on its scalable data-search solution. They called this an effort to "stand up to" Amazon's AWS for offering ElasticSearch functionality as a service "without collaborating with us... after years of what we believe to be Amazon/AWS misleading and confusing the community." Amazon then forked ElasticSearch, releasing a new "OpenSearch" product under the original Apache 2.0 licensing. Last month AWS's fork reached General Availability/1.0 status.

Now Mike Melanson's "This Week in Programming" column reports that ElasticSearch is "making further attempts at closing off access to ElasticSearch and shutting out AWS — while AWS is fighting back: AWS says that "OpenSearch aims to provide wire compatibility with open source distributions of Elasticsearch 7.10.2, the software from which it was derived," making it easy to migrate to OpenSearch. While Elastic can't do anything about that, they can make changes to some open source client libraries that are commonly used. "Over the past few weeks, Elastic added new logic to several of these clients that rejects connections to OpenSearch clusters or to clusters running open source distributions of Elasticsearch 7, even those provided by Elastic themselves," AWS writes. "While the client libraries remain open source, they now only let applications connect to Elastic's commercial offerings..."

AWS is again coming out as the savior of open source in this scenario, it would seem, this time promising to offer "a set of new open source clients that make it easy to connect applications to any OpenSearch or Elasticsearch cluster" that "will be derived from the last compatible versions of corresponding Elastic-maintained clients before product checks were added."

"In the spirit of openness and interoperability, we will make reasonable efforts to maintain compatibility with all Elasticsearch distributions, even those produced by Elastic," they write. In the meantime, while the OpenSearch community works on creating the replacement libraries, AWS recommends that users do not update to the latest version of any Elastic-maintained clients, lest their applications potentially cease functioning.
"It's disappointing to see this," reads a comment (upvoted 35 times) on the ElasticSearch repository announcing the change in late June. "You're forcing us as bystanders in a battle to choose sides." And Amazon responded with its own take on the situation in their AWS press release this week. "Our experience at AWS is that developers find it painful to update their already-deployed applications to use new versions of server software, so backward compatibility for clients and APIs weighs heavily in our designs..."

The press release also calls ElasticSearch's changes "disruptive," adding "The most broadly adopted open source projects generally emphasize flexibility, inclusion, and avoidance of lock-in..."

Jim Salter writes via Ars Technica: In March of last year, proprietary filesystem vendor Paragon Software unleashed a stream of anti-open source FUD about a Samsung-derived exFAT implementation headed into the Linux kernel. Several months later, Paragon seemed to have seen the error of its ways and began the arduous process of getting its own implementation of Microsoft's NTFS (the default filesystem for all Windows machines) into the kernel as well. Although Paragon is still clearly struggling to get its processes and practices aligned to open source-friendly ones, Linux kernel BDFL Linus Torvalds seems to have taken a personal interest in the process. After nearly a year of effort by Paragon, Torvalds continues to gently nudge both it and skeptical Linux devs in order to keep the project moving forward.

To those familiar with daily Linux use, the utility of Paragon's version of NTFS might not be immediately obvious. The Linux kernel already has one implementation of NTFS, and most distributions make it incredibly easy to install and use another FUSE-based implementation (ntfs-3g) beyond that. Both existing implementations have problems, however. The in-kernel implementation of NTFS is extremely old, poorly maintained, and should only be used read-only. As a result, most people who actually need to mount NTFS filesystems on Linux use the ntfs-3g driver instead. Ntfs-3g is in reasonably good shape -- it's much newer than the in-kernel ntfs implementation, and as Linux filesystem guru Ted Ts'o points out, it actually passes more automated filesystem tests than Paragon's own ntfs3 does.

Unfortunately, due to operating in userspace rather than in-kernel, ntfs-3g's performance is abysmal. In Ts'o's testing, Paragon's ntfs3 completed automated testing in 8,106 seconds -- but the FUSE-based ntfs-3g required a whopping 34,783 seconds. Bugs and performance aside, ongoing maintenance is a key aspect to Paragon's ntfs3 making it in-kernel. Torvalds opined that "Paragon should just make a pull request for [ntfs3]" -- but he did so after noting that the code should get OKs from current maintainers and that Paragon itself should maintain the code going forward. (Paragon developer Konstantin Komarov quickly replied that the company intended to continue maintaining the code, once accepted.) [...] For his own part, Torvalds seems determined to find a performant, modern, maintainable replacement for the ancient (2001-era) and seldom-used ntfs implementation in the kernel now. As long as Paragon remains willing to keep playing, it seems likely to get there eventually -- perhaps even in time for the 5.15 kernel.

GitHub's new "Copilot" tool (created by Microsoft and OpenAI) shares the autocompletion suggestions of an AI trained on code repositories. But can that violate the original coder's license? Now the Free Software Foundation (FSF) is calling for a closer look at these and many other issues...

"We already know that Copilot as it stands is unacceptable and unjust, from our perspective," they wrote in a blog post this week, arguing that Copilot "requires running software that is not free/libre (Visual Studio, or parts of Visual Studio Code), and Copilot is Service as a Software Substitute. These are settled questions as far as we are concerned."

"However, Copilot raises many other questions which require deeper examination..." The Free Software Foundation has received numerous inquiries about our position on these questions. We can see that Copilot's use of freely licensed software has many implications for an incredibly large portion of the free software community. Developers want to know whether training a neural network on their software can really be considered fair use. Others who may be interested in using Copilot wonder if the code snippets and other elements copied from GitHub-hosted repositories could result in copyright infringement. And even if everything might be legally copacetic, activists wonder if there isn't something fundamentally unfair about a proprietary software company building a service off their work.

With all these questions, many of them with legal implications that at first glance may have not been previously tested in a court of law, there aren't many simple answers. To get the answers the community needs, and to identify the best opportunities for defending user freedom in this space, the FSF is announcing a funded call for white papers to address Copilot, copyright, machine learning, and free software.

We will read the submitted white papers, and we will publish ones that we think help elucidate the problem. We will provide a monetary reward of $500 for the papers we publish.
They add that the following questions are of particular interest:

• Is Copilot's training on public repositories infringing copyright? Is it fair use?
• How likely is the output of Copilot to generate actionable claims of violations on GPL-licensed works?
• How can developers ensure that any code to which they hold the copyright is protected against violations generated by Copilot?
• Is there a way for developers using Copilot to comply with free software licenses like the GPL?
• If Copilot learns from AGPL-covered code, is Copilot infringing the AGPL?
• If Copilot generates code which does give rise to a violation of a free software licensed work, how can this violation be discovered by the copyright holder on the underlying work?
• Is a trained artificial intelligence (AI) / machine learning (ML) model resulting from machine learning a compiled version of the training data, or is it something else, like source code that users can modify by doing further training?
• Is the Copilot trained AI/ML model copyrighted? If so, who holds that copyright?
• Should ethical advocacy organizations like the FSF argue for change in copyright law relevant to these questions?

"GitHub has announced a partnership with the Stanford Law School to support developers facing takedown requests related to the Digital Millennium Copyright Act (DMCA)," reports VentureBeat: While the DMCA may be better known as a law for protecting copyrighted works such as movies and music, it also has provisions (17 U.S.C. 1201) that criminalize attempts to circumvent copyright-protection controls — this includes any software that might help anyone infringe DMCA regulations. However, as with the countless spurious takedown notices delivered to online content creators, open source coders too have often found themselves in the DMCA firing line with little option but to comply with the request even if they have done nothing wrong. The problem, ultimately, is that freelance coders or small developer teams often don't have the resources to fight DMCA requests, which puts the balance of power in the hands of deep-pocketed corporations that may wish to use DMCA to stifle innovation or competition. Thus, GitHub's new Developer Rights Fellowship — in conjunction with Stanford Law School's Juelsgaard Intellectual Property and Innovation Clinic — seeks to help developers put in such a position by offering them free legal support.

The initiative follows some eight months after GitHub announced it was overhauling its Section 1201 claim review process in the wake of a takedown request made by the Recording Industry Association of America (RIAA), which had been widely criticized as an abuse of DMCA... [M]oving forward, whenever GitHub notifies a developer of a "valid takedown claim," it will present them with an option to request free independent legal counsel.

The fellowship will also be charged with "researching, educating, and advocating on DMCA and other legal issues important for software innovation," GitHub's head of developer policy Mike Linksvayer said in a blog post, along with other related programs.
Explaining their rationale, GitHub's blog post argues that currently "When developers looking to learn, tinker, or make beneficial tools face a takedown claim under Section 1201, it is often simpler and safer to just fold, removing code from public view and out of the common good.

"At GitHub, we want to fix this."

Fossbytes has an article detailing how you can check to see if your mobile device is infected with the "Pegasus" spyware. What's Pegasus you ask? It's phone-penetrating spy software developed by NSO Group and sold to governments to target journalists and activists around the world. The CEO of NSO Group says law-abiding citizens have "nothing to be afraid of," but that doesn't help us sleep any better. Here's how to check if your device has been compromised (heads up: it's a bit of a technical and lengthy process): First off, you'll need to create an encrypted backup and transfer it to either a Mac or PC. You can also do this on Linux instead, but you'll have to install libimobiledevice beforehand for that. Once the phone backup is transferred, you need to download Python 3.6 (or newer) on your system -- if you don't have it already. Here's how you can install the same for Windows, macOS, and Linux. After that, go through Amnesty's manual to install MVT correctly on your system. Installing MVT will give you new utilities (mvt-ios and mvt-android) that you can use in the Python command line. Now, let's go through the steps for detecting Pegasus on an iPhone backup using MVT.

First of all, you have to decrypt your data backup. To do that, you'll need to enter the following instruction format while replacing the placeholder text (marked with a forward slash) with your custom path: "mvt-ios decrypt-backup -p password -d /decrypted /backup". Note: Replace "/decrypted" with the directory where you want to store the decrypted backup and "/backup" with the directory where your encrypted backup is located.

Now, we will run a scan on the decrypted backup, referencing it with the latest IOCs (possible signs of Pegasus spyware), and store the result in an output folder. To do this, first, download the newest IOCs from here (use the folder with the latest timestamp). Then, enter the instruction format as given below with your custom directory path: "mvt-ios check-backup -o /output -i /pegasus.stix2 /backup". Note: Replace "/output" with the directory where you want to store the scan result, "/backup" with the path where your decrypted backup is stored, and "/pegasus.stix2" with the path where you downloaded the latest IOCs.

After the scan completion, MVT will generate JSON files in the specified output folder. If there is a JSON file with the suffix "_detected," then that means your iPhone data is most likely Pegasus-infected. However, the IOCs are regularly updated by Amnesty's team as they develop a better understanding of how Pegasus operates. So, you might want to keep running scans as the IOCs are updated to make sure there are no false positives.

An anonymous reader quotes a report from Ars Technica: Muse Group -- owner of the popular audio-editing app Audacity -- is in hot water with the open source community again. This time, the controversy isn't over Audacity -- it's about MuseScore, an open source application that allows musicians to create, share, and download musical scores (especially, but not only, in the form of sheet music). The MuseScore app itself is licensed GPLv3, which gives developers the right to fork its source and modify it. One such developer, Wenzheng Tang ("Xmader" on GitHub) went considerably further than modifying the app -- he also created separate apps designed to bypass MuseScore Pro subscription fees. After thoroughly reviewing the public comments made by both sides at GitHub, Ars spoke at length with Muse Group Head of Strategy Daniel Ray -- known on GitHub by the moniker "workedintheory" -- to get to the bottom of the controversy.

While Xmader did, in fact, fork MuseScore, that's not the root of the controversy. Xmader forked MuseScore in November 2020 and appears to have abandoned that fork entirely; it only has six commits total -- all trivial, and all made the same week that the fork was created. Xmader is also currently 21,710 commits behind the original MuseScore project repository. Muse Group's beef with Xmader comes from two other repositories, created specifically to bypass subscription fees. Those repositories are musescore-downloader (created November 2019) and musescore-dataset (created March 2020). Musescore-downloader describes itself succinctly: "download sheet music from musescore.com for free, no login or MuseScore Pro required." Musescore-dataset is nearly as straightforward: it declares itself "the unofficial dataset of all music sheets and users on musescore.com." In simpler terms: musescore-downloader lets you download things from musescore.com that you shouldn't be able to; musescore-dataset is those files themselves, already downloaded. For scores that are in the public domain or that users have uploaded under Creative Commons licenses, this isn't necessarily a problem. But many of the scores are only available by arrangement between the score owner and Muse Group itself -- and this has several important implications.

Just because you can access the score via the app or website doesn't mean you're free to access it anywhere, anyhow, or redistribute that score yourself. The distribution agreement between Muse Group and the rightsholder allows legitimate downloads, but only when using the site or app as intended. Those agreements do not give users carte blanche to bypass controls imposed on those downloads. Further, those downloads can often cost the distributor real money -- a free download of a score licensed to Muse Group by a commercial rightsholder (e.g., Disney) is generally not "free" to Muse Group itself. The site has to pay for the right to distribute that score -- in many cases, based on the number of downloads made. Bypassing those controls leaves Muse Group on the hook either for costs it has no way to monetize (e.g., by ads for free users) or for violating its own distribution agreements with rightsholders (by failing to properly track downloads).

Today, Amaon said it will be upgrading almost every plug-in Echo smart speaker to support Matter, a cross-platform open-source standard coming later this year. This includes most Echo and Echo Dot speakers and every Echo Studio, Echo Show, Echo Plus, and Echo Flex. "In fact, the only Echo smart speakers that won't get upgraded to Matter are the first-gen Echo, first-gen Echo Dot and Echo Tap," reports The Verge. From the report: While the company doesn't provide a timeline for those upgrades, the general idea is that Matter will launch by late 2021, so it shouldn't be long until Amazon's newest and / or more popular devices receive the capability. A bigger question is whether any of them will work as Matter hubs. Google announced in May that in addition to upgrading its Nest devices to Matter, it would allow its devices that support the Thread protocol (like the Nest Wi-Fi, Nest Hub Max, and second-gen Nest Hub) to double as connection hubs for Matter, too, not simply as a voice assistant to control Matter gadgets. But while Amazon's Eero routers were early to adopt Thread, Amazon's Echo smart speakers were not.

Slashdot reader Hmmmmmm shares a blog post from Stockfish announcing a lawsuit against ChessBase: The Stockfish project strongly believes in free and open-source software and data. Collaboration is what made this engine the strongest chess engine in the world. We license our software using the GNU General Public License, Version 3 (GPL) with the intent to guarantee all chess enthusiasts the freedom to use, share and change all versions of the program. Unfortunately, not everybody shares this vision of openness. We have come to realize that ChessBase concealed from their customers Stockfish as the true origin of key parts of their products (see also earlier blog posts by us and the joint Lichess, Leela Chess Zero, and Stockfish teams). Indeed, few customers know they obtained a modified version of Stockfish when they paid for Fat Fritz 2 or Houdini 6 -- both Stockfish derivatives -- and they thus have good reason to be upset. [ChessBase released Fat Fritz 2, described on their website as the "new number 1" chess engine "with a massive new neural network, trained by Albert Silver with the original Fat Fritz." They advertise Fat Fritz 2 as using novel strong ideas compared to existing chess engines, but in reality Fat Fritz 2 is just Stockfish with a different neural network and minimal changes that are neither innovative nor appear to make the engine stronger.] ChessBase repeatedly violated central obligations of the GPL, which ensures that the user of the software is informed of their rights. These rights are explicit in the license and include access to the corresponding sources, and the right to reproduce, modify and distribute GPLed programs royalty-free.

In the past four months, we, supported by a certified copyright and media law attorney in Germany, went through a long process to enforce our license. Even though we had our first successes, leading to a recall of the Fat Fritz 2 DVD and the termination of the sales of Houdini 6, we were unable to finalize our dispute out of court. Due to Chessbase's repeated license violations, leading developers of Stockfish have terminated their GPL license with ChessBase permanently. However, ChessBase is ignoring the fact that they no longer have the right to distribute Stockfish, modified or unmodified, as part of their products. Thus, to enforce the consequences of the license termination, we have filed a lawsuit. This lawsuit is broadly supported by the team of maintainers and developers of Stockfish. We believe we have the evidence, the financial means and the determination to bring this lawsuit to a successful end. We will provide an update to this statement once significant progress has been made.

Mike Melanson's "This Week in Programming" column shares an update on Amazon's ongoing battle with scalable data search solution ElasticSearch: Earlier this year, AWS completed its fork of ElasticSearch with the first release of OpenSearch. If you haven't followed along, the whole affair was a bit of a tug of war between AWS and Elastic, with AWS eventually coming out seemingly on top. After Elastic changed the licensing on ElasticSearch in an attempt to prevent AWS from selling a service based on the then-open-source project, AWS forked the project to release OpenSearch under Apache 2.0, effectively preserving its open source status.

Now, OpenSearch has reached 1.0, which AWS says not only "marks the first production-ready version of OpenSearch," but also introduces "multiple new enhancements," such as data streams, trace analytics span filtering, report scheduling and more. The 1.0 release also involved quite a bit of code cleanup, removing proprietary code and marks, and adds the ability to upgrade from ElasticSearch to OpenSearch as if you were performing a normal upgrade of ElasticSearch.

If you're interested in learning where the project is going, head on over to the public roadmap to learn more.

"By 2030, technology will have advanced to the point that even the idea of owning objects might be obsolete," argues a thought-provoking new piece by Gizmodo's consumer tech reporter: Back in 2016, the World Economic Forum released a Facebook video with eight predictions it had for the world in 2030. "You'll own nothing. And you'll be happy," it says. "Whatever you want, you'll rent. And it'll be delivered by drone...."

In some ways, not owning things is easier. You have fewer commitments, less responsibility, and the freedom to bail whenever you want. There are upsides to owning less. There's also a big problem... The reality is when you buy a device that requires proprietary software to run, you don't own it. The money you hand over is an entry fee, nothing more. When everything is a lease, you also agree to a life defined by someone else's terms... When hardware is merely a vessel for software and not a useful thing on its own, you don't really get to decide anything. A company will decide when to stop pushing vital updates. It might also decide what you do with the product after it's "dead...." The power has shifted so that companies set the parameters, and consumers have to make do with picking the lesser of several evils...

You can trace much of this back to Section 1201 of the Digital Millennium Copyright Act (DMCA), which basically makes it illegal to circumvent "digital locks" that protect a company's proprietary software... One day in the future, if you buy a physical house, you will likely have to rent the software that operates it. You won't really have a say in the updates that get pushed out, or the features that get taken away. You'll have less of a say in when you renovate or upgrade, even if you want to continue using the house as is. You might not even have the right to do DIY repairs yourself. Just because you've bought a smart washing machine, doesn't mean you'll be allowed to repair it yourself if it breaks — or if you'll be allowed to pick which repair shop can fix it for you. You only have to look as far as John Deere, Apple, and General Motors. Each one of these companies has argued that people who bought their products weren't allowed to repair them unless they were from a pre-approved shop.

The scary thing is that only sounds terrible if you have the mental energy to care about principles.

Making decisions all the time is difficult, and it's easier when someone else limits the options you can choose from. It's not hard to turn a blind eye to a problem if, for the most part, your life is made a little simpler. Isn't that what every tech company says it's trying to do? Make your life a little simpler? Life is hard enough already, and living in a home that maintains itself so long as you hand over control — well, by 2030, who's to say that's not what we'll all want?

"We're building a chip. A fast chip. A safe chip. A trusted chip," explains the web page at Libre-SOC.org. "A chip with lots of peripherals. And it's VPU. And it's a 3D GPU... Oh and here, have the source code."

And now there's big news, reports long-time Slashdot reader lkcl: Libre-SOC's entirely Libre 180nm ASIC, which can be replicated down to symbolic level GDS-II with no NDAs of any kind, has been submitted to IMEC for fabrication.

It is the first wholly-independent Power ISA ASIC outside of IBM to go Silicon in 12 years. Microwatt went to Skywater 130nm in March; however, it is also developed by IBM, as an exceptionally well-made Reference Design, which Libre-SOC used for verification.

Whilst it would seem that Libre-SOC is jumping on the chip-shortage era's innovation bandwagon, Libre-SOC has actually been in development for over three and a half years so far. It even pre-dates the OpenLane initiative, and has the same objectives: fully automated HDL to GDS-II, full transparency and auditability with Libre VLSI tools Coriolis2 and Libre Cell Libraries from Chips4Makers.

With €400,000 in funding from the NLNet Foundation [a long-standing non-profit supporting privacy, security, and the "open internet"], plus an application to NGI Pointer under consideration, the next steps are to continue development of Draft Cray-style Vectors (SVP64) to the already supercomputer-level Power ISA, under the watchful eye of the upcoming OpenPOWER ISA Workgroup.

"The Rust for Linux project, sponsored by Google, has advanced..." reported the Register earlier this week: A new set of patches submitted to the Linux kernel mailing list summarizes the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.

- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...

- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...

There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.

More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."

Over the Fourth of July weekend, a number of news outlets, including Slashdot, ran stories warning that the free and open-source audio editor Audacity may now be classified as spyware due to recent updates to its privacy policy. Ars Technica's Jim Salter looked into these claims and found that that is not the case. An anonymous reader shares an excerpt from his report: FOSS-focused personal technology site SlashGear declares that although Audacity is free and open source, new owner Muse Group can "do some pretty damaging changes" -- specifically meaning its new privacy policy and telemetry features, described as "overarching and vague." FOSSPost goes even further, running the headline "Audacity is now a possible spyware, remove it ASAP." The root of both sites' concern is the privacy policy instigated by new Audacity owner Muse Group, who already published open source music notation tool MuseScore. The privacy policy, which was last updated on July 2, outlines the data which the app may collect [...]. The personal data being collected as outlined in the first five bullet points is not particularly broad -- in fact, it's quite similar to the collected data described in FOSSPost's own privacy policy: IP address, browser user-agent, "some other cookies your browser may provide us with," and (by way of WordPress and Google analytics) "your geographical location, cookies for other websites you visited or any other information your browser can give about you." This leaves the last row -- data necessary for law enforcement, litigation and authorities' requests (if any)." While that's certainly a broad category and not particularly well-defined, it's also a fact of life in 2021. Whether a privacy policy says so or not, the odds are rather good that any given company will comply with legitimate law enforcement requests. If it doesn't, it won't likely be a company for long. The final grain of salt in the wound is a line stating that Audacity is "not intended for individuals below the age of 13" and requesting people under 13 years old "please do not use the App." This is an effort to avoid the added complexity and expense of dealing with laws regulating collection of personal data from children.

The first thing to point out is that neither the privacy policy nor the in-app telemetry in question are actually in effect yet -- both are targeted to an upcoming 3.0.3 release, while the most recent available version is 3.0.2. For now, that means there's absolutely no need for anyone to panic about their currently-installed version of Audacity. [...] Although FOSS-focused media outlets including FOSSPost and Slashgear reported negatively on this issue over the holiday weekend, the contributors and commenters active on the project's Github seem to have been largely satisfied by the May 13 update, which declared that Muse Group would self-host its telemetry sessions rather than using third-party libraries and hosting. The same day the second pull request went live, Github user Megaf said, "Good stuff. As long as the data is not going to [third party tech giants] we should be happy. Collect the data you really need, self-host it, make it private, make it opt-in, and we shall help." It's a small sample, but the sentiment seems broadly supported, with 66 positive and 12 negative reactions. Reaction to Megaf's comment reflects user reaction to the updated pull request itself, which currently has 606 positive and 29 explicitly negative reactions -- a marked improvement over the original pull request's 4,039 explicitly negative reactions and only 300 positive reactions. We believe that the user community got it right -- Muse Group appears to be taking the community's privacy concerns very seriously indeed, and its actual policies as stated appear to be reasonable.