Again - refusing to use proprietary software and software with a "non-free" (FSF definition) license, has nothing to do with politics. It's a philosophy.

6 members found this post helpful.

I changed the license in java.SlackBuild so it should be OK once this next batch goes out.

4 members found this post helpful.

The philosofies are esentially abstract ways to look to the World. Points of view.

But when you try to implement them in real world, and do campaigns to convince peoples to follow them, they became either religions or politics.

Yes, both the Marxism and Confucianism are philosophies. But applying them in real life is something else.

1 members found this post helpful.

I am afraid that they have no issues with the java.SlackBuild licensing, and everyone agreed that your extra SlackBuilds are already perfectly valid "libre software" themselves.

But in their over-interpretation of the FSF's four freedoms, they dislike those SlackBuilds because them "helps" or "suggests" the usage of a "non-free" software.

2 members found this post helpful.

This is factually incorrect. I am not saying we are completely apolitical, but I can easily prove that we are much more than that. For example, our very first milestone was to categorize the licenses of all Slackware packages, and especially the ones with restrictions on use, distribution, and/or modification. This piece of documentation was instantly useful to all users of Slackware, as well as of every Slackware derivative. Regardless of where they stand politically, Slackware users are now able to see exactly which packages have which restrictions (without personally examining 1000+ packages), and it comes handy when they are trying to deploy the OS in a licensing-sensitive environment. This is especially true for users who deploy Slackware at a business, since violating the license terms in that environment can cost a lot of money. Please feel free to make an argument why this work was 100% politically motivated, even though its immediate and principal benefit was to the existing Slackware users.

And you would know all of that if you actually took time to read our documentation: what we did and what we plan on doing; so now I am suspecting you are fighting a strawperson.

And more broadly to the point of apolitical utility of deblobbing... If you still believe that using proprietary software, and especially closed-source blobs, does not affect your privacy and security, then you have no idea what you are talking about.

2 members found this post helpful.

Oh, now you try to make us to believe that you are so busy to think about Enterprise deployments of Slackware? As in Slackware Enterprise Linux?

So, what to do those Companies with Slackware?

Desktop? Then office deployments? Was widely discussed in this forum already, and I am pretty sure that there are issues much higher than your "blobs" on this deployment case. By its own politics, the Slackware lacks the LinuxPAM and Kerberos, and that's a really huge issue for offfice deployment, which make it unusable. Last time a widely known (by us) company tried to do that, the venture failed lamentably and the company finally switched to CentOS. Try to search about the Kiki Novacs adventures, in this very forum.

Server? A server deployment is a highly customized solution, and the main rule is: no software beyond purpose shall be deployed. IF the Company intends to deploy a web server, then even GCC and friends will be removed. Personally, I believe that there are huge problems, as Slackware has no clear package dependencies even in the form of some lists published in a website, so to create a Slackware solution for servers is really time consuming, then nobody use it. Because those Team Managers who has no will to pay a several months research when the same result can be obtained in several days using CentOS.

And there we can continue with many reasons WHY they do not use Slackware in the servers, but CentOS. And your "blobs" are highly likely the last reason.

Interesting and clear words. Your gods aren't The Four Freedoms, but the Almighty Dollar and Holly Rubla, and that's OK. I am happy for you, if you found a way to sell Slackware*.

BUT be honest about that and do not sell to us stories about freedoms and other shiny words. We are neither stupids or ignorant.

----------------------------------------
* But I bet that Patrick Volkerding will not be so happy if you abuse his trademarks.

mind linking to example threads concerning this "Kiki Novacs adventures"?

Do a simple search, it is impossible to not find out what you want. There was even mega-threads about.

This wasn't in regards to being able to deploy Slackware in an existing environment with permissions, logins, and whatnot, but rather trying to show that some software in Slackware specifically prohibits usage in a commercial setting. That is now documented and that software can be removed from Slackware installations in businesses to prevent legal issues.

This could be for a computer being used for a small business that only needs one computer to handle gnucash. This person can now be informed on what software they should remove to ensure they won't run into any legal trouble. Or it can be used in a highly-customized version of Slackware that includes kerberos and PAM... it still would legally require that software to be removed (and that wouldn't require deblobing the whole OS if that isn't their desire).

You're confusing licensing with accounts and permissions... both can be related to businesses, but qweasd was only referring to the former, not the latter.

And yes, people are free to ignore the licenses of software included with Slackware, but that still doesn't make it legal. It is at least documented so users can make their own decisions.

https://blog.microlinux.fr/slackware-centos/
https://www.linuxquestions.org/quest...os-4175609546/

1 members found this post helpful.

Is this reflected somewhere in a single database?

I do not confuse a thing. I only explained that someone who tries to use Slackware in Enterprise hits magnitude grades bigger issues than those imaginary blobs and radical bullshit.

Dear Frenemy, did you read those enormities you written here? Really?

So, now you question if Slackware is legal? and if is legal to use Slackware?

---------------------------------------------
IF your brains had been fried by only that amount of communist propaganda, I strongly suggest you to stay away of North Korea at any price.

Otherwise you may found yourself sincerely believing in the Juche idea and singing hymns about the Supreme Leader...

You really are confused. The data provided by Freenix can tell you what pieces of software you might run into legal issues with if you use it in a business setting. That does not have to go hand-in-hand with deblobbing the OS (although, it can if you're against that). And not everyone who would use Slackware in a business would run into issues like the lack of PAM/kerberos, although, some companies certainly could.

Wow... how'd you get to that? Maybe you should realize the second paragraph is directly relating to what I wrote in the first paragraph and the bottom one is in the same context as the other paragraphs. I'm not questioning the legality of Slackware. Everything included in Slackware is able to be included. However, some software have restrictions stating they aren't allowed to be used in a commercial environment. So, if you intend to use Slackware to make money, you may be in violation of the licenses of some software.

The CreativeCommons interpretes non-commercial to mean:

How to interprete that would be up to the lawyers (but before you pick apart that statement, read the page about non-commercial that I linked to... those are not my words and are simply copied from their site).

The software from Slackware that Freenix has documented as "Non-commerical only" is as follows:

• a/getty-ps
• ap/amp
• n/trn
• xap/xfractint
• xap/xgames
• xap/xv

If you decide to use any of the above software on a business computer, you may be violating the terms of the license, however, I am not a lawyer, so usage of this software should be reviewed by the company's legal team. The programs above, according to Freenix, are the only programs included in Slackware that could be affected by this. That business would be free to use everything else in Slackware if they want to, including the kernels and firmwares included in Slackware, without running into potential licensing restrictions.

2 members found this post helpful.

Even with nothing but free software installed on the disk, hardware components still run their own shady, obfuscated code.

It seems to be impossible to have unlimited access to everything on anything but a toy computer.

My hope is that projects like OpenSPARC will eventually gain enough momentum to turn into viable replacements to the likes of Intel and AMD.

2 members found this post helpful.

I don't know... maybe need to exclude EFI support from Freenix? Seriously.

How does the GPL-community view this?

If you do this, then I, for my part, can begin to split my kernel configurations files into "libre-linux-kernel" and "kernel". In addition I use aufs + reiser4 and do not use OSS. But this factor should not become a problem for you. :-)

P.S. To date, I have configs for 4.16.x and 4.14.x. Best regards, Ne01eX.