interesting - i just look into this a bit

probably in most cases, the person writing those description is not thinking at all of making any distinction between the kernel and the OS - probably in most cases where the word "linux" appears as referring to the kernel itself it is usually stated as "the linux kernel" probably in most cases where the only the word "linux" appears and not "the linux kernel" it probably applies appropriately to the OS "GNU/Linux"

here is a more useful command for this purpose:

pacman -Ss ' linux ' | grep -v 'ernel' | grep -v 'GNU/Linux'

that returns 79 packages so perhaps this request is feasible

note that some descriptions such as the one for LMMS ("The Linux MultiMedia Studio") should not be altered because that is merely stating the formal name of the program - changing it to ("The GNU/Linux MultiMedia Studio") would be incorrect unless the upstream renamed the project to "GLMMS"

bill-auger wrote:

note that some descriptions such as the one for LMMS ("The Linux MultiMedia Studio") should not be altered because that is merely stating the formal name of the program - changing it to ("The GNU/Linux MultiMedia Studio") would be incorrect unless the upstream renamed the project to "GLMMS"

i'm not completely on-board with this logic. i would say renaming whole projects would be extremely cumbersome, but not necessarily incorrect. if saying "Linux" for things other than the kernel is an error, then it remains an error regardless of whether the mistake is made by Arch or upstream.

i am not saying that those names are correct - they are inappropriate names assigned by people who probably do not know that - but i can draw a clear analogy much like the archlinux misnomer - "Linux" in this context is not a general description - it is a formal name of the project - it would be a different situation if the description said "this program is made for linux operating system" but i am only talking about when it says "the name of this program is Linux Multi Media Studio" - it is an unfortunate name but that statement is true because the name of that program IS in fact "Linux Multi Media Studio"

what if the name of the program's author was "Fred Linux"? would it be appropriate to re-write the git commit history changing every instance of his name with "Fred GnuLinux"?

let's say for the sake of argument that your parents named you isabelle instead of isaac - you might contend that this was an error on the grounds that isabelle is a girl's name and most people would agree - then it may bother you so much that you start telling people that your name is fred and many of those same poeple will start calling you fred - but IN FACT your name is NOT fred - it is isabelle - now, it is true that "belle" as a stand-alone word does have the meaning of "girl" but "isabelle" as a name is not intending to be a description of what the nature of that person "is" - telling people that your name is actually fred is, by definition, "incorrect" unless you first officially change your name to fred

but that analogy does not acurately capture this scenario - in that analogy, you would have every right to re-name yourself - but this is more like a third person other than you or your parents, such as me, deciding to call you fred only because it is my belief that your parents made an error; even if you object because you like the name isabelle and want to be called isabelle - you have every right to call yourself isabelle regardless of whether any other person finds it dis-tasteful - if i persist in calling you fred against your wish, that is an indefensible position for me to take

i think that in order for the suggestion of changing the names of such programs to be reasonable then parabola would need to fork those programs and probably sift through the source hunting down and changing all references to "linux" - that could be done but i think that only changing the name is inappropriate and misleading to users

i will also add that the name of the program really has no place in the description - it is just redundant there and indicates lack of imagination or pure laziness of the packager; so probably all such cases are moot - the description should be changed in all such cases to something that meaningfully describes the functionality

i will add one other obvious alternateve which is to drop those programs entirely - this would be my second choice - first i would ask the upstream to change their name voluntarily - then secondly i would drop my support for that program if they refused - much as my opinion on the archlinux misnomer is simply stop using the words "arch" or "archlinux" - strike every mention of either from view and just call parabola "a pacman-based libre distro""

