The role of Microsoft's .NET Foundation, set up for the governance and support of open-source .NET and related projects, has been questioned by a former board member who resigned in frustration. Here's an excerpt from The Register's report: Rodney Littles II is a software engineer at Megsoft Consulting and core maintainer of an open-source project, ReactiveUI, which is a .NET Foundation project. The .NET Foundation was formed in 2014 and describes itself as "an independent, non-profit organization established to support an innovative, commercially friendly, open-source ecosystem around the .NET platform." Littles joined the .NET Foundation board in August 2020. In his campaign pitch he spoke of a "serious disconnect in the .NET ecosystem" in that Microsoft promotes .NET open source but that the community around it is not healthy. "Maintainers of .NET OSS that Microsoft wants to help thrive are still in rough shape," he said. The sustainability of open-source projects was a key concern, as was expanding the .NET open-source ecosystem.

Littles resigned from the .NET Foundation board ahead of its elections in September. He intended to say nothing in public about it, but changed his mind when the foundation posted that "we wish him all the best as he refocuses on his personal life." Concerned friends contacted him, resulting in this post, where he explains some of the background to his resignation and said: "I am fine. No issue in my personal life took me away from the board." According to Littles' post, "the .NET Foundation was not concerned about its membership" and "hasn't been transparent with the community about anything." He asked the foundation: "Are you here to enforce Microsoft's will on .NET Open Source, or are you here to help foster and promote a healthy community?" He added: "The scoreboard doesn't look good for the latter... I watched Microsoft kill an Open Source Project, while my friends in the community demanded the Foundation say something, I felt powerless to do anything. It was clear the reasons I joined the Foundation weren't important."

We asked Littles about his experience of being on the board. He joined, he told us, with the awareness that the previous board "was not a fully functioning board... it didn't seem coherent, it didn't seem that it was a board moving towards a goal. They put up the maturity model which I had a very big issue with." Project Maturity was a pilot including "maturity profiles," designed to improve software quality. The project was abandoned shortly after its introduction after community members complained that it was over-reaching, with board member Ben Adams acknowledging that "we didn't then open this discussion up to all projects, to find out if it was acceptable to them, or if there was a better way. This was wrong." Littles told us: "My problem with the maturity model was it seemed too Microsoft bureaucratic... member projects would have to provide a service level agreement for consumers of those libraries... it was elitist and exclusionary. I felt the model should have been more about how do we open up a path for a small open-source library to go from a one-person labour of love to a library that the community can depend on? I felt the focus was more on overseeing and dictating versus nurturing and helping."

Microsoft engaged in some strange behavior with regard to its WinGet project, finding out all the details of an existing open-source project called AppGet by dangling the prospect of a job at Microsoft for its creator, but then in effect killing that open-source project though borrowing many of its ideas. Littles was more than disappointed. "The foundation, which is supposed to be the champion for open source, said nothing," Littles told us. "The foundation remained silent and to me, that was extremely loud... that is what made me wake up and realize the foundation doesn't care about the community or incidents like this... the community was in outrage behind this and the Foundation that's supposed to be Microsoft's open source arm said nothing." AppGet was not a .NET Foundation project, but Little felt that "if you're here for open source, you cannot be exclusionary, you cannot say it's not a foundation project so we don't care."

This week the Free Software Foundation (FSF) announced JShelter, "an anti-malware Web browser extension to mitigate potential threats from JavaScript, including fingerprinting, tracking, and data collection."

The browser add-on — supported by NLnet Foundation's Next Generation Internet (NGI) Zero Privacy & Trust Enhancing Technologies fund — is currently "in development and the first release is available." This browser add-on will limit the potential for JavaScript programs to do harmful actions by restricting default behavior and adding a layer of control... Accessing cookies, performing fingerprinting to track users across multiple sites, revealing the local network address, or capturing the user's input before they submit a form are some examples of JavaScript's capabilities that can be used in harmful ways. JShelter adds a safety layer that allows the user to choose if a certain action should be forbidden on a site, or if it should be allowed with restrictions, such as reducing the accuracy of geolocation to the city area. This layer can also aid as a countermeasure against attacks targeting the browser, operating system, or hardware levels... [The extension] will ask — globally or per site — if specific native functions provided by the JavaScript engine and the Document Object Model (DOM) are allowed by the user. It will also link to an explanatory page for each function, to raise awareness of related threats. Depending on the function being addressed, the user will have the option to allow it, block it, or have it return a custom value...

"Our browsers have become perhaps the most critical of tools we depend on, and yet the browser environment is far from healthy," says Michiel Leenaars, director of strategy at NLnet Foundation and coordinator of NGI Zero. "Dominant corporate behavior from a small amount of actors has been aggressively reshaping the evolution of the Web, and that is starting to wreak havoc. Despite an enormous systemic dependency, we as users have very little control over what browsers allow and share — leading to significant risk as the most powerful tools in the shed are essentially left unprotected for every casual Web site to abuse. JShelter is a great initiative to help empower us all, to help us gain better understanding and to better safeguard ourselves from obvious and otherwise unavoidable harm."

