FSF Joins Bluesky, Discourages Sign-Ups Over Nonfree JS

The Free Software Foundation (FSF), an organization promoting free software, has opened an official account on the decentralized microblogging service Bluesky. Reporting by Slashdot’s EditorDavid, citing the FSF’s own announcement, said the launch took place this week. The aim is to deliver information where users gather. At the same time, it declined to recommend new sign-ups. The reason is that running nonfree JavaScript during the registration process is unavoidable.

FSF Announces Bluesky Launch

The FSF announced its participation in Bluesky in an official announcement. It positions it as a communication channel alongside its existing Mastodon presence. It called on supporters to follow it on both.

If you’re on social media, follow the FSF on Bluesky and on Mastodon today.

In his reporting, Slashdot’s EditorDavid quoted this call from the FSF’s blog. According to that report, Slashdot itself also has a presence on Bluesky. There is a growing trend of organizations distributing their messages without favoring a specific protocol. The FSF’s decision is part of that trend.

The aim of participating is to expand the reach of its advocacy. It seeks to reach people who have never encountered the idea of free software. It also considered the difference from other large services that the FSF views as more problematic. It judged Bluesky to be a comparatively better option. The tension between principle and outreach is at the heart of this case.

Technical Reasons for Not Recommending

New Sign-Ups

The FSF made clear its position of not recommending new sign-ups for Bluesky. This differs from its treatment of sign-ups for Mastodon or PeerTube. The reason is that the registration page requires loading nonfree JavaScript.

We can’t advocate that you sign up for a Bluesky account like we do with Mastodon or PeerTube since signing up for Bluesky means loading the registration page’s nonfree JavaScript…

Under the FSF’s criteria, what matters is whether the code running on the user’s machine is free. The freedoms to run, copy, modify, and share must be ensured. Because the code on the registration page does not meet that condition, it cannot recommend it. A similar problem remains with the web client as a whole. The FSF considers that this harms freedom on the user’s side.

There is also a caveat regarding client options. The FSF said it has prepared its own instructions for specific uses. It explained that it has not examined all commercial or public clients. Whether free clients exist remains unverified. Users themselves must verify.

Structural Differences Between AT Protocol

and ActivityPub

Bluesky has a federated architecture. However, it is generally not considered part of the so-called fediverse. It uses the AT Protocol, separate from ActivityPub adopted by Mastodon and PeerTube. The difference in protocols becomes a barrier to interoperability. The mechanisms for posting, following, and migration are also separate systems.

This difference has practical implications for engineers. Knowledge of ActivityPub does not directly carry over. The design philosophies for key management, identifiers, and relays differ. Operating and auditing procedures must also be learned separately. Supporting multiple protocols increases the burden on organizations.

Regarding developments around testing infrastructure for free software, there is also discussion in GNOME OS Test Center, Inspired by Apple TestFlight. Verification of clients and transparency of distribution have become challenges. The client issue on Bluesky is a related concern. Public availability of code and freedom at runtime are separate issues.

Self-Hosting Burden and the Gap in Freedom

Much of Bluesky’s code is published under free licenses. Broad portions can be run, copied, modified, and shared. The FSF acknowledges this point. The publication of the code itself is a positive element.

However, the burden of self-hosting is heavy. Self-hosting a Personal Data Server (PDS), a personal data repository, or a relay is technically possible. The FSF explained that it is more difficult and resource-intensive than setting up a Mastodon instance. The gap widens further compared with lightweight ActivityPub-compatible services such as Akkoma and Starling. It is a high barrier for a small organization to handle alone.

As shown in Linux 7.3 to Bring Stable Support for Intel Nova Lake-S Integrated GPUs, free infrastructure is maintained through steady integration work. A design that can be self-hosted is different from a design that is easy to self-host. The prevailing view is that Bluesky remains at the former. Operational realities shape how it spreads.

Decision to Balance Expanded Reach with Principles

Why did the FSF join despite being aware of the constraints? The reason is the need to reach people where they are. Staying only in free spaces would fail to reach unexposed audiences. Its mission as an advocacy organization drove the decision.

We accepted running Bluesky’s nonfree JavaScript a single time if it meant being able to reach people who have never heard of software freedom.

It began publishing after allowing a one-time execution. It accepted running nonfree code limited to the single occasion of registration. It distinguished this from recommending ongoing use. Rather than bending its principles, it separated their scope of application. It does not hide that it was a difficult choice.

This approach could spread to other organizations. It is a method of separating multi-channel outreach from endorsement of sign-ups. It primarily encourages users to follow it on Mastodon. For those already on Bluesky, it provides an additional point of contact. It is an attempt to pursue both the protection of freedom and expanded reach.

Editorial Opinion

In the short term, we expect simultaneous posting to multiple protocols by nonprofits and public institutions to expand. Growth in users on the Bluesky side and maintenance on the Mastodon side will proceed in parallel, increasing operational loads. Verification work around the handling of code on registration pages will also become more active.

In the long term, we expect the focus to be on developing migration and viewing tools between AT Protocol and ActivityPub. Whether clients that allow use without nonfree JavaScript exist will affect choices. Understanding of the difference between the scope of free code and freedom at runtime will also deepen.

As the editorial team, we believe the question is how to measure the balance between expanding reach and upholding principles. Will the logic of allowing a one-time execution extend to other situations? Who bears responsibility for protecting user-side freedom — the operator, the organization, or the user?

References

• “FSF is Now on Bluesky - But Won’t Advocate Signing Up Due to Nonfree JavaScript”, by EditorDavid — Slashdot, 2026-09-05T22:34:00.000Z (ARR)
• Source URL: https://news.slashdot.org/story/26/09/05/0452205/fsf-is-now-on-bluesky---but-wont-advocate-signing-up-due-to-nonfree-javascript?utm_source=rss1.0mainlinkanon&utm_medium=feed