Re: ESC meeting minutes: 2024-10-31

["Dr. David Alan Gilbert" <dave@xxxxxxxxxxx>]

* Andreas Mantke (maand@xxxxxx) wrote:
> Hi all,
> 
> Am 31.10.24 um 19:07 schrieb Thorsten Behrens:
> > (...)
> > * Feature locking (Andreas)
> >    +<https://gerrit.libreoffice.org/c/core/+/174865> "Remove blocking functions feature from core"
> >    + re-visit from last week - any new views?
> >    + Heiko: having a 'freemium' label in the code - is not ideal. but more a question
> >      of labelling stuff, rather than technically wrong. And not affecting the desktop
> >      version anyway
> >    + Ilmari: but Andreas is not complaining about the label, but about the feature
> >    + Hossein: perhaps this can be a compile-time option instead?
> >    + Michael W.: unclear if that resolves it for Andreas
> >    + Ilmari: does not see the point either
> >    + Cloph: sees no prob here, either - several other places with 'locks' already in
> >    + AI thorsten conclude this from the side of the ESC, leave comment in the patch
> 
> 
> after some further thoughts on the process I find it very disturbing
> that the ESC made its decision (and discussion) without even looking at
> the 'freemiumDenyList' (or its renamed version / file). Because we are
> talking about Free Software / FOSS it should be necessary to look first
> on the facts/reasons for the blocking/locking function. But that is only
> really possible if you know the list of denied features.

Hmm; I'm not on ESC, and don't work for any company, so, with that said.

I do agree with you that freemium like things are horrible, but in the
end there's nothing in the free licenses stopping anyone releasing a modified
build that hobbles some features and then another build that has them.
(Although what does the trademark policies say?)

Are there any good reasons for one? Hmm, I've seen things where 
companies really don't want to support a particular feature, e.g. because
it's flaky or they don't employ anyone who knows how to fix it when it breaks;
so that's a kind of sane use for an interface like that.
I can't really object to that.

(Personally I'd rather that be an interface that then allows you to enable
it with a big scary, logged, warning telling you that you don't
get support for it).

IMHO just using it so you can scrape more $ from the customers for
some features other than support is rather natier and just annoys
the customers; but then again as I say, I don't think the licenses
stop it.

> Thus I expect the ESC to ask for this list, publish it and start the
> discussion and decision from scratch again. And I think the discussion
> and decision has to be done without those who have an CoI on this topic.

I think the point is to make the list flexible, so I doubt that would work.

> There were some attendees with such potential conflict in the
> discussion/decision on 2024, Oct. 24/31.

The ESC isn't exactly huge, so I can see how that might be tricky.

But two other thoughts:
  a) I'd rather have the code in LO rather than distro companies
having hacked the hell out of LO to what they ship to customers.

  b) This seems to have been more controvercial because it was only
found out later;  an obviously contentious thing should be discussed
before going in, and it seems wrong for that not to go through a lot
of review.   Getting ESC to think how we stop controvercial things
going in without more visibility seems worthwhile.

Dave
throwing his own two cents into a discussion that probably already has too
many.

> And I would appreciate if the ESC would have a deeper look on those
> patches which only make it to a distro branch and not to the LibreOffice
> master (or a LibreOffice release branch).
> 
> Regards, Andreas
> 
> --
> ## Free Software Advocate
> ## Plone add-on developer
> ## My blog:http://www.amantke.de/blog
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/