Re: [GNU-linux-libre] Freeslack website

[Ivan Zaigralin]

Yes yes. And to continue with examples and policy suggestions, the minimal 
length of forbidden substrings should probably be also set to something 
specific. Like 3 letters is probably too short, because given a nonfree 
project "ion", no one would be able to use names like "Motion" or "Lionheart". 
This all may sound like fun and jokes, but I believe these are serious 
concerns.

As I am writing this, I am informed that "Freenix" is approved for use :) This 
is fantastic news for us, and a perfect prelude to what I will say here. What 
is to stop a subjective name censor from rejecting "Freenix", for example, on 
the grounds that it's "too similar" to "Unix"? And at what point the censors 
will usurp this power to exercise de facto creative control over the 
distribution naming? This is essentially an unchecked veto power over the 
branding, and I think the best way to confront this problem is by making name 
rules completely objective. No system will be perfect with respect to 
*accuracy* when it comes to detecting *similarity*, so it makes sense to use a 
system which offers OK accuracy, while being perfectly fair and impossible to 
abuse from the position of power in the review process.

Once again, this is intended as a mild criticism of the existing process, 
which I personally think worked just fine up to now. I am just fearing that 
going forward will be wrought with peril, as the free software movement is 
picking up steam, and more distributions come into picture, each with its own 
individual issues and quirks. Unless the process is made more fair and more 
robust, there will inevitably be a build-up of resentment due to subjective 
name vetoes. And it won't even matter how well justified these vetoes will be, 
really, the trust in the process will start to erode, and it would be great to 
fix this issue before it even shows up on the radar.

On Friday, March 23, 2018 13:23:21 KRT Listmaster wrote:
> Disclaimer:  I find this a particularly interesting conversation, and I
> am posing genuine questions and thoughts that come to mind.  I am not
> trying to ruffle any feathers or step on any toes.  With that in mind...
> 
> On 03/23/2018 11:51 AM, Ivan Zaigralin wrote:
> > I'd like to register my dislike of the subjective approach to the name
> > similarity issue as well. Not that it doesn't work. I think it works OK,
> > because this is not a particularly big deal to begin with. FreeSlack
> > project, for example, has always been flexible in that respect, as in,
> > fully cooperative. But it would be better to have an objective criterion,
> > like for example:
> > 
> > Cannot use nonfree distro name or trademark as a substring in a free
> > distro
> > name.
> > 
> > A rule like this would prevent "Slackware Libre", but not "FreeSlack". But
> > more crucially, it would be fair, and no one would ever feel like an
> > individual reviewer at FSF is yanking their chain just for the fun of it.
> 
> There's a obvious limit to how far this goes.  If this general concept
> is pushed to it's logical extreme, then we'd have to drop the GNU-prefix
> from everything as well.  Because, doesn't the U stand for... Unix?
> 
> I started thinking about what a cool name for FreeSlack (which could be
> seen as a general term taken from project management theory [1]) would
> be if Freenix was rejected for some reason, and FXP wasn't accepted
> either.
> 
> A couple of joke names came to mind, and I finally settled on:
> 
> §NH - which stands for §NH is Not Hyperbola
> 
> and was my way of avoiding
> 
> §NS , short for §NS is Not Slackware
> 
> and, only then I started to wonder if the negation makes things okay.
> 
> and then it all clicked into place.
> 
> GNU would fail this same criterion if proposed today.  Just a thought.
> 
> ;-)
> 
> - krt
> 
> [1]
> https://www.coursera.org/learn/scope-time-management-cost/lecture/Gsh3x/free
> -slack
> 
> --
> This email account is used for list management only.
> https://strangetimes.observer/

signature.asc
Description: This is a digitally signed message part.