The effort is part of a larger, multi-year campaign from FSF on JavaScript on the Web started in 2013, which among others includes the development of GNU LibreJS and outreach to users and developers about nonfree software inside the browser. The GNU LibreJS extension detects JavaScript web labels and assists users with running only JavaScript distributed under a free software license, according to their ethical convictions and individual preferences.
"JShelter will help protect users from critical threats now, and contribute significantly to progress on the necessary longer-term cultural shift of moving away from nonfree JavaScript," said Ruben Rodriguez, former FSF chief technology officer.

"This is a project I've been looking forward to for years, tired of dealing with all kinds of potential antifeatures in the browsers I use and distribute, and having to figure out some countermeasure for them with configuration changes, patches or extensions. Being able to wrap the JavaScript engine in a layer of protection is a game changer."

An anonymous reader writes: This week saw the annual check-in with Linux creator Linus Torvalds at the Open Source Summit North America, this year held in Seattle (as well as virtually). Torvalds took the stage for the event's traditional half-hour of questions from Dirk Hohndel, an early Linux contributor (now also the chief open source officer and vice president at VMware) in an afternoon keynote session.... And the theme of community seemed to keep coming up — notably about what that community has ultimately taught Linus Torvalds. (For example, while Torvalds said he'd originally planned on naming the operating system Freax, "I am eternally grateful for two other people for having more taste than I did.")

But even then Linux was a project that "I probably would've left behind," Torvalds remembered, "if it was only up to me." Torvalds credits the larger community for its interest (and patches) "that just kept the motivation going. And here we are 30 years later, and it's still what keeps the motivation going. Because as far as I'm concerned, it's been done for 29 of those 30 years, and every single feature ever since has been about things that other people needed or wanted or were interested in."

Torvalds also says "I'm very proud of the fact that there's actually a fair number of people still involved with the kernel that came in in 1991 — I mean, literally 30 years ago.... I think that's a testament to how good the community, on the whole, has been, and how much fun it's been."

And Torvalds says you can see that sense of fun in discussions about writing some Linux kernel modules using Rust. "From a technical angle, does that make sense?" Torvalds asked. "Who knows. That's not the point. The point is for a project to stay interesting — and to stay fun — you have to play with it....

"Probably next year, we'll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel."
"I really love C," Torvalds said at one point. "I think C is a great language, and C is, to me, is really a way to control the hardware at a fairly low level..." Yet Torvalds also saw Hohndel's analogy that it can be like juggling chainsaws. As a long-time watcher of C, Torvalds knows that C's subtle type interactions "are not always logical" and "are pitfalls for pretty much anybody. And they're easy to overlook, and in the kernel that's not always a good thing." Torvalds called Rust "the first language I saw which looked like this might actually be a solution"

"2021 Is the Year of Linux on the Desktop," writes PC Magazine. "No, really..." Walk into any school now, and you'll see millions of Linux machines. They're called Chromebooks. For a free project launched 30 years ago today by one man in his spare time, it's an amazing feat.... Linux found its real niche — not as a political statement about "free software," but as a practical way to enable capable, low-cost machines for millions...

Chrome OS and Android are both based on the Linux kernel. They don't have the extra GNU software that distributions like Ubuntu have, but they're descended from Linus Torvalds' original work. Chromebooks are the fastest growing segment of the traditional PC market, according to Canalys. IDC points out that Canalys' estimates of 12 million Chromebooks shipped in Q1 2021 are only a fraction of the 63 million notebooks sold that quarter, but once again, they're where the growth is. Much of that is driven by schools, where Chromebooks dominate now. Schoolkids don't generally need a million apps' worth of generic computing power. They need inexpensive, rugged ways to log into Google Classroom. Linux came to the rescue, enabling cheap, light, easy-to-manage PCs that don't have the Swiss Army Knife cruft of Windows or the premium price of Macs...

One great thing about open-source hacker projects is that they can be taken in unexpected directions. Linux isn't controlled, so it can adapt, Darwinian-style. It was a little scurrying mammal in the time of the dinosaurs, and then the mobile-computing asteroid hit. Linux could evolve. Windows couldn't. When you're building something that fits in your hand and has to sip battery, you can't just keep throwing processors and storage at it. Microsoft had a tough time adapting its monstrous megakernel OS to the new, tiny world. But *nix platforms thrive there: Android (based on Linux) and iOS.
"Android and Chrome water down the Linux philosophy," the article argues, "but they are Linux..."

