On-going in different articles we have mentioned community-oriented and -driven software. So within this article we want to give an overview what and how we understand this phrase.

We understand the mentioned phrase and wording to be used for free, libre and permissive licensed software-projects being most time only developed within a community of people, not with any kind of company and / or corporation behind. A trademark included is under these conditions most time used only to protect the project itself and not to misuse it further against interested individuals or groups to prevent modification, build and share the software itself.

Hyperbola is defining free, libre software and culture in combination with a ground base of altruism. This means also that people are acting on behalf for their own good but also the good of the group and community. Using this understanding means that free, libre software is done on behalf for the good of all beings to have data and information in their own hands and to have also full control of their system. We call this technical emancipation as software should be written by users from users, not from companies and / or corporations and granted afterwards some rights to the users - leaving any further change for the future questionable. Projects with a company and / or corporation have a clear course for:

• breaking portability
• ignoring backwards compatibility
• replacing existing services

All of this forcing into adoption of the software itself and making other projects and systems complete depending only on that special project.

Per definition any company and / or corporation has no common understanding of ethics and moral, also no understanding to protect the privacy and security for the greater good of all beings. Acting on behalf of laws does not automatically include acting per definition good or morally intact following ethical standards. So Hyperbola concluded as project that the inclusion of projects with a corporate background is not following our definition and understanding of what free, libre software should grant.

Especially trademarks in usage can lead in our perspective to further issues, when it comes to rights granted for free, libre and permissive licensed software. Yes, it is clearly to be seen also that licenses on the one hand and trademarks on the other hand are also to be separated. Nevertheless companies and / or corporations have proven not to be oriented towards some kind of fair usage or friendly tolerance. In fact it is more clear to be seen that free, libre software is in a dangerous position when only adapting definitions instead of redefinition own stances against trendings to use too harsh and strict trademarks. Examples are here Java, Rust or PHP.

In fact: Companies and / or corporations only pretend to support as they are only interested to have most flexible support for their products and productions and people being active in their so-called projects are most time cheap workforces.

To rely on solutions and implementations from companies and / or corporations may work, but also the opposite. There are enough reported cases, where people are even experiencing legal issues and prosecution for just reporting severe problems within the security. Instead of working together companies and / or corporations see within those a better method for “solving” issues. Hyperbola as project see therefore no point to include those projects, even when they offer some free and permissive licenses same as we see trademarks.

As result of those noted perspectives Hyperbola is only including community-oriented software-projects with corresponding licensing. All others are complete marked as incompatible and being removed or rejected right from the base of Hyperbola as system-distribution and operating-system. Examples of removed und further unsupported packages are:

• zstd: Meta / Facebook is behind this project, https://facebook.github.io/zstd/
• protobuf: Alphabet / Google is behind this project, https://protobuf.dev/
• redis: Redis Ltd. is behind this project, https://redis.io/
• syslog-ng: One Identitiy LLC. is behind this project, https://www.syslog-ng.com/

We have already written here clearly that we talk about community-oriented software and projects. Nevertheless people will for sure misuse this reasoning and complain that we then should even remove most drivers and more. Please read again: We have not written here any single word about some special piece of code and only described our stance towards community-oriented software. We have even given clear examples about opposite projects and why we declined their integration in our system-distribution and project. So our definition is neither unclear nor incoherent. We just reject projects with the clear to be seen major focus coming from companies and corporations. But for some people everything fits to be used for accusations. Even the used question for this section, which is another example of bad framing.

And that is what this question exactly is about: Bad framing used to silence people when they point out the issues with more integration of company-projects. As long as the license somewhat fits everything works out also in the generic perspective and therefore the majority within the free and libre community is not interested to hear counterpart arguments. The problems coming for sure are ignored, same as for clear arguments also.

Yes, the FSF (Free Software Foundation) has their own listings and directory for free and libre software. We do not always follow their reasonings, for example when it comes to trademarks or when they ignore non-free licensed data (non-functional data). This does not mean that we redefine freedom or “free and libre software” in general. We just point out that we see issues and therefore do not further bother into reworking packages with trademark-issues or other problematic fields. If you do not see that same way, it is sure your own opinion to do so. But demanding from us to follow only one definition of free and libre software or otherwise accusing us to confuse the people is not working out. A movement should be able to endure a diverse landscape of motivations for user freedom and when a project alike Hyperbola has taken its own way to be clearly more strict this is nothing harmful. Accusations towards the project or individuals within the team is not really helpful when based on this point, but when you see a point for discussion you can also take the advantage to get in touch with us direct. It is quite more helpful debating issues direct instead of us reading them and nevertheless trying to explain endless as some people seem just to enter a place to feel annoyed and take the moment to let everyone know. If that is the reasoning of free, libre software, we should think again and just finally work together to make a real new paradigm, instead of being a cheap excuse to follow only egoistic motivations.

Yes, the FSF is listing reasonings for distribution:

