[Consortium] Official fork

rosea.grammostola rosea.grammostola at protonmail.com
Fri Feb 19 18:56:00 CET 2021



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, February 13, 2021 2:36 PM, Robin Gareus <robin at gareus.org> wrote:

> On 2/13/21 2:05 PM, Fons Adriaensen wrote:
>
> > On Sat, Feb 13, 2021 at 12:42:27PM +0100, Robin Gareus wrote:
> >
> > > On 2/13/21 11:51 AM, Fons Adriaensen wrote:

> >
> > Who do not pretend to act on behalf of linuxaudio.org.
> > Nor do they declare any other competing project 'legacy'.
> > If anyone (member or not) can pretend to speak for linuxaudio.org
> > then the whole consortium thing becomes a joke.
>
> Yeah, they put their foot in with that.

If we agree on the fact that the linuxaudio.org consortium can't be used like this, then this should be solved, right?

There wasn't a problem until now, but this new situation asks for new rules or better, explicit rules.

I do propose the following and it's proposed by others on the LAD list as well. It's a  simple rule, which solves this situation easily, without any further efforts by the linuxaudio.org consortium. The simple rule is:

The linuxaudio.org consortium doesn't release nor host software.

So at this moment in time, the fork of Non Session Manager and the forked API should be removed (I suggest within a reasonable time of two weeks) from anything with a relation to the linuxaudio.org consortium. Which means they have to host the software on their own spot on the Internet. They are not allowed to use the name linuxaudio.org, nor use the linuxaudio.org domain when releasing and announcing the software. This is not only to keep linxaudio.org consortium neutral, but also to protect a fellow LAD developer. And not only this particular one, but all, now and in the future.

For this particular case it means that both the original and the forked project are on equal ground. Which is normal for a fork, no privileges. The linuxaudio users will make their decision which version they'll use, which is best for them. There is no need to make this choice for them. The developers behind the fork said they stick with the original Non Session Manager (NSM) API, so that's not a problem as well.

This will leads to a more balanced situation, where the linuxaudio.org consortium is still neutral, where the rights of the original developer are more protected and where the developers behind the fork, still have the right to fork. It's a simple and fair solution to all parties and good for a healthy future in my opinion.

I don't see a role for the linuxaudio consortium here at all in any situation anyway. I don't see what else is needed to promote a session API then having it on a website, in the WIKI and having community members asking developers for this feature to be supported in applications and explaining them why they want API x and not y. On LAD mailinglist and at LAC conferences, developers can discuss different session manager API's and discuss the pros and cons as well. The choice should be based on quality of the API it's infrastructure and the discussion about it.


Then there is the issue of the naming and especially the use of NSM. NSM stands and should stand for Non Session Manager. Raysession also uses the NSM API, but doesn't reuse the NSM abbreviation for it's name. Using the same abbreviation leads to confusing and it's in some ways deceiving. I think it would be good to handle it as if NSM was trademarked by the original author. So change the name to something totally different and tell users that the NSM API or the Non Session Manager API is used. The question is whether this is a issue for the linuxaudio.org consortium though. It's more a matter of good manners and reason and something to be handled by discussing it in the LAU/LAD community I think. It would be best if the developers behind the fork, would changed it themselves of course.

Regards,

\r


More information about the Consortium mailing list