Non-Session-Manager fork descalation

What other apps and distros do you use to round out your studio?

Moderators: MattKingUSA, khz

fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Non-Session-Manager fork descalation

Post by fundamental »

So, hopefully this isn't entirely out of place. For those following other mailing lists, there has been ongoing action in regards to non-* and a current fork. The fork had plenty of good reasons for occurring, though it would seem that the current way the fork is represented has escalated the situation. Ideally things can deescalate such that things can co-exist. By no means am I implying that people need to work together on a given project. That's their own choice.

After a bit of back and forth it seems like it could be simple to change how the fork is represented in some small degrees and with how the original upstream interacts with the community generally to the overall benefit of users. Keep in mind that I did not personally have first hand knowledge of plenty of the discussions which incited the forking. Forking is something which is stressful and emotional and has resulted in an unreasonably escalated situation from my point of view. Ideally I don't want to hear about people receiving undue harassment nor being put in a situation where they perceive people trashing their work.

So without further adue the changes proposed after chatting for a while amount roughly to:

1. Rename the fork to something not abbreviated to NSM (seems plenty reasonable for new-session-manager to still be a drop in replacement, but differentiating the fork seems like a simple goal)
2. Ensure that it references the original design (already done in the repo from what I can tell)
3. Avoid calling new-session-manager the "community version" (only changing a the git repo about text from what I can tell)
4. Avoid implying endorsements from linuxaudio.org or the linux audio consortium as they have not made any such statement
(AFAIK, this point is already planned on being addressed)
5. Add some guidelines to LAA list submissions. Part of the friction there appears to be due to the fact that the last official non-* release was a decade ago. I agree with list moderators that it does not fit with the style of submissions in any way, though it would likely be good to have a blurb describe list rules regardless.
6. If there's a hard ban on LAA, remove it, but keep moderation on the list as is normal (Anything in the future similar to the original announcement should be referred to the rules if it is declined. I personally would not have it accepted to LAA without modification.)
7. Avoid claims of ownership of the original NSM codebase or NSM protocol at LAC or the community related event of Sonoj
8. Do not imply that upstream includes spyware, tracking, or advertisement issues not present (AFAIK no such upstream issues exist)
9. A public statement (e.g. on one of LAD/LAA/etc) after renaming to indicate that the matter is settled (I guess this forum counts?)
10. Ideally documenting the GUI<->server bits somewhere since that's what started all of this

So, several of these items are already addressed, some of them should be easy to possibly address, and some of them are just about future actions in relation to how both projects are presented. From what I had seen some of the earlier discussions turned to talking about the people involved rather than the projects, so perhaps this is a step forward?

Either way, happy hacking on whatever you (the reader) is working on.
nils
Established Member
Posts: 537
Joined: Wed Oct 22, 2008 9:05 pm
Has thanked: 35 times
Been thanked: 94 times
Contact:

Re: Non-Session-Manager fork descalation

Post by nils »

fundamental wrote: Mon Mar 15, 2021 7:34 pm So without further adue the changes proposed after chatting for a while amount roughly to:
Here are my comments and answers, as the maintainer of New-Session-Manager, which is the fork fundamental mentioned.

Before I answer, let me quote to you the "Bullet Points" from my README. These are still the goals.
New Session Manager README wrote: * Drop-In replacement for the non-session-manager daemon nsmd and tools (e.g. jackpatch)
* Simple and hassle-free build system to make packaging easy
* Possibility to react to sensible bug fixes that would not have been integrated original nsmd
* Stay upwards and downwards compatible with original nsmd
* Conservative and hesitant in regards to new features and behaviour-changes, but possible in principle
* Keep the session-manager separate from the other NON* tools Mixer, Sequencer and Timeline.
* Protect nsmd from vanishing from the internet one day.
* The goal is to become the de-facto standard music session manager for Linux distributions
Now on to fundamentals list:
1. Rename the fork to something not abbreviated to NSM (seems plenty reasonable for new-session-manager to still be a drop in replacement, but differentiating the fork seems like a simple goal)
It would be nice to have a name that indicates a connection to music production. Ubuntu already renamed it in their repositories because new-session-manager is too generic (which is correct).
However, the acronym "NSM" will continue to show up plenty on the website, documentation and in the code because the protocol is also named "NSM". Thus, the server binary will also remain "nsmd". New-Session-Manager is a drop-in replacement.

