HyperWiki

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
en:philosophy:community_software [2024/07/02 12:48]
throgh [But you can rebrand for example programming-languages or other software?] 		en:philosophy:community_software [2024/07/03 15:09] (current)
throgh [But the FSF is listing some of your excluded and removed packages as free?]
Line 3: Line 3:
 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. 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.+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.
  
 ===== Where are the issues with companies and / or corporations? ===== ===== Where are the issues with companies and / or corporations? =====
Line 42: Line 43:
 ===== But the FSF is listing some of your excluded and removed packages as free? ===== ===== But the FSF is listing some of your excluded and removed packages as free? =====
  
-Yes, the FSF (Free Software Foundation) has their [[https://directory.fsf.org/wiki/Main_Page|own listings and directory for free and libre software]]. We do not always follow their reasonings, for example when it comes to [[https://wiki.hyperbola.info/doku.php?id=en:philosophy:trademarks|trademarks]] or when they ignore non-free licensed data ([[https://wiki.hyperbola.info/doku.php?id=en:philosophy:nonfunctional_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, 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.+Yes, the FSF (Free Software Foundation) has their [[https://directory.fsf.org/wiki/Main_Page|own listings and directory for free and libre software]]. We do not always follow their reasonings, for example when it comes to [[https://wiki.hyperbola.info/doku.php?id=en:philosophy:trademarks|trademarks]] or when they ignore non-free licensed data ([[https://wiki.hyperbola.info/doku.php?id=en:philosophy:nonfunctional_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.
  
 ===== But you can rebrand for example programming-languages or other software? ===== ===== But you can rebrand for example programming-languages or other software? =====
Line 48: Line 49:
 Yes, the FSF is listing reasonings for distribution: Yes, the FSF is listing reasonings for distribution:
  
-<code bash>+<code>
 Rules about how to package a modified version are acceptable, if they don't substantively limit your  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. freedom to release modified versions, or your freedom to make and use modified versions privately.
Line 56: Line 57:
 you're already making other changes to the program, so you won't have trouble making a few more. you're already making other changes to the program, so you won't have trouble making a few more.
 </code> </code>
 +(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. 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.
Line 63: Line 65:
 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. 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:
 +
 +<code>
 +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. 
 +</code>
 +
 +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.
 +
 +===== But what if a corporation makes a free program, under a free software license for selling free software, would you recognize this as non-free? =====
 +
 +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.
  
 ===== Conclusion ===== ===== Conclusion =====
Line 69: Line 92:
  
 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. 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!