IDK if getting that paranoic with the name (they are just descriptions, they won't harm your freedom), but this should definitively go for [libre] and [pcr] packages. For example:

pcr/mkinitcpio-paralogo 0.r24.g1e12097-1
Add colored Parabola Linux ASCII art logo to early boot process

or

pcr/util-linux-nosystemd 2.30.1-2 [instalado]
Miscellaneous system utilities for Linux


both are in [pcr], and all those packages come directly from Parabola Hackers (many are taken from AUR, but not all), so IMO our packages should fix the descriptions (because filter packages from Arch and rebuild them just for changing a description I think it's too much, but it's worthy in the case of [libre] packages)

An example of what I say is openshot

nonprism/openshot 2.3.1-1.parabola1.nonprism1
a free, non-linear video editor for GNU/Linux based on MLT framework, without nonfree faac recommendation and Youtube uploader support
libre/openshot 2.4.0-1.parabola1
a free, non-linear video editor for GNU/Linux based on MLT framework, without nonfree faac recommendation

While in Arch it says:
an open-source, non-linear video editor for Linux based on MLT framework

bill-auger wrote:

i am not saying that those names are correct

i sense inconsistency. you very strongly imply they are correct when you say:

changing it to ("The GNU/Linux MultiMedia Studio") would be incorrect

so if i understand your correctly, you think they are in fact incorrect, but also think that trying to correct them is incorrect (i.e., that the correct name is also incorrect). :S

let's continue...

i am only talking about when it says "the name of this program is Linux Multi Media Studio" - it is an unfortunate name but that statement is true because the name of that program IS in fact "Linux Multi Media Studio"

i don't contend the truth of the statement: "the name of this program is Linux Multi Media Studio". it's only the name "Linux Multi Media Studio" itself that is called into question (assuming "GNU/Linux" applies to this scenario, I'm not even familiar with LMMS). i could come up with factually wrong names for everything and anything, then popularize them to the point where these are taught at school as though their meanings were true; and according to you it would be wrong to even try to course-correct, because, "hey, that's actually what they are called!"

moving on with the analogy to people's names, here are the flaws i see:

1. those aren't factual claims, they are only agreed-upon labels. "isabelle" is no equivalent to a descriptive name of the sorts of "Please refer to me as His Majesty from outer space, because that's what I am". heck, a law could even be made to refer to me as such.
2. legal recognition is irrelevant to the matter. if "fred" became my de facto name tomorrow, then it would also be my name in a very strong sense. you don't need more than usage to call something a name (or that's what i understand by "name").
3. there's no law (physical or otherwise) that limits the number of names a thing can have to just one. if a group of people started calling me fred while my legal name is isabelle, then there are valid senses in which each of them is in fact one of my names.

ok i think we really are mostly in agreement - the statement: "the name of this program is Linux Multi Media Studio" is a true factual statement; but the name: "Linux Multi Media Studio" is unfortunately misleading - where we are diverging is whether or not it is appropriate for a downstream to change the name without making any meaningful functional changes - i personally would view this as shady attempt to mis-represent it's true identity which is disrespectful to it's authors - i would prefer to dis-associate myself from it than to be so pretentious as to call it by a name that it's authors do not approve of

it is true that alternate names can be just as practically useful as the real names but these are not "The Official Canaonical Names" - they are pseudonyms or nick-names and should not be confused as anything formal - the names of package is formal and canonical - you would not want to rename 'linux-libre' package to 'freed-nix' or 'gnu-linux-libre' just becuase you think it is a better name - would you? - there is one very subtle point you raised with: "hey, that's actually what they are called!" - the crucial thing is that this is not incidentally "what people call it" - it is a proper formal legally copyrighted name - "nix" is just a slang term "what people call it" that does not truly refer to anything in particular; but "Linux" is a very formal legal entity with a very specfic identity - if it were a proprietary program it may even be illegal to change it - and if it were trademarked it may be mandatory to change it - in either of those cases parabola probably would not carry it - in any case it is not clear what would be the appropriate name if not one that is designated by the authors - it would lead people to wonder "what is this "GMMS GNU Studio" - i have never heard of that before" - and no wonder why - because no such program actually exists

iceweasel for example diverges in notable ways from firefox so a distinct name is very appropriate - this is why i suggest either to fork these poorly named programs and make some truly significant functional changes to them before renaming - or save the hassle and drop them entirely

megver says:

"rebuild them just for changing a description I think it's too much" 

as i said before, that is is actually only 79 packages so perhaps this request is feasible; but another things to say is that i think the GNU distro guideliness may actually require it - for example there was recently some discussion around the evaluation of the connochaetos distro where the last major flaw it had preventing it from being approved was that when it's kernel tried to load some blob but found it was missing, the names of those blobs would be logged to a file like: "unable to load: 'b43'" - that was enough to disqualify the distro and the developer had to obscure those names in the logs to satisfy the guidelines

another things to say is that i think the GNU distro guideliness may actually require it

If that was the case, then we should also blacklist packages which refer to "open source" instead of "free software" in their pkgdesc.

I know we block hundreds of packages, however there are more prioritary ones to maintain, but as I already said, we can do this with packages from [libre] and [pcr].

Megver83 wrote:

If that was the case, then we should also blacklist packages which refer to "open source" instead of "free software" in their pkgdesc.

I know we block hundreds of packages, however there are more prioritary ones to maintain, but as I already said, we can do this with packages from [libre] and [pcr].

I think this discussion has finally pointed the core of our problem:

Do we have the right to tell people how they should pronounce this or that ?
Is this our freedom of expression, or is this infringement to their ?
Is it ethic to propagate our ideas by concealing other's ideas ?

I think we have to position ourself about that, in order to unashamedly apply what we ruled.

• If we think that the best way to express how important user's freedom is for us, is to replace systematically every bad wordings in packages names and descriptions, then we must do that. For every packages. But should we stop ourselves here ? Shouldn't we also update their documentations, man-pages, user interfaces, etc. ?

• If we think that it's not our right nor our role to rename packages, disturbing both upstream developers and users, then we must not do that. Apart from OUR packages, of course, as said Megver83, because we do have the "right" to decide which will be their names and descriptions.

If somebody disagrees with both propositions, then s.he should put forward precises criteria for processing any (every) contentious cases.

i'm reading through the FSDG, and what seems to be good news to me is that it doesn't insist on hunting the "Linux instead of GNU+Linux" misnomer down to every place and corner. it asks for avoiding mistakes like this in general, though. still, i wouldn't shed a tear if someone stepped up to change those descriptions and maintain the affected packages.

bill-auger wrote:

where we are diverging is whether or not it is appropriate for a downstream to change the name without making any meaningful functional changes

why not? i would expect others to be free to name my works (or even myself) the way they see fit, even if i don't like it. this occurs all the time and is for the most part irrelevant to everyone (authors included):

• piano sonata 14 -> moonlight sonata
• ARPANET -> internet
• Compilers: Principles, Techniques, and Tools -> Dragon Book
• etc.

and i don't see why it wouldn't be obvious to everyone that sometimes the author won't do a good job in that domain.

i personally would view this as shady attempt to mis-represent it's true identity which is disrespectful to it's authors - i would prefer to dis-associate myself from it than to be so pretentious as to call it by a name that it's authors do not approve of

this is absolutely hilarious, because it describes word-for-word what those authors are doing (perhaps without malice) to the GNU project and others, by calling them with a pars pro toto. i'm not even advocating to force them to recognise GNU, i would simply prefer if we didn't spread the mistake.

there is one very subtle point you raised with: "hey, that's actually what they are called!" - the crucial thing is that this is not incidentally "what people call it" - it is a proper formal legally copyrighted name

IANAL, but no, it is not.[0] names aren't even eligible for copyright. perhaps you are thinking of trademarks.

[0]: https://en.wikipedia.org/wiki/Copyright#Rights_granted

"Linux" is a very formal legal entity with a very specfic identity

only true for trademarks (idk where "Linux" is registered and therefore valid). moreover, the Linux trademark holders have no say on whether we don't want to use that name as part of the name of a separate product (e.g. LMMS); and clearly they don't have a say on whether we wanna go with a different name (e.g. Linux-libre) for the very product trademarked as "Linux" (many kernel developers will say firmware is not part of the kernel when confronted with the fact that Linux is not fully free, which entails that Linux-libre is true pure Linux with a different name, in their minds). if anything, projects like LMMS are at risk of being sued for using a trademarked name.

if it were a proprietary program[...]

no point in bringing proprietary software in

[...]it may even be illegal to change it

unless you can point to us that some free software's license prohibits us to call it by other name, then this is not worth discussing. GNU may as well start demanding users of their software that they use "GNU/Linux", forcing all distros to follow suit as they try to distribute LMMS.

and if it were trademarked it may be mandatory to change it

great, trademarks don't prevent us from using another name. no blocker here.

it would lead people to wonder "what is this "GMMS GNU Studio" - i have never heard of that before"

i share this concern. however, there are ways to attain clarification without seizing upon proper names. Descriptions like "The Linux MultiMedia Studio" could become "The Linux MultiMedia Studio, an audio workstation for GNU+Linux". I've used this compromise before on the wiki.

and no wonder why - because no such program actually exists

it would exist, but only to the extent that we make it real.

iceweasel for example diverges in notable ways from firefox so a distinct name is very appropriate

would it legally or morally matter if it were identical to standard firefox? i think this example also plays on my side, if the answer is "no".

this is why i suggest either to fork these poorly named programs and make some truly significant functional changes to them before renaming

with all respect, i think this would be a bad idea and a waste of time. there's no need to make changes to function, and i see no moral obligation to make up an excuse that would justify a name change. it's probably within our right to change names anyway; and as i explained above, appending a clarification to descriptions could be more than enough.

or save the hassle and drop them entirely

why?, no. we want free software, we like having a free distro like Parabola, even if that involves tweaking things around. i mean, if we followed this policy our repositories would empty the moment every free software project starts using the misnomer.

the FSDG asks for avoiding mistakes like this in general

i think it is that "in general" bit that they used against connochatos - i dont think the FSDG explicitly says "do not mention names of proprietary software" nor "you must say free-software and never opensource" but they gave connochatos a very hard time about these details - as i remember those are the only problems that were ever found with the distro and they were corrected promptly yet after 7 years it still has not been approved

i would simply prefer if we didn't spread the mistake.

thats basically my opinion too except that i am not so willing to go out of my way to plaster over someone else's mistakes - i would sooner kick them to the curb and move on if they will not fix their own errors - there is an abundance of free software around - i dont think i would be exaggerating to say that every example of a program in parabola repos with "linux" in the name could probably be replaced tomorrow with 3 programs with identical functionality that do not have "linux" in the name - though i suspect those duplicates already are available in the repos - LMMS for example is a no-brainer - it could simply be dropped and parabola would still have the 'ardour' and 'qtractor' DAW programs

"The Linux MultiMedia Studio, an audio workstation for GNU+Linux"

i like this very much - it get straight to the heart of the matter - it clearly indicates the distinction that "The Linux MultiMedia Studio (LMMS)" is just an arbitrary name and not a description of "what it is" - and that "what it is" is "an audio workstation for the GNU+Linux operating system" - and i repeat here that the program name really has no place in the description - it is redundant there - it is not even important to mention GNU/Linux in any package description is it? clearly, all parabola packages run on GNU/Linux - also, that particular program has a windows port (ironically) - that reduces a perfectly adequate description for that program to "A digital audio workstation"

would it legally or morally matter?
it's probably within our right to change names anyway

the only reason i brought up trademark and legal names is just to say that names are not trivial or arbitrary - names are very important for the identity of formal groups - would you approve of someone that redistributes parabola as ArchLinuxLibre if they added absolutely nothing original to it? i would hope not, because people could easily confuse that for a completely separate project - i am really not trying to speak of legality or morality - im quite sure we have every right to change the names of those programs just as we can change the source code - my view is that it is, at best, pretentious "activism" with little practical benefit - but others could easily see it as lousy spiteful behavior - in any case the most practical effect of this would be confusion

i suggest to post a list of those programs with "linux" in the program name to determine what functionality would be lost from a parabola system if they were all simply dropped and who would actually object to their absence - i suspect that very little or nothing would be lost and very few users or none would complain - if even one person complained "what happened to LMMS? thats my favorite program" then it may be worth considering to build it or fork it to make the terminology changes - but seriously we may have already spent more time discussing these program names than is worth what little value can come of changing them

removing "linux" from the package descriptions is another issue but not so contentious, only time consuming - but again i think a strong argument could be passed upstream that program names are redundant in the descriptions and the word "linux" is not relevant in the description at all unless it is describing a kernel module or utility - otherwise, a userland program "for linux" most likely means only that it has not been ported to any other platform yet

bill-auger wrote:

i think it is that "in general" bit that they used against connochatos - i dont think the FSDG explicitly says "do not mention names of proprietary software" nor "you must say free-software and never opensource"

it explicitly states that nonfree software/firmware shouldn't be recommended. logging nonfree firmware names was considered enough of a recommendation. this is on a whole different level to simply confusing the name of one free project with another.

they gave connochatos a very hard time about these details - as i remember those are the only problems that were ever found with the distro and they were corrected promptly yet after 7 years it still has not been approved

because the authors didn't bother to re-apply; they expressed they don't want to, in fact. connochaetos' case doesn't establish precedents regarding misnomers, afaict.

my view is that it is, at best, pretentious "activism" with little practical benefit - but others could easily see it as lousy spiteful behavior

the same is said about many other aspects of the FSDG, and 100% free distros in general. what matters is whether Parabola is doing the right thing, in light of the FSDG.

i am not so willing to go out of my way to plaster over someone else's mistakes - i would sooner kick them to the curb and move on if they will not fix their own errors

i guess you are against collaborative software development and forks too... i mean, a big part of what Parabola does is stepping over, what we consider are, Arch's mistakes.

there is an abundance of free software around - i dont think i would be exaggerating to say that every example of a program in parabola repos with "linux" in the name could probably be replaced tomorrow with 3 programs with identical functionality that do not have "linux" in the name

it's not about the pkgname per se, but descriptions. would you rather tell cinnamon and lmms users to fuck off over having a hypothetical Parabola maintainer drop a "GNU" in their descriptions? Consider how much effort Arch has put in packaging that software.

i suggest to post a list of those programs with "linux" in the program name to determine what functionality would be lost from a parabola system if they were all simply dropped

this is definitely the way to go about it. I prepend a ? to descriptions that I'm unsure whether they refer to the kernel.

extra/avahi:: Service Discovery for Linux using mDNS/DNS-SD -- compatible with Bonjour
? extra/brltty:: Braille display driver for Linux/Unix
? extra/flatpak:: Linux application sandboxing and distribution framework (formerly xdg-app)
  extra/ibus:: Next Generation Input Bus for Linux
  extra/ladspa:: Linux Audio Developer's Simple Plugin API (LADSPA)
  extra/libimobiledevice:: Library that talks the protocols to support iPhone and iPod Touch devices on Linux
  extra/lirc:: Linux Infrared Remote Control utilities
? extra/nss_ldap:: The nss_ldap module provides the means for Linux and Solaris workstations to resolve the entities defined in RFC 2307 from LDAP directories.
  extra/tomboy:: Desktop note-taking application for Linux and Unix
  extra/wicd:: Wired and wireless network manager for Linux
  extra/wicd-gtk:: Wired and wireless network manager for Linux - GTK client
? community/android-udev:: Udev rules to connect Android devices to your linux box
  community/antiword:: A free MS Word reader for Linux and RISC OS
  community/backuppc:: Enterprise-grade system for backing up Linux, Windows and MacOS PCs
? community/bluez-tools:: A set of tools to manage Bluetooth devices for Linux
  community/bsd-games:: Linux port of the collection of BSD command line games
? community/btchip-udev:: Udev rules to connect BTChip wallet to your linux box
  community/checksec:: Tool designed to test which standard Linux OS and PaX security features are being used
  community/cinnamon:: Linux desktop which provides advanced innovative features and a traditional user experience
  community/clamtk:: Easy to use, light-weight, on-demand virus scanner for Linux systems
? community/cutter:: TCP/IP Connection cutting on Linux Firewalls and Routers
? community/cwiid:: Linux Nintendo Wiimote interface
  community/deepin-account-faces:: Account faces for Linux Deepin
  community/deepin-control-center:: New control center for linux deepin
  community/deepin-notifications:: System notifications for linuxdeepin desktop environment
  community/deepin-screenshot:: Easy-to-use screenshot tool for linuxdeepin desktop environment
  community/fasm:: Fast and efficient self-assembling x86 assembler for DOS, Windows and Linux operating systems
  community/fcitx-mozc:: Fcitx Module of A Japanese Input Method for Chromium OS, Windows, Mac and Linux (the Open Source Edition of Google Japanese Input)
  community/gmerlin:: Multimedia architecture for Linux
? community/gufw:: Uncomplicated way to manage your Linux firewall
? community/heaptrack:: A heap memory profiler for Linux
  community/hexedit:: Hex Editor for Linux
? community/i2c-tools:: Heterogeneous set of I2C tools for Linux that used to be part of lm-sensors
? community/i7z:: A better i7 (and now i3, i5) reporting tool for Linux
? community/igmpproxy:: a simple multicast router for Linux only using the IGMP protocol
? community/ipsec-tools:: KAME IPSec tools ported to Linux
? community/isapnptools:: Allow ISA Plug-And-Play devices to be configured on a Linux machine
? community/isatapd:: Creates and maintains an ISATAP tunnel (rfc5214) in Linux
  community/keepass:: A easy-to-use password manager for Windows, Linux, Mac OS X and mobile devices.
  community/libiodbc:: Independent Open DataBase Connectivity for Linux
  community/linssid:: Graphical wireless scanner for Linux
? community/linuxtv-dvb-apps:: Linux DVB API applications and utilities
? community/lmms:: The Linux MultiMedia Studio.
? community/lxc:: Linux Containers
  community/lynis:: Security and system auditing tool to harden Unix/Linux systems
  community/man-pages-de:: German Linux man pages
  community/nmon:: AIX & Linux Performance Monitoring tool
  community/oprofile:: System-wide profiler for Linux systems
? community/packeth:: A Linux GUI packet generator tool for ethernet.
? community/pflask:: Lightweight process containers for Linux
  community/pkgdiff:: A tool for analyzing changes in Linux software packages
  community/python-distro:: Linux OS platform information API
? community/python-pyinotify:: Python module used for monitoring filesystems events on Linux platforms with inotify.
  community/python2-distro:: Linux OS platform information API
? community/python2-pam:: Module that provides an authenticate function that allows the caller to authenticate a given username / password against the PAM system on Linux.
? community/python2-pyinotify:: Python module used for monitoring filesystems events on Linux platforms with inotify.
  community/qlandkartegt:: Use your GPS with Linux
  community/snownews:: Text mode RSS newsreader for Linux and Unix.
  community/spice-vdagent:: Spice agent for Linux guests
  community/squashfs-tools:: Tools for squashfs, a highly compressed read-only filesystem for Linux.
? community/tenshi:: real-time log monitor from the Gentoo Linux project
  community/tilda:: A Gtk based drop down terminal for Linux and Unix
? community/tinyserial:: Small minicom replacement for accessing serial ports on Linux inspired by FreeBSD 'tip'
  community/udpxy:: small-footprint UNIX/Linux daemon to relay multicast UDP traffic to client's TCP (HTTP) connection.
? community/usb_modeswitch:: Activating switchable USB devices on Linux.
? community/ussp-push:: OBEX object pusher for Linux
  community/wireshark-cli:: a free network protocol analyzer for Unix/Linux and Windows - CLI version
  community/wireshark-gtk:: a free network protocol analyzer for Unix/Linux and Windows - GTK frontend
  community/wireshark-qt:: a free network protocol analyzer for Unix/Linux and Windows - Qt frontend
? community/wxcam:: Webcam application for linux
  community/xwax:: Open-source vinyl emulation software for Linux.
? pcr/apparmor:: Linux application security framework - mandatory access control for programs (metapackage)
? pcr/evrouter:: An Input Event Router for Linux
? pcr/laptop-mode-tools:: Power Savings tool for Linux
? pcr/lcmc:: Linux Cluster Management Console
 pcr/minicomputer:: A standalone Linux softwaresynthesizer for creating experimental electronic sounds.
 pcr/mkinitcpio-paralogo:: Add colored Parabola Linux ASCII art logo to early boot process
? pcr/multipath-tools:: Multipath tools for Linux (including kpartx)
  pcr/openswan:: Open Source implementation of IPsec for the Linux operating system
? pcr/psad:: A collection of three lightweight system daemons (two main daemons and one helper daemon) that run on Linux machines and analyze iptables log messages to detect port scans and other suspicious traffic
? pcr/spectrum3d:: An audio spectrum analyser in 3D for Linux

generated with expac -Ss '%r/%n:: %d' | grep -E '::.* [Ll]inux' | grep -vE '([Kk]ernel|GNU|gnu|-[Ll]ibre|Arch)' and removals from my part.

the program name really has no place in the description - it is redundant there

that's right often times (expanding acronyms sounds like a sensible exception, specially if the result is a description). namcap warns against repeating pkgname verbatim in pkgdesc.

it is not even important to mention GNU/Linux in any package description is it? clearly, all parabola packages run on GNU/Linux - also, that particular program has a windows port (ironically) - that reduces a perfectly adequate description for that program to "A digital audio workstation"

some pkgdescs list many OSes. redundant still, but redundancy is a digression from the topic under discussion. "A digital audio workstation" would be a perfectly fine new description in all regards, but it would miss the opportunity to explain what's wrong with the 'L' in LMMS.

would you approve of someone that redistributes parabola as ArchLinuxLibre if they added absolutely nothing original to it? i would hope not, because people could easily confuse that for a completely separate project

a problem would be born regardless of whether changes are poured in that fork,[0] yet it wouldn't be my fault. in any case, you have narrowed the realm of possibilities under consideration to one that is specially bad, possibly to try to sway those who will lose track from this move. i wouldn't commend such an unfortunate choice, but in the process, i wouldn't declare that the act of renaming always produces bad outcomes and therefore should be frowned upon. the thing is, we are responsible for our own use of language. we can either acquiesce or try to do better.

[0]: https://www.gnu.org/distros/free-system-distribution-guidelines.en.html#name-confusion

removing "linux" from the package descriptions is another issue but not so contentious, only time consuming

i was under the impression that this issue was about descriptions (it also naturally extends to in-program UI strings, config comments, etc.); it says so in the subject line. i would never be tempted to change actual pkgnames; that's a recipe for breaking lots of dependency graphs, and therefore rebuilding and maintaining even more packages.