Non-Session-Manager fork descalation
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Non-Session-Manager fork descalation
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.
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.
-
- Established Member
- Posts: 538
- Joined: Wed Oct 22, 2008 9:05 pm
- Has thanked: 35 times
- Been thanked: 94 times
- Contact:
Re: Non-Session-Manager fork descalation
Here are my comments and answers, as the maintainer of New-Session-Manager, which is the fork fundamental mentioned.fundamental wrote: ↑Mon Mar 15, 2021 7:34 pm So without further adue the changes proposed after chatting for a while amount roughly to:
Before I answer, let me quote to you the "Bullet Points" from my README. These are still the goals.
Now on to fundamentals list: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
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).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)
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.
It always did, still does. There was never a problem here.2. Ensure that it references the original design (already done in the repo 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.3. Avoid calling new-session-manager the "community version" (only changing a the git repo about text from what I can tell)
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.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)
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.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 is not a hard ban. LAA is a low-traffice mailing list and every e-mail is moderated, by default.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 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.7. Avoid claims of ownership of the original NSM codebase or NSM protocol at LAC or the community related event of Sonoj
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.8. Do not imply that upstream includes spyware, tracking, or advertisement issues not present (AFAIK no such upstream issues exist)
All in good time. But this is not what started all this10. Ideally documenting the GUI<->server bits somewhere since that's what started all of this
- d.healey
- Established Member
- Posts: 611
- Joined: Fri Sep 22, 2017 8:33 pm
- Has thanked: 278 times
- Been thanked: 101 times
Re: Non-Session-Manager fork descalation
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.
YouTube - Free HISE scripting and sample library dev tutorials
Libre Wave - Freedom respecting instruments and effects.
- 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
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: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.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)
Exactly, see also https://lists.linuxaudio.org/listinfo/l ... o-announce.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.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.
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.nilshi wrote:There is not a hard ban. LAA is a low-traffice mailing list and every e-mail is moderated, by default.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.)
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Re: Non-Session-Manager fork descalation
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
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Re: Non-Session-Manager fork descalation
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.autostatic wrote: ↑Tue Mar 16, 2021 10:37 amExactly, see also https://lists.linuxaudio.org/listinfo/l ... o-announce.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.
ZynAddSubFX maintainer
Re: Non-Session-Manager fork descalation
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.
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.
- 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
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...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.
-
- Established Member
- Posts: 2347
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 466 times
Re: Non-Session-Manager fork descalation
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?
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.
-
- Established Member
- Posts: 165
- Joined: Thu Nov 07, 2013 1:19 pm
- Been thanked: 1 time
Re: Non-Session-Manager fork descalation
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.
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
- 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
You're right, the LAA mailing list About page deserves some LTC and polishment, I'll take a look at that!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.
- 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
Statement from the board director: https://lists.linuxaudio.org/archives/c ... 02221.htmlfundamental 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)
-
- Established Member
- Posts: 2080
- Joined: Mon Sep 28, 2015 8:06 pm
- Location: Here, of course!
- Has thanked: 227 times
- Been thanked: 400 times
- Contact:
Re: Non-Session-Manager fork descalation
Thanks for that link. Mind you, it's quite right and exactly what I would expect.autostatic wrote: ↑Wed Mar 17, 2021 3:53 pmStatement from the board director: https://lists.linuxaudio.org/archives/c ... 02221.htmlfundamental 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)
The Yoshimi guy {apparently now an 'elderly'}
- 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
This.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.
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
-
- 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
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?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.
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.