Does this make any long-time geeks feel vindicated? In the original submission wiredog (Slashdot reader #43,288) looks back to 1995, remembering that "my first Linux was RedHat 2.0 in the beige box, running the 0.95(?) kernel and the F Virtual Window Manager...

"It came with 2 books, a CD, and a boot floppy disk."

destinyland writes: A newly-released video at GNU.org shows an hour-long talk given by free software advocate Richard Stallman for the BigBlueBotton open source conference (which was held online last July). After a 14-minute clip from an earlier speech, Stallman answers questions from the audience — and the first question asked Stallman for his opinion about the AI Copilot [automated pair programming tool] developed for Microsoft's GitHub in collaboration with AI research and deployment company OpenAI.

Stallman's response?

There are many legal questions about Copilot whose answers I don't know, and maybe nobody knows. And it's likely some of theo depend on the country you're in [because of the copyright laws in those countries.] In the U.S. we won't be able to have reliable answers until there are court cases about it, and who knows how many years it'll take for those court cases to arise and be finally decided. So basically what we have is a gigantic amount of uncertainty.

Now the next thing is, what about morally? What can I say morally about Copilot? Well the basic idea seems okay. Why shouldn't a program be able to give you hints like that?

But there is one pitfall, which is that if you follow those hints, you might end up putting a substantial block of code copied from a GPL-covered program, written by someone else, or one hint after another after another after another — it adds up to a substantial amount of code, perhaps, with very little change, perhaps. And then you've infringed the GPL by releasing that code, unless your program is covered by the same versions — plural — of the GPL, in which case it would be permitted. But you might not even know that. Copilot might not tell you — it doesn't endeavor to inform you. So you're likely not to know. Which means Copilot is leading users — some of its users — into a pitfall. Well, they should fix it so it doesn't do that.

But basically, what can you expect from GitHub? GitHub gives people inadequate advice about what it means to choose a license. They tell you you can choose GPL version 2 or GPL version 3. I think they don't tell you that really you could choose GPL version 2 only, or GPL version 2 or later, or GPL version 3 only, or GPL version 3 or later — and those are four different choices. They give users different permissions over the future. So it's important to make each program say clearly which choice covers it. And GitHub doesn't tell you how to do that.

It doesn't tell you that you need to do that. Because the way you do that is with a licensed notice that is supposed to be in every source file. It's unreliable to put just one statement in a free program and say "This program is covered by such-and-such license." What happens if somebody copies one of the files into some other program which says it's covered by a different license? Now that program has been inaccurately mis-licensed, which is illegal and is going to mislead users. So any self-respecting — any repository that wants to be honest has to explain these things, not just tell people to make the licensing of each piece of code clear, but help users do so — make it easy.

So GitHub has had this enormous problem for all of its existence, and Copilot has the similar — a basically, vaguely similar sort of problem, in the same area. It's not exactly the same problem. I don't think that copying a snippet of a few lines of code infringes any license. I think it's de minimus. But I'm not a lawyer.

"Amazon Web Services on Thursday fulfilled its commitment to rename Amazon Elasticsearch Service with its expected new identity, Amazon OpenSearch Service," reports the Register in a new update on Amazon's ongoing battle over open source licensing: The name change was necessary because AWS and Elasticsearch BV fell out over the licensing of the Elasticsearch open source software and the eating of one another's lunch.... While AWS promises that OpenSearch Service APIs will be backward-compatible with the existing service APIs (open source Elasticsearch 7.10), meaning no backend or client app changes should be necessary, building against new OpenSearch Service features means there's no going back. AWS says that upgrading from existing Elasticsearch 6.x and 7.x managed clusters to OpenSearch is irreversible.

[According to a blog post by Channy Yun, principal developer advocate for AWS], OpenSearch 1.0 (the AWS fork) supports three features unavailable in the legacy Elasticsearch versions still supported in Amazon OpenSearch Service: Transforms, Data Streams, and Notebooks in OpenSearch Dashboards... Amazon OpenSearch Service incorporates various other capabilities not present in the open-source Elasticsearch code, like security integrations (Active Directory, etc), reporting, alerting, and other such things. Cloud provider lock-in can become an issue even when there's compatibility between hosted open source services and the projects they're based upon.

What started out as an exercise in copying, the most lucrative form of flattery, has become a race to differentiate, or — to use the words of former Microsoft VP Paul Martiz when telling Intel representatives in 1995 about how Microsoft would deal with Netscape — "Embrace, extend, extinguish."

"Asahi Linux for Apple M1 Macs is moving closer to reality," writes Slashdot reader TroysBucket.

An Asahi developer posted a detailed status update on Twitter. Linux enthusiast Bryan Lunduke offers this succinct summary:

- The Asahi Linux team has Linux (Debian, in this case) booting and usable with network support.

- They now have (very early) display drivers which "take full advantage of the display hardware."

- They have at least two base distributions — both Arch and Debian — working and functional (to some extent).

They also have, according to their latest update, "boot picker" support so that you can manually select which OS / Drive to boot from on the M1 Macs... I, for one, can't wait to see the first public, functional release of Asahi Linux — and will be following it extremely closely.

"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).