However, renaming might take some time, until New-Session-Manager is closer to the "de-facto-standard" goal.
2. Ensure that it references the original design (already done in the repo from what I can tell)
It always did, still does. There was never a problem here.
3. Avoid calling new-session-manager the "community version" (only changing a the git repo about text from what I can tell)
This is common practice in open source and linux development, a quick search through anyones package repositories will show plenty of examples. Therefore it will remain.
4. Avoid implying endorsements from linuxaudio.org or the linux audio consortium as they have not made any such statement (AFAIK, this point is already planned on being addressed)
Even before a recent discussion on the Linux Audio Consortium mailing list I agreed to not start the release mail with "Linuxaudio.org presents". I confirmed this on the mailing list. Hosting the project and code under the linuxaudio.org umbrella is still a very good idea and it shall remain so, as well as release announcements from "software@linuxaudio.org" . This is not my personal project, even if I am the main developer and maintainer at the moment. Hosting it there is a good way to sweeten the Bus Factor and makes it also more attractive to potential helpers.
5. Add some guidelines to LAA list submissions. Part of the friction there appears to be due to the fact that the last official non-* release was a decade ago. I agree with list moderators that it does not fit with the style of submissions in any way, though it would likely be good to have a blurb describe list rules regardless.
There are "Linux Audio Announce" mailing list guidelines: Only release announcements related to linux audio, or at least FLOSS audio. No offtopic (such as normal spam), no discussions, no answering to other release announcements.
6. If there's a hard ban on LAA, remove it, but keep moderation on the list as is normal (Anything in the future similar to the original announcement should be referred to the rules if it is declined. I personally would not have it accepted to LAA without modification.)
There is not a hard ban. LAA is a low-traffice mailing list and every e-mail is moderated, by default.
7. Avoid claims of ownership of the original NSM codebase or NSM protocol at LAC or the community related event of Sonoj
There were never claims of ownership, so there was never a problem here. All source code files hold the original authors name, as well as the updated and improved New-Session-Manager API document. There are a few source files which hold my name, additionaly, eventhough there were no code changes. Ubuntu packaging requested that this fork, any fork, must add a copyright entry, even to unchanged files, otherwise they would not package. I followed that request. Over time this legal technically will resolve itself, when every file was modified at least once.
8. Do not imply that upstream includes spyware, tracking, or advertisement issues not present (AFAIK no such upstream issues exist)
I never did, nor did any document. I know exactly what this is referring to: the marketing speech in our readme, that describes what "FLOSS" implies in layman's terms: "is free in every sense of the word free of cost, free to share and use, free of spyware or ads, free-and-open-source." It was tried to twist that into >>THEN YOU MEAN NON-SESSION-MANAGER MUST BE ALL THAT!<<, which is ridiculous. Needles to say this sentence will remain. It is a cornerstone of the README.
10. Ideally documenting the GUI<->server bits somewhere since that's what started all of this
All in good time. But this is not what started all this :)
User avatar
d.healey
Established Member
Posts: 609
Joined: Fri Sep 22, 2017 8:33 pm
Has thanked: 273 times
Been thanked: 100 times

Re: Non-Session-Manager fork descalation

Post by d.healey »

FLOSS doesn't mean free of spyware/ads/malware. I'm sure NSM is, but that's not what FLOSS means. That could mislead someone into a false of security if they believe all FLOSS programs do not contain malware.
David Healey
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
User avatar
autostatic
Established Member
Posts: 1994
Joined: Wed Dec 09, 2009 5:26 pm
Location: Beverwijk, The Netherlands
Has thanked: 32 times
Been thanked: 104 times
Contact:

Re: Non-Session-Manager fork descalation

Post by autostatic »

