Did MongoDB become non-free?
- Inicie sesión ou rexístrese para enviar comentarios
I am a translator!
That is not clear to me. FSF's licensing team is hopefully analyzing https://www.mongodb.com/licensing/server-side-public-license
this is surprising-- having looked through half of the license, it appears to be an alternative version of the agpl in purpose.
what i couldnt figure out is why they would create their own agpl. this page might provide the answer: https://www.mongodb.com/licensing/server-side-public-license/faq#why-are-we-changing
"The community needs a new open source license that builds on the spirit of the AGPL, but makes explicit the conditions for providing the software as a service."
supposedly, they want the agpl to do something that it doesnt explicitly do.
but it seems to be a copyleft license inspired by the agpl. im having trouble understanding the part about patents in particular, but if i had to guess i would say its a patent clause similar to (but perhaps in some way different than) the apache 2.0 license.
this looks like a free software license to me. i feel certain osi will approve it as an open source license.
of course i put far greater stock in what the fsf says about it, but i suspect they will classify it as a gpl-incompatible agpl-incompatible free software license, and continue to classify new versions of mongodb as free software. but license proliferation is unfortunate and most often unnecessary. to quote xkcd, now there are 15 standards.
In my view the license has several problems which make it non-free by https://www.gnu.org/philosophy/free-sw.html
Fortunately https://goodformcode.com/ exists which has forks from before the redis license change.
In my view the license has several problems which make it non-free by https://www.gnu.org/philosophy/free-sw.html
not to be obtuse, but this says absolutely nothing at all. i mean, im not disputing (in the least) that you have a point here, only whether youve told us what it is.
perhaps it is trivial to find such a problem with this license. as far as i can tell, the biggest problem is that it is redundant (and the agpl would probably do just as well. in every possible use of this alternative.) so thats one possible issue. but after combing through a good portion of the license, there was nothing that would seem to conflict with your url, unless you want to tell us what it is.
dont get me wrong, im very curious.
i went into this thinking the license would have some obvious flaw-- i had good enough reason to think id find something. but i didnt. the last time an issue came up like this-- with regards to some goofy license nasa and osi like, but the fsf says isnt a free software license, i was surprised that osi even approved it as meeting osd requirements. it seemed to against both the fsd and the osd, but they obviously let it slide. compare this to the cc0, where it is obviously gpl compatible (and the fsf says it is) but osi decided not to approve it. theyre ridiculous.
still cant find the flaw here. now i know your opinion about it, but im no closer to finding the reason fsf shouldnt put it on their list of free software licenses, even if they add "but its redundant and you would be better off using agpl." which i would agree with. if there are several problems, even one example of a possible issue would be great.
"not to be obtuse, but this says absolutely nothing at all. i mean, im not disputing (in the least) that you have a point here, only whether youve told us what it is."
I didn't intend to discuss the specific issues; only to mention that they exist.
But, I will point to http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003632.html
Looking at their comparison,[1] it's mostly the same as the AGPL; the main difference is in the changes to section 13. Some things that I note (though of course it should be noted that I'm not a lawyer or legal expert, so don't take this as legal advice or anything of the sort):
1. The SSPL puts the section 13 restriction on the use of unmodified versions, for some reason I can't comprehend. What exactly they hope to gain by requiring users to give back the exact same source code that they already have, I have no clue.
2. GPL compatibility has been removed.
3. They removed the "notwithstanding" key phrase at the beginning of section 13. Why, I haven't a clue. "Notwithstanding" is a legal term that, from my understanding, is intended to stop the text that follows from unintentionally conflicting with the rest of the license, by explicitly stating that the terms that follow it are not overridden by other terms in the license.
4. They replaced the network interaction wording with something that refers to "mak[ing] the functionality of the Program... available to third parties as a service". I note two things that this would result in: firstly, it opens up the door to interpretation over what the heck a "service" is. Secondly, it isn't just interaction over a network anymore; this seems like something that would extend to just someone handing you their computer for use, or a library offering use of their computers to patrons.
5. You're also required to hand over the source code for, and I quote, "all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available". That's a mouthful, but basically, they're saying you have to hand over source code for every single program involved in some way in your offering of the "service". Depending on how you interpret that, this could include the entire operating system you're running the program on, which incidentally makes it illegal to run a program under this license on a computer that has any proprietary software on it; after all: "If you cannot use, propagate or convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not use, propagate or convey it at all."
Point 5 is a big one, and it's in my opinion a good reason to consider the license proprietary. By essentially forbidding users from running any proprietary programs alongside the covered work on the same system if you offer a "service", Freedom 0 is effectively restricted, and this could be a really bad restriction depending on exactly how broadly a "service" is defined. You could possibly be prohibited, as I alluded to above, from lending your computer to a friend so they can use it for a while.
[1] https://webassets.mongodb.com/_com_assets/legal/SSPL-compared-to-AGPL.pdf
Point 5 also raises problems for programs that are free too because you're supposed to hand over all that stuff under the terms of the SSPL. The (A)GPL don't allow that. So if you have anything in your stack that you can't legally relicense to SSPL you'd have no way to comply with that license at all.
Also, the scope of point 5 represents a policy change by applying copyleft to things that are not derivative works under copyright. Copyright has been what gives the (A)GPL its teeth. The traditional way of enforcing copyleft has been with a copyright-based lawsuit when someone fails to comply. Because copyright covers derivative works and once the license terminates for noncompliance you're really just left with a copyright infringement situation. But, if you're extending this to other things that don't qualify as a derivative work under copyright and so doesn't have the teeth of copyright behind it, it's not clear to me what recourse someone might have if not copyright.
Both of these matters should have been discussed by consulting/collaborating with copyleft experts before doing this. But they didn't. Bradley Kuhn's email goes over all of that stuff very well.
"By essentially forbidding users from running any proprietary programs alongside the covered work on the same system if you offer a "service", Freedom 0 is effectively restricted"
i make the same argument about linux-libre all the time, and no one takes this seriously.
its not actually a freedom problem "per se" since you can always recompile linux-libre without the part that does this-- connochaet os and debian (and void) do that, so the kernel has no non-free parts but it handles missing non-free firmware differently.
its also different because the problem is program-based, not in the license. however, oliva states this is a bug in linux-libre, doesnt think it can be resolved, but still a problem, and i think it is an instance where the fsf requirement to "not induce" the user to install non-free software actually limits your ability to run non-free modules in a way that is artificial and added to the program. it is an undesired side-effect.
no ones saying that you should run non-free modules, or that gnu/linux has to support them. gnu/linux does support them though. i would happily delete ndiswrapper from a system, as there are no free drivers that it supports that cant be ported to gnu/linux.
only that i think freedom 0 outweighs "do not induce" when it has this cost for the requirement for fully-free distros, i have specifically said this is a freedom 0 issue (rms doesnt agree with the argument, so thats settled i guess. it is his fsd after all) but its irrelevant that you can repackage non-free modules that do work with linux-libre to make them work, because no one is ever going to do that. the only people who are going to use non-free modules are going to use the debian or void or connochaet os kernel, if they dont want the kernel to contain lots of non-free stuff.
i dont use non-free firmware, i dont want to use it, but i do prefer the debian/connochaet os/void solution because it doesnt throw the option out the window (imagine if gnu/linux only ran free-licensed software and blocked all else)
generally i appreciate "do not induce," like when the browser says you need adobe. no you dont. but thats application level, not kernel level. and i think they put freedom 0 too far down on the totem for this one, when it has to be this way to get approved in the first place.
note i agree with whats being said about point 5, although i bet that interpretation will be disregarded and made irrelevant. i still think this license is unnecessary, i dont like license proliferation (which can usually be avoided by not making absurd assumptions about the license that supposedly needs adapting.)
the short version is, i think "do not induce" should be taken into consideration, but fixing the do not induce problem in mozilla web browsers doesnt prevent loading non-free plugins. if it prevents loading non-free firmware, freedom 0 should come before "do not induce" which isnt even part of the 4 freedoms (the 4 freedoms should weigh more than the fully free requirements-- whenever its one or the other, freedom 0 should win.) just my opinion though.
You can't compare a technical limitation to a license restriction. Linux-libre does not restrict your right to run proprietary software. It just has a bug that prevents some proprietary software, and also potentially some libre software (as was the case briefly when Think Penguin released its RYF wireless adapters), from running without modifying and recompiling it.
"You can't compare a technical limitation to a license restriction."
i specifically said this myself. my argument isnt that its the same argument-- the one about the technical limitation is a weaker argument and the one about the license restriction is stronger.
however, for me the one about the technical limitation predates this license issue. i dont expect people to agree with me on linux-libre of course-- nor expect them to think its the same level of freedom 0 problem as when its in a license, where a similar problem is more definite.
"Linux-libre does not restrict your right to run proprietary software. It just has a bug that prevents some proprietary software,"
it doesnt restrict your right-- it just restricts you. yes, theres a difference. but its the reason i prefer debians kernel to trisquels, even though the debian one (as of squeeze) wouldnt exist if linux-libre hadnt first. theres no way to say any of this without someone coming back and saying "youre not really restricted though." i get it. youre not really restricted. only almost, sort of, but actually sort of not. i still think its one of the 4 freedoms taking a back seat while "do not induce" goes on a joyride through the neighborhood, and i know which priority matters more to me. lets squash that though and say the freedom to run non-free software never applies. its practically a contradiction. but then we can make a software license that forbids running non-free software, cant we?
no. but we almost could.
what we really end up saying is a lot closer to: "the freedom to run non-free software isnt relevant unless its in a license. only then does stopping people from running non-free software make a thing non-free."
which could be true, but damn it is awkward to make the justification for sometimes. what i prefer, strongly, is to just say "the 4 freedoms are the ones that count first and foremost to free software. anything peripheral to that (fully free distro requirements) is worth adding whenever possible-- except when the 4 freedoms have to take a back seat because of it." that way i dont feel so much like its trying to square a circle-- just being as free as possible without arbitrary or competing limitations.
it is pretty much what i do say. no one else does, but id like to know if the author of connochaet os feels that way. note he tried to get fsf fully-free approval, i dont think he could.
> it doesnt restrict your right-- it just restricts you.
No, it does not restrict you. If Linux-libre "restricts" you from running proprietary firmware blobs, then literally every program that has ever existed "restricts" you from doing the infinite number of things they are not capable of doing. For example, you could say that the GIMP "restricts" you from uploading imagined pictures directly from your brain, or that LibreOffice "restricts" you from making OOXML files that are 1:1 compatible with Microsoft Office, or that Brasero "restricts" you from making DVDs with CSS encryption. This is all nonsense.
A restriction is when something is specifically designed to prevent the user from doing something, like when DVD players are specifically designed to not let you skip to the movie, or when a video player is specifically designed to prevent you from saving a copy of the video it plays, or when a copyright license specifically forbids you from using the program as you wish.
"No, it does not restrict you."
then the bug in linux-libre does not exist. however, the linux-libre author himself says that it does, which you are willing to dismiss as nonsense because youre getting it from me-- i didnt come up with it myself, and take it on pretty good authority that it isnt nonsense.
nor are its author and i the only two people interested in a solution to it. over a few years, several people have tried to figure out a way fix this restriction you say doesnt exist. if their website wasnt so hard to navigate, id link you a discussion on it.
i do get that it sounds like other things which are not actually restrictions. those are beside the point and not actually good metaphors for this.
"A restriction is when something is specifically designed"
this is just imposing a particular definition (or incomplete definition) of a word on an argument. it attempts to negate and it fails to be complete or even accurate. plus, note i said "restrict" not "restriction."
the rings on soda cans are not designed to restrict the movement of sealife, but they certainly do restrict them. theres no disputing that. linux-libre does not intentionally restrict the user from running non-free software-- but it probably does so more effectively than this license will in practice.
so heres the real argument you are making to me-- and im being very careful not to misrepresent your argument, though you may certainly disagree:
"a License that restricts the running of non-free software in theory (but not necessarily in practice,) is more 'restrictive' than a Program that restricts the running of non-free software in practice (but not necessarily in theory.)"
i really cant fully agree with that argument! i can sort of be quiet about it, i can comment on it here and then throw my hands up and say "oh well," or i can claim ive refuted it. i am planning on the second option. but i tried.
i almost never buy 6-packs of anything, but i always cut the rings. down the middle and along each side.
then the bug in linux-libre does not exist.
The bug exists. But it is not a freedom 0 issue, as you wrote. If a missing feature were a freedom 0 issue, then no software would ever give freedom 0 and there would be, by definition, no free software. Being able to load external firmware is a feature, not a freedom. Like accessibility is a feature, security is a feature, localization is a feature, user-friendliness is a feature, etc. Sure missing one of those features makes some usages impossible. For some users, the program even becomes useless. But it does not restricts them (using onpon4's definition: it does not harm the freedoms of the user). It is only imperfect. Imperfection is not the same as oppression: https://www.gnu.org/philosophy/imperfection-isnt-oppression.html
ok, thats really well stated. i mean its basically flawless. even the side points and supporting links are fair and relevant.
it does at least side step the main point im making, which is that it significantly reduces an already-existing feature (the ability to load non-free plugins into the kernel) for the sake of something that isnt in the 4 freedoms (do not induce the user, a requirement of fsdg) but i dont think anyone could make a more solid rebuttal than you have.
so perhaps "restrict" is too strong a word, but it certainly decreases the amount of leeway the user has in the software they run. if we were starting from a new program that doesnt do anything, you certainly couldnt call it a restriction that it doesnt bother implementing something. that would be silly, and of course i wouldnt make that argument. which i think is what most people want to rebutt, but yours was pretty spot-on.
and yes, the bug exists-- my own solution is to throw the "do not induce" requirement under the bus in the very rare instance that it drastically affects functionality. i dont want to sacrifice any of the 4 freedoms for functionality-- but i will sacrifice "do not induce" for existing functionality in a rare instance like this. by comparison-- no fsf/free-software-friendly adaptation of firefox fails to load non-free plugins if you tell it to. it just stops advertising them, which i think is an improvement because "do not induce" is a very good idea, with very few exceptions ever. and even those are disputed, eh?
i look forward to learning more about this license with regards to suitability/free software status. i still think it is probably unnecessary, agpl would do just as well. this license probably fits an entire class of "open source" licenses we could call "me too" licenses. they cause needless proliferation and that means the license itself could be used as a very low-grade, relatively low-impact weapon against software freedom. im not completely sure about the point 5 that was made-- it relies on an interpretation that will likely never be made in practice, and thus never actually apply, but in theory it makes it a lousy license and certainly poorly worded, which is not a thing you want in a license-- but im open to the possibility.
"i still think it is probably unnecessary, agpl would do just as well."
Probably not for their purposes, which seems to be to sell proprietary licenses to those that use the software in a for-profit way.
maybe thats the real reason open source has so many "me too" versions of free software licenses.
Wow, this has really gone off topic from the original post but I'd like to point out three things.
One is that the Linux-libre project goes beyond making Linux free. The goal is to make it GNU FSDG-compliant. That brings "inducing" in scope for the project.
I consider it that is indeed not an existing function in Linux-libre. You seem to be looking to Linux and seeing it present but they're not the same functionality. Linux has firmware loading. Linux-libre wants firmware loading without inducing when the proprietary junk's not present, which Linux doesn't have. It has firmware loading with inducement. They're not exactly the same functionality.
It's a very hard feature to implement; otherwise it would have been implemented long ago. There are partial patches in the mailing list archives. Rather than complaining about a hard thing not being implemented, patches are welcome. Then you can see just how deep the rabbit hole goes. :)
Third, the whole notion that Linux-libre won't load proprietary junk in the first place is really false. If someone really did want to do run proprietary junk with Linux-libre without the full solution implemented it is not hard. It only requires editing of a few lines in a single file and nothing more. I'll leave the what where and how as an exercise for the reader. An interested person should have absolutely zero problem in determining exactly what that is and then running their proprietary junk. And so, I don't feel swayed by your arguments since it is so easy to do.
> The goal is to make it GNU FSDG-compliant. That brings "inducing" in scope for the project.
yes.
> Linux-libre wants firmware loading without inducing when the proprietary junk's not present, which Linux doesn't have. It has firmware loading with inducement. They're not exactly the same functionality.
lets be clear about this, i dont want it to have any functionality that alex oliva doesnt want it to have. i may point this out in a way that makes it seem otherwise, but thats why i am clarifying that point.
> It's a very hard feature to implement; otherwise it would have been implemented long ago. There are partial patches in the mailing list archives.
i understand this. indeed one of the reasons i bring it up (other than a loose comparison to a similar outcome of a very difference process/circumstance in this thread) is because i was a proponent of linux-libre (and trisquel) in the past, and i would like more people to know about this issue. no one is sure its possible to implement a fix ever, but a lot of people dont know about it so a fix is less likely.
> Rather than complaining about a hard thing not being implemented, patches are welcome. Then you can see just how deep the rabbit hole goes. :)
oh no, ive looked. ive talked to oliva about it. his pessimism is mine and if he were more optimistic i would be too.
> Third, the whole notion that Linux-libre won't load proprietary junk in the first place is really false.
in practice, in practice. i know there is a way to do in theory that absolutely would never happen. id love to be wrong, because thats the other way to solve this (which is also why i talk about it.)
> It only requires editing of a few lines in a single file and nothing more. I'll leave the what where and how as an exercise for the reader. An interested person should have absolutely zero problem in determining exactly what that is and then running their proprietary junk.
to be honest, i have no idea what that is. but since this probably isnt the place for it, i will send an email to a place that im likely to get a reply.
> And so, I don't feel swayed by your arguments since it is so easy to do.
its a pity i dont have the details to be swayed by your argument, because it sounds like you (might) have enough information to relieve me of this notion altogether.
ive personally been interested in coding since the fsf was about 2 years old. that makes me younger than a lot of kernel hackers. ive been interested in gnu/linux since the late 90s and free software for more than a decade.
i do try to be as accurate and reasonable (and in the know) about as many of these issues as possible-- since the people i advocate to are not just online, but everywhere i go.
i have nothing to gain by being wrong about any of this, it makes part of my life a whole lot easier if youre right. feel free to email me about this and tell me what those few lines are. or, i will keep researching this and find out eventually. then i can give people more accurate information about linux-libre. i would be very happy to do so.
...unless you mean recompiling the kernel. because that just gives you a kernel exactly like the one in debian, and that kernel with no non-free parts that loads non-free firmware already exists in multiple distro families. i hope thats not your answer, because it is simply the longer way to get to precisely the one i already offer people. it wouldnt change a thing. did you mean there is a way to do it with the linux-libre kernel in trisquel, without recompiling it?
> recompiling
Right. Linux doesn't have a way to change firmware loading behavior on demand. That's a technical limitation in the kernel at present. Whether recompiling is needed or not doesn't matter; it just goes to my point that the notion that Linux-libre won't load proprietary junk in the first place is really false. Anyone that wants to change how it works, such as inventing some new thing to do wonderful magical firmware things, involve a recompile. Like: Maybe they write up some new code to go download needed firmware over the internet automatically without asking. That will need recompiling. Unless now you're going to want another new feature in Linux-libre? :)
> because that just gives you a kernel exactly like the one in debian
So? Linux-libre predates Debian's kernel efforts. Once they started cleaning up their act, Linux-libre became superfluous? That's the feeling I get when I read things like this. It strikes me as "Debian came along and re-solved the problem over again so Linux-libre isn't needed anymore." But: I see http://www.fsfla.org/ikiwiki/selibre/linux-libre/ more as a replacement for kernel.org, which is still needed. So it's operating at another level than a specific distro. And, I'm chiming in to comment on the firmware loading point of it only. Which seems pretty well covered at this point.
"Whether recompiling is needed or not doesn't matter; it just goes to my point that the notion that Linux-libre won't load proprietary junk in the first place is really false."
cmon, this is sophistry. linux-libre is compiled in a way that removes an ability, of course you can recompile it (again) to regain that ability-- but then it wouldnt be linux-libre.
plus it is entirely unnecessary to do that, since other distros already do it (but dont have the non-free parts.) so the solution i give people for running non-free software IS THE SAME AS YOURS but with one step fewer. the only difference is-- mine isnt linux-libre, but you claim it is. we wouldnt meander so much around these topics if you werent dancing around simple facts like this. i feel like youre toying with me more than being honest-- however, i dont doubt your sincerity. i think you really believe what youre saying.
its fine, i happen to think theres another way, but its more trouble than just using a different kernel, and ive asked alex oliva already if he can remind me what it is.
but your answer is just bunk. its not not only impractical, its self-contradicting and partially imaginary. if you do it, it isnt linux-libre. its linux again, without the non-free parts. more accurately, its the debian kernel. its the void linux kernel. or the connochaet os kernel. its a lot more trivial than recompiling-- just use a different kernel without non-free parts (the same thing youd get if you recompiled.) what banana said was more to the point, and harder to argue with. you couldve left it there, i was happy to. shouldnt we?
on a more positive note, i would like to give distro-libre users who have removed all non-free parts of devuan (as i have a script that automatically cleans it now) the option of installing your linux-libre for devuan too. i dont know why the trisquel kernel wont work for that (too old?) but i dont care, your kernel is recommended by this community. so if youd like to email me about that or start a thread (or point me to instructions) id be genuinely interested in making it easier to add to devuan (live.) im assuming its in a .deb package and installation is trivial, but i dont know where it is. i will most likely search it out myself eventually.
How easy or hard it is to modify Linux-libre to make it run that firmware is immaterial to the point. It's a technical limitation (one that no one who uses the program really cares much about, mind), not a freedom issue.
There's a reason modifying Linux-libre to run proprietary firmware doesn't happen: because there's already a Linux kernel with blobs, called the Linux kernel. Why waste effort adding blobs to a deblobbed Linux kernel when you can just get the original Linux kernel with blobs? It would be like modifying a pre-OOXML version of OpenOffice to add OOXML support when you can much more easily just grab the latest version of LibreOffice, or modifying GNOME 2 to add GNOME Shell when you can just use GNOME 3, or modifying GNOME 3 to use Metacity instead of Mutter when you can just use MATE. Heck, there are programs that won't even compile anymore on modern systems because they rely on old compiler bugs and bad practices; does that mean that the new compilers leave you less free? Of course not. Just because a program isn't ideal for a particular job doesn't mean you lose freedom by using it, and just because people don't modify a program in a particular way doesn't mean they can't; often they just don't want to.
Why waste effort adding blobs to a deblobbed Linux kernel when you can just get the original Linux kernel with blobs?
for one, because i dont trust non-free code, and it is definitely better for both security and freedom to minimise unvetted code running with root-level access.
because a free kernel with one non-free firmware is probably better than a kernel with lots of non-free firmware. not necessarily! but lets not kid ourselves. plus, if you go and get a proper wireless adapter for example, you dont have to recompile or reinstall the kernel, which many real-life users dont feel (or arent) up to doing. you just remove the driver, and youre 100% free. thats why. i mean, it shouldnt need to be explained, but you asked. starting with a free kernel is a better idea whether you do it for freedom or not. go ahead, disagree.
i personally prefer, and generally recommend, that people go fully free whenever they can (better always.) i have to go just as much trouble to explain why to them as i have to go to to get a straight answer about something here.
heres what happens though-- all or nothing. if i use just one non-free driver, im basically told i might as well use the vanilla kernel, when theres a kernel that is much closer to linux-libre than the vanilla one. i understand why, but thats what this all or nothing does.
if i use one non-free driver, i might as well use the vanilla kernel. if i use the vanilla kernel, i might as well use ubuntu. if i use ubuntu, i might as well use windows. the "we dont care about freedom" people have their own version of that argument, but i didnt move to gnu/linux, i migrated gradually. and linux-libre doesnt offer that as a path. not because of 4 freedoms-- but because of do not induce.
but short of "all" there are much better options than "nothing." because of do not induce, we have to all pretend like that isnt true. which is what people are doing-- either not knowing the real answer or knowing and pretending.
i really dont like "do not induce" when its absolute. its free softwares version of the nda. if you want to be fully free, you agree not to disclose certain information about other software. even if you want to.
so much better as a guideline than a rule. as a rule, it leads to absurdities. without it as a guideline, freedom would suffer a lot. but being better as a guideline doesnt change the fact that its a rule, does it?
so all or nothing it is. but im still not going to use windows-- or the vanilla kernel. or ubuntu, per se. (im not even using non-free modules. but i still prefer being able to give people relatively straight answers, which is why i will never try for fully-free status.)
wherever you find do not induce, you find people working on things in relative secrecy (talking about it openly while working but only openly to fellow developers, not to users-- as a rule.) thats a fact, which you interpret in different words.
wherever you find do not induce, you find people dancing around the things they have agreed not to talk about. outsiders dont understand, and you can try to explain, but its a remarkably similar communication process as speaking as a member of a regime. open secrets, taboos, routes around the topic. this is how social justice works, but not science. science has to be able to weigh details openly, not just decide for everyone and talk like undesirable details dont exist. activism, not science.
but you volunteer all that, so its cool. its not censorship if you volunteer. its choosing what not to say, and then finding ways to say things based on that choice. just like everyone does when theyre fully free.
but no matter how you dance, the debian kernel has all 4 freedoms-- it has the same amount of non-free software linux-libre does.
but on a forum where you cant recommend non-free, im told if i use a debian kernel that has no non-free parts, or recompile linux-libre to be like the debian kernel, i might as well use the one that has non-free parts.
and conflating "induce" with installing non-free (as if theres no difference, when one has only free software and the other doesnt) gets a +1. i didnt tell anyone to install non-free anything. i said sometimes its better to use a (free) kernel that lets you.
but someone told me i might as well use non-free then-- and that got a +1.
it may not be censorship, but it definitely harms the ability to have logical arguments the way actual censorship would. because people are doing a silly dance around facts, and making fallacies that fit the local fiction better than the reality of fully free software that isnt fsdg-compatible.
none of this silliness would have happened without do not induce. the 4 freedoms are fine. do not induce isnt freedom though, its a way to protect freedom that makes perfect sense until it goes too far and starts to get ridiculous. which is what happens when you test ideas for merit (you find out when they really work and when they dont) instead of just believing or following rules. guidelines are great. you couldnt have too many of those.
guidelines let you do stupid things-- with rules though, you agree to do things even when you know theyre stupid. thats why we cant have a real conversation here, we have to go somewhere else to speak openly about kernels (with nothing non-free in them!) alright. (no, not ubuntu land. theyre still worse.) give the guy telling me i might as well use the vanilla kernel another +1 though, id do it myself though i havent made that feature work yet.
im done here. the occasional ignorance and the well-intended dishonesty is starting to tip the balance over the fantastic intelligence you can find here on a regular basis.
theres far more intelligence than stupidity going on here-- however, we are being all or nothing after all, and the stupid (and the strawman, and the equivocation, and the lack of honesty) is still too much. i totally blame rms for this. hes one of the most brilliant people on earth, truly.
brilliant people sometimes do dumb things. this is all the fruit of one of his dumbest ideas. but the 4 freedoms are some of his very best. they dont deserve a back seat to this nonsense. have fun.
> for one, because i dont trust non-free code, and it is definitely better for both security and freedom to minimise unvetted code running with root-level access.
Perhaps this is your itch to scratch, then, so to speak. If you care about a missing feature in a libre program like Linux-libre, you have the freedom to add that feature. That's the point: your freedom isn't being hindered, you're just unsatisfied with the program.
Most people either want all blobs (maximum functionality) or no blobs (maximum freedom). So my rhetorical question about why someone would want to modify Linux-libre to add blobs back in was a demonstration of why it just doesn't happen, i.e. that it's the choice of users.
> heres what happens though-- all or nothing. if i use just one non-free driver, im basically told i might as well use the vanilla kernel, when theres a kernel that is much closer to linux-libre than the vanilla one. i understand why, but thats what this all or nothing does.
So? Being among people who disagree with you does not limit your freedom. Diversity of opinion is perfectly normal in a free society.
> but no matter how you dance, the debian kernel has all 4 freedoms-- it has the same amount of non-free software linux-libre does.
Of course. Here you demonstrate yet another reason why no one has made the decision to fix this very unimportant bug in Linux-libre we're talking about. Why modify a program to do a job when just using another almost identical program already does so?
> but on a forum where you cant recommend non-free, im told if i use a debian kernel that has no non-free parts, or recompile linux-libre to be like the debian kernel, i might as well use the one that has non-free parts.
Oh? I didn't see such a post. But so what? People are allowed to think things that you disagree with. I have many, many disagreements with many others on this forum, and I don't consider that to be a problem.
> none of this silliness would have happened without do not induce.
Oddly enough, this is a point I actually agree with you on: I think the GNU FSDG is too far-reaching in this regard, and I've said as much in the past (though I don't remember where). But that is immaterial with regard to whether or not Linux-libre gives you the same amount of freedom as Debian's Linux kernel. Agree with GNU FSDG or not, it's the purpose of Linux-libre and the reason why it has the long-standing bug we're talking about.
> brilliant people sometimes do dumb things. this is all the fruit of one of his dumbest ideas.
I think you haven't spent enough time on stallman.org if you think the "inducement" clause of GNU FSDG is one of RMS's dumbest ideas. It doesn't come even close. One of his recent things is using the made-up pronouns "person", "per", and "pers" in an effort to be "gender neutral" and avoid even perfectly traditional uses of singular "they" (those being when the identity of the person you're talking about is unknown, when you're talking about no one in particular, and when you're talking about several people at once in the singular tense).
- Inicie sesión ou rexístrese para enviar comentarios