Rules about how to package a modified version are acceptable, if they don't substantively limit your 
freedom to release modified versions, or your freedom to make and use modified versions privately.
Thus, it is acceptable for the license to require that you change the name of the modified version,
remove a logo, or identify your modifications as yours. As long as these requirements are not so
burdensome that they effectively hamper you from releasing your changes, they are acceptable;
you're already making other changes to the program, so you won't have trouble making a few more.

(Source: https://www.gnu.org/philosophy/free-sw.en.html#packaging)

The used wording “burdensome” is vague defined and left for further interpretation: Is it burdensome to modify a complete programming language alike Rust with all binaries, documentation, code-basics, comments in sources mentioning the name and also source-files with mentioning names? Yes, for small system-projects like Hyperbola this is “burdensome”. Is it “burdensome” to rebrand all packages with trademark-issues being identified and not leaving this open likewise Python or Perl? Yes, same problematic. We have already taken stance here multiple times that we have not the intention to package alternatives and rebrand packages as patching includes also every new release made. Hyperbola has a complete different focus and intention, a complete different roadmap and is not a common GNU/Linux-system as leaving those areas in the near future for a complete own BSD-implementation. To argument with such intentions that we could rebrand Rust, PHP, OpenJDK and more with ease is simple not possible for us and a point we will never do.

It is also easy to state and demand a rebranding while being not so easy in the end when this rebranding is also needed to be reviewed later on by copyright-holding projects for example. And this is included in the issues we point out when exactly talking about this: Every rebranding would need a later review and the permission from the original project upstream. At worst for every new release and Hyperbola has neither the time nor the man-power doing this.

Besides the definition of the FSF ignores clearly the awaitings of users resulting in even more issues and problems rising when systems need to patch out data and possible issues with some features likewise also URLs for downloading additional data as example. We do not patch and rebrand, when there is no real need.

And the quote from the FSF is going also further:

Rules that “if you make your version available in this way, you must make it available in that way also”
can be acceptable too, on the same condition. An example of such an acceptable rule is
one saying that if you have distributed a modified version and a previous developer asks for a
copy of it, you must send  one.
(Note that such a rule still leaves you the choice of whether to distribute your version at all.)
Rules that require release of source code to the users for versions that you
put into public use are also acceptable. 

Because this means in fact that Hyperbola would need to do several forks from upstream and that amount of work is again to underline impossible for small system-projects. In fact the FSF has written those principles with good intention, but also with ignoring the amount of rising complexity. Exactly that complexity Hyperbola rejects and is not oriented on. What “acceptable” means is not to be defined by the FSF, only by the projects doing so. And to accept “open-source” (as most big projects are going this way) is not working for Hyperbola. Same way to accept to “ask for permission”: This should not be acceptable, when it is on demand as process everytime again. Please remember that we would than need to stay on pair with upstream and rebrand everytime again. In theory all of that sounds like not so much work, but the reality is quite different.

No, we do not recognize anything further than the license is telling. But in that case we do not include that software-project. The reasoning is therefore: We are nevertheless talking about possible trademarks, possible restrictions added to the license later on or the license is changed complete. When the software is then elementary dependency for other we have more work than before removing this instead being sure to have a safe way forward with a community-oriented project under a free, libre and permissive licensing.

We respect the decisions of other systems for sure, but we just ask for respecting also our decision to not include software and not use software therefore. It is a decision of the system to include and package software, or leaving this out for a reasoning. We can make a difference between the theoretical license in usage, the practical development and creation of a software-project and the further outcome in the time to come. And no one can assure that copyright-holders, maintainers and others may not change the used license in the future at any given point. If that happens there is always a chance for a fork being done, but in the practical doing this happens not that often and resulting forks bear also the risk to vanish afterwards quite fast with no perspective for the future. So please understand: We do not redefine anything, we accept and acknowledge the used license, but we just leave that package and software complete out as it is not based on our values and principles.

Following our values and principles means the free and libre software is exactly not only made out of the reasoning to earn more money, instead it is done to give back the control to users. So here is the second point of that question answered: We do not and will not accept projects providing individual rights about solidarity and common good. And we do not put the right of the majority above the protection of minorities. Free and libre software is done out of altruistic motivation, not alone out of pragmatism. Giving something back so all people can participate technical emancipation and are in full control of their running system.

Hyperbola as project only supports software-projects with a clear focus from the community for the community. If we see that software-projects and resulting packages develop further into the direction being only focussed on a company and coorperate background, we are going to remove it and rebuild dependending packages. Free, libre software and culture is from our perspective better when companies and corporations are kept outside!

The problem here is that more and more projects depend on those making them mandatory as users are not questioning those also. For Hyperbola the freedom of choice is most important, so there is also a choice not to use some package or force others to install and use it.

And demands from the FSF to do more “acceptable” work, is ignored here for a clear reasoning: Before demanding such, people should know their rights and possibilities. To demand something needs knowledge doing so and not to await something coming right out of nothing. The target of Hyperbola is freedom, but minimalistic and with technical emancipation!