nilshi wrote:
fundamental wrote:4. Avoid implying endorsements from linuxaudio.org or the linux audio consortium as they have not made any such statement (AFAIK, this point is already planned on being addressed)
Even before a recent discussion on the Linux Audio Consortium mailing list I agreed to not start the release mail with "Linuxaudio.org presents". I confirmed this on the mailing list. Hosting the project and code under the linuxaudio.org umbrella is still a very good idea and it shall remain so, as well as release announcements from "software@linuxaudio.org" . This is not my personal project, even if I am the main developer and maintainer at the moment. Hosting it there is a good way to sweeten the Bus Factor and makes it also more attractive to potential helpers.
I think this is mostly sorted out by now. And like you said fundamental, this point will be addressed one of these days.
nilshi wrote:
fundamental wrote:5. Add some guidelines to LAA list submissions. Part of the friction there appears to be due to the fact that the last official non-* release was a decade ago. I agree with list moderators that it does not fit with the style of submissions in any way, though it would likely be good to have a blurb describe list rules regardless.
There are "Linux Audio Announce" mailing list guidelines: Only release announcements related to linux audio, or at least FLOSS audio. No offtopic (such as normal spam), no discussions, no answering to other release announcements.
Exactly, see also https://lists.linuxaudio.org/listinfo/l ... o-announce.
nilshi wrote:
fundamental wrote:6. If there's a hard ban on LAA, remove it, but keep moderation on the list as is normal (Anything in the future similar to the original announcement should be referred to the rules if it is declined. I personally would not have it accepted to LAA without modification.)
There is not a hard ban. LAA is a low-traffice mailing list and every e-mail is moderated, by default.
No one has been banned from LAA. LAD is a different story, that is an unmoderated list so something had to be done there. I'm OK with undoing any ban on LAD though, but if people start to stir up the fire again we won't hesitate this time doing something about it and communicate that clearly, that's one lesson we've learned.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Non-Session-Manager fork descalation

Post by fundamental »

nilshi wrote: Mon Mar 15, 2021 8:14 pm It was tried to twist that into >>THEN YOU MEAN NON-SESSION-MANAGER MUST BE ALL THAT!<<, which is ridiculous.
I totally get the initial aim and goal of the statement. The problem seems similar to going to a grocer to pick up some salt. You could end up with 4 boxes which say "X-brand's salt" and a 5th box which has the additional labels "Meat free, Asbestos free". While your intention wasn't to make an implication, similar to those boxes of salt when products/projects are put in comparison and one claims it doesn't have something it can be misinterpreted as implying that it is a differentiating factor (i.e. implying that the other boxes of salt were somehow contaminated without directly making the claim).
ZynAddSubFX maintainer
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Non-Session-Manager fork descalation

Post by fundamental »

autostatic wrote: Tue Mar 16, 2021 10:37 am
nilshi wrote:There are "Linux Audio Announce" mailing list guidelines: Only release announcements related to linux audio, or at least FLOSS audio. No offtopic (such as normal spam), no discussions, no answering to other release announcements.
Exactly, see also https://lists.linuxaudio.org/listinfo/l ... o-announce.
Certainly that's the goal of the list. It sounds like some of the hang ups was that the message being too far offtopic implied it was spam (I don't recall or even know if I would have known about the specifics). Having a bit more detail in what constitutes offtopic (I'm guessing we would all agree on a definition, it just hasn't been written down) and perhaps placing that text on the list's page would be an improvement. Right now all that's there is "The Linux Audio Announce list is intended as a low-traffic informational list for announcements about Linux Audio development issues." I don't disagree with the moderation decisions personally, but being able to point to specific rules IMO is one strategy in defusing situations.
ZynAddSubFX maintainer
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 357 times

Re: Non-Session-Manager fork descalation

Post by j_e_f_f_g »

There's an easier and quicker way to resolve this... dueling pistols at dawn.

Here are 2 things that every OSS developer needs to understand before he releases any code:

1) If you don't want anyone to make money off of your code, don't give it a BSD license.

2) If you don't want anyone to modify (and distribute the mods) of your code, don't license it GPL.

