~sircmpwn/public-inbox

1

Re: Provided "as is", without warranty of any kind

Details
Message ID
<20210615155953.l6xfljk5l62qnaos@hoshi>
DKIM signature
missing
Download raw message
Hi Drew,

Just read your article "Provided "as is", without warranty of any kind", I like
it a lot.

Some people don't understand the implications of MIT(-like) licenses at all.

In the light of

> Many people who rely on free and open source software [...] think that the
> developers have a responsibility to provide good maintenance, or any
> maintenance at all, for their work. This is simply not true.

and

> [..] important that maintainers understand this as well. [...]
> As a maintainer, you need to be prepared to say “no”.

it's dramatic what the NixOS community experienced just days ago. Maybe you
already saw the discussion on hackernews, possibly it even led you to write this
article.

TL;DR: An author of a few python libraries which are used in the home-assistant
project wants the nixos community not to package their libraries (I'm not
linking because of the tension in the discussion and I don't want to drive more
people to shoot comments into the already heated environment).

AFAICS, this would make home-assistant unusable on NixOS.

While their intentions are not completely clear yet, it seems like they just
want to have their software packaged in NixOS (and fedora, FWIW), although
nothing can prevent the respective communities from packaging as their software
is MIT-licensed.

It is sad that users do not understand the nature of these licenses, but it is
(at least to me) kind of shocking that maintainers do not understand the
implications.

Thus: Thanks for writing this up! We can only repeat the mantra until everybody
understood!

Best,
Matthias

Re: Provided "as is", without warranty of any kind

jman
Details
Message ID
<87bl86lxca.fsf@city17.xyz>
In-Reply-To
<20210615155953.l6xfljk5l62qnaos@hoshi> (view parent)
DKIM signature
pass
Download raw message
I think the story is more faceted than "I owe you nothing, bring your 
entitlement somewhere
else".

The points that Drew lays down are all correct but it's just one side of the 
coin. The other side is
that a FOSS project lives because of its users and their feedbacks (bugs 
reports, patches, useful
suggestions, even a simple thank-you email). If a project doesn't have users, 
you can enforce any
license you want, the project ends up just being an exercise for the author 
(which makes sense on
its own but that's a different story).

The maintainer must be able to balance "bad" users (= avoid burn out) to not 
alienate the "good" ones
(= can contribute).

The problem I often see in FOSS projects is orthogonal: organization. Being a 
one-man-band is the
receipt for burn-out, so as soon as a project starts getting visibility, it is 
(imo) important for
the original maintainer to delegate to trusted people, offloading and improving 
the bus factor.
Finding people for that is even more difficult.

Best,
Reply to thread Export thread (mbox)