The entire point of the GPL is to allow anyone to modify the source whichever way suits his purposes. Forking code is a legitimate, legal action under the GPL. That's the bottom line. If you license GPL, and subsequently complain when someone modifies your code, then you're being an annoying twit.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Non-Session-Manager fork descalation

Post by raboof »

j_e_f_f_g wrote: Tue Mar 16, 2021 3:25 pm 1) If you don't want anyone to make money off of your code, don't give it a BSD license.
2) If you don't want anyone to modify (and distribute the mods) of your code, don't license it GPL.

The entire point of the GPL is to allow anyone to modify the source whichever way suits his purposes. Forking code is a legitimate, legal action under the GPL. That's the bottom line. If you license GPL, and subsequently complain when someone modifies your code, then you're being an annoying twit.
While I agree with those statements themselves, they seem besides the point: I don't think anyone is complaining new-session-manager modified the non-session-manager code...
tramp
Established Member
Posts: 2335
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 454 times

Re: Non-Session-Manager fork descalation

Post by tramp »

From a developers pov:
For years I've ask to make NSM available outside the NON-suite, as a de-facto wonebe standard for inter-client communication shouldn't be part of a software suite.
This never ever happen from the original author, and, in opposite, he claimed that he never ever will do that and proclaimed a fork to make that happen.
For me that was the reason why I never implement support for NSM in any of my projects.
Now, this have been changed with this fork, fortunately, and NSM is available without any dependency to a custom toolkit, and without being part of a suite, and, with a responsible maintaining crew. That's so nice. I've immediately implement support for it in my projects.
As said by @j_e_f_f_g, that's how open source roles, claiming against a fork of a GPL'd software harm the community at all, regardless which hairy reasons you mess up.
Sometimes a fork could be a big step up into the future.

Imagine, LV2 standard would only be available as part of ingen, what do you think, how many LV2 plugs would we have today?
On the road again.
fundamental
Established Member
Posts: 165
Joined: Thu Nov 07, 2013 1:19 pm
Been thanked: 1 time

Re: Non-Session-Manager fork descalation

Post by fundamental »

From what I've seen it's a degree of forks being an intrinsically painful event, but a large portion of the friction comes from the representation of the fork. Code licenses dictate what recipients of code/software can do. It doesn't go into any of the social implications of the how. Some of the issues would fall into the domain of trademark concerns. Overall it's how things are done which changes the possible perception from people improving situations with their own independent work to viewing things as a hostile takeover.

I'm not trying to judge the situation or otherwise say that one way of viewing things is the only true way to view things, just trying to highlight how things can be viewed.
ZynAddSubFX maintainer
User avatar
autostatic
Established Member
Posts: 1994
Joined: Wed Dec 09, 2009 5:26 pm
Location: Beverwijk, The Netherlands
Has thanked: 32 times
Been thanked: 104 times
Contact:

Re: Non-Session-Manager fork descalation

Post by autostatic »

fundamental wrote: Tue Mar 16, 2021 1:22 pm Certainly that's the goal of the list. It sounds like some of the hang ups was that the message being too far offtopic implied it was spam (I don't recall or even know if I would have known about the specifics). Having a bit more detail in what constitutes offtopic (I'm guessing we would all agree on a definition, it just hasn't been written down) and perhaps placing that text on the list's page would be an improvement. Right now all that's there is "The Linux Audio Announce list is intended as a low-traffic informational list for announcements about Linux Audio development issues." I don't disagree with the moderation decisions personally, but being able to point to specific rules IMO is one strategy in defusing situations.
You're right, the LAA mailing list About page deserves some LTC and polishment, I'll take a look at that!
User avatar
autostatic
Established Member
Posts: 1994
Joined: Wed Dec 09, 2009 5:26 pm
Location: Beverwijk, The Netherlands
Has thanked: 32 times
Been thanked: 104 times
Contact:

Re: Non-Session-Manager fork descalation

Post by autostatic »

fundamental wrote: Mon Mar 15, 2021 7:34 pm 4. Avoid implying endorsements from linuxaudio.org or the linux audio consortium as they have not made any such statement
(AFAIK, this point is already planned on being addressed)
Statement from the board director: https://lists.linuxaudio.org/archives/c ... 02221.html
folderol
Established Member
Posts: 2069
Joined: Mon Sep 28, 2015 8:06 pm
Location: Here, of course!
Has thanked: 224 times
Been thanked: 400 times
Contact:

Re: Non-Session-Manager fork descalation

Post by folderol »

autostatic wrote: Wed Mar 17, 2021 3:53 pm
fundamental wrote: Mon Mar 15, 2021 7:34 pm 4. Avoid implying endorsements from linuxaudio.org or the linux audio consortium as they have not made any such statement
(AFAIK, this point is already planned on being addressed)
Statement from the board director: https://lists.linuxaudio.org/archives/c ... 02221.html
Thanks for that link. Mind you, it's quite right and exactly what I would expect.
The Yoshimi guy {apparently now an 'elderly'}
User avatar
davephillips
Established Member
Posts: 592
Joined: Sat Aug 15, 2015 1:05 pm
Has thanked: 35 times
Been thanked: 23 times

Re: Non-Session-Manager fork descalation

Post by davephillips »

j_e_f_f_g wrote: Tue Mar 16, 2021 3:25 pm ...

Here are 2 things that every OSS developer needs to understand before he releases any code:

1) If you don't want anyone to make money off of your code, don't give it a BSD license.

2) If you don't want anyone to modify (and distribute the mods) of your code, don't license it GPL.

The entire point of the GPL is to allow anyone to modify the source whichever way suits his purposes. Forking code is a legitimate, legal action under the GPL. That's the bottom line. If you license GPL, and subsequently complain when someone modifies your code, then you're being an annoying twit.
This.

I'm aware of the details of the particular fiasco under discussion. This is the critical point we've danced around, and it remains solidly valid. Put your stuff on github under the GPL or BSD license and there can be specific consequences regarding forks and redistribution that will be beyond your control. Which, as jeff emphasizes, is a primary point of the GPL, i.e. the possibility of shifting control from the owner of the code to the user.

I'd add:

0) Thoroughly read whatever license you select. Know its terms and intentions completely and accurately before sticking it in your codebase.

Best regards,

dp
grammo
Established Member
Posts: 45
Joined: Thu Mar 18, 2021 1:19 pm
Has thanked: 1 time
Been thanked: 5 times

Re: Non-Session-Manager fork descalation

Post by grammo »

davephillips wrote: Thu Mar 18, 2021 12:23 pm

This.

I'm aware of the details of the particular fiasco under discussion. This is the critical point we've danced around, and it remains solidly valid. Put your stuff on github under the GPL or BSD license and there can be specific consequences regarding forks and redistribution that will be beyond your control. Which, as jeff emphasizes, is a primary point of the GPL, i.e. the possibility of shifting control from the owner of the code to the user.

I'd add:

0) Thoroughly read whatever license you select. Know its terms and intentions completely and accurately before sticking it in your codebase.
This is exactly the point, thanks for making this so clear. So people should think twice in the linuxaudio community to release their software as GPL. Is that what we really want?

As Fundamental pointed out, forking is one thing, how you fork is another thing. Fact is that is took me a year to make them finally drop the statement: 'released by linuxaudio.org'. But they still want to use a linuxaudio e-mail address and they host on the linuxaudio github page. They want first to wipe out the original NSM and then when they've reached their ultimate goal (full control over NSM) they might be willing to change it's name. They say it themselves. They decide for themselves and nobody does anything to restore the balance and to set some boundaries.

At the end the problem isn't the fork, not even how it's done, but the way this behavior is supported by linuxaudio.org and the community. Nice statement from the board director, but it doesn't say anything really unfortunately. They make their own boundaries as also is clear from the response of the maintainer here.

So indeed, from now on, think twice before you release something as GPL in this community. It's the sad conclusion. Sorry that it took me a year to find the right words.
Last edited by grammo on Thu Mar 18, 2021 1:50 pm, edited 1 time in total.
Locked