> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development.

Pretty sure every open source license includes this in the warranty line...

No, that’s the legal warranty disclaimer. It has nothing to do with support, security fixes, or future development.

What do you think a warranty is?

A warranty is about the code which already exists, and whether the code is fit for a particular purpose, etc. (all legal terms). The warranty disclaimer in free software licences all say basically “Although this specific version of the software is meant to be helpful to you for a certain purpose, you can’t sue the developer if there’s a bug or an omitted feature, since we don’t make any guarantee that it will work.” But this is not what I was talking about. I was talking about disclaiming any implied support, security bugfixes, and future development, all three of which are usually heavlily implied (or outright stated) to be available in official project information (such as on an official web site).

You are saying I should add, to my free lemonade stand, a disclaimer:

I will not help you with drinking the free lemonade; if the lemonade is too sour for you I will not be providing extra sugar; and I will not make free lemonade tomorrow.

Can you give me one or two examples of official OSS websites where these are heavily implied or outright stated? Do you mean anything beyond a roadmap?

You don’t need a disclaimer for something which nobody reasonably expects. Although an “available today only” notice might be useful, since people might reasonably expect a lemonade stand to be available the next day.

Regarding examples, basically any software project web site which talks about the project as an ongoing thing, gives links to where “new releases” will be available. Stuff like that. All that implies that the software is actively developed and will be developed for at least the near future.

Let's look at one of my favorite open source projects:

https://github.com/gorhill/uBlock

Does gorhill need a disclaimer, as you propose?

If so, please tell me specifically, where you are reading any "implied support, security bugfixes, and future development".

I am not purposefully complicated, I just feel your "implied" is doing a lot of work, and I want to see what that really means. I don't see the implication, but perhaps I am blind. So please enlighten me. (If ublock doesn't fit your argument, please give another example of your liking.).

Firstly, uBlock doesn’t really talk about its own updates, since all the frequent updates it needs are provided by its filter lists. It’s basically an app store, a little bit like F-Droid. And you’re right, I can find no explicit language that either states or implies any of the things i listed.

But think of it this way. There is a prominent link to their list of releases, <https://github.com/gorhill/uBlock/releases>. From what I can tell, the releases vary from a few days apart to maybe a month apart, with the most recent release being yesterday. What would you think if, say, six months from now, there still wasn’t a new release? No bugs fixed? And, when asked about the absence of these things, if the developer’s answer would be “You’re whiny and entitled, I have no legal obligation to do anything, read the license LOL.”? I mean, he’d be technically correct, it would be legal for him to do this. But would it be OK? What I am arguing is that it would not be OK, and that users do have legitimate reasonable expectations of any project that presents itself as being active; i.e. fixing bugs, security holes, and implementing new features. Users are not “entitled” when expecting these things.

> And, when asked

Just so I understand, what would be the question here?

(I have edited to clarify.)

I am no longer sure there is much disagreement... just a different perspective on the world, I guess?

What you say is kinda true, but directly proportional to time since the last commit (currently for uBlock 9hours ago). If there has been a commit over the last few days, yes, I (not particularly reasonably, but still) expect there to be updates. But this expectation (and reasonableness) diminishes with this commit further away, if that becomes months and then years, I no longer expect that.

And in your hypothetical conversation, a lot hinges on your exact framing and phrasing of both the (non)entitled question and the phrasing of the answer. Yeah, your hypothetical developer is a dick. Don't be a dick, both sides.

Again, I feel there isn't enough disagreement here for argument. Enjoy your perspective, have a good day or night.

The distinction you're trying to make isn't recognized in the eyes of the law, nor really anyone else for that matter.

The warranty disclaimer in virtually every software project, regardless of license, has been around for decades. The text has been fairly anodyne except with the recent wave of parasites killing their host and trying to snake their way out of it.

> B: Be clearly labelled, in its public-facing information, as being offered as-is, without any implied updates or future development.

So if I had a text file in the root of my repo that said:

  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

Would that be sufficient?

That text does not disclaim support, security bugfixes, and future development. On the contrary, all three of those things are probably either heavlily implied or outright stated to be available on the project web site.

You and I are reading "SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION." very differently.

At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases.

> At best, that only covers bug fixes. And, as I said, bug fixes are usually implied to be available in future releases

Can you explain how you got to that interpretation from that phrasing?

> SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

And how is future development and / or support not covered under servicing of that clause?

Fixing defects is a different activity from support and future development, no?

Why is that distinction important? Especially in light of the first sentence of the paragraph that sentence is embedded in.

> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.

It also doesn't disclaim the author from writing you a check out of the good will of their heart.

I don't understand what's so difficult to understand. It's like everyone has been captured by a machine that will conjure up the most mystifying reasoning to suit a predetermined conclusion that was never true to begin with.

> * It also doesn't disclaim the author from writing you a check out of the good will of their heart.*

Nobody expects that. But people do reasonably expect a project to recieve updates, security fixes, and new releases.

I'm not disagreeing with you, you're just wrong.

It's not reasonable to expect a project to receive updates, security fixes, and new releases for software projects the author put on the Internet explicitly with a license saying it's warrantied for no purpose.

I was going to present a fair rebuttal, but you’ve just convinced me that it’s unreasonable for you to expect any answer from me in this debate.

There's nothing to debate.

Your starting point is to selectively ignore parts of the authors explicitly chosen license.

It's sophistry.

I think it is too long.

This is ridiculous because there is no legal or moral obligation from the creator to say anything except maybe adding the license. You as a user can use the given software and probably modify yourself at will due to the permissive license which is the main advantage of OSS. When I get stuff from the charity I do not expect them to provide a return policy and customer service, your analogy is moronic because the thing was done already and you can come back and get a newer thing if it is ready.

The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support. I am not talking about you, even the larger companies always mention a wish to force smaller developers to patch security issues for free, this is an issue in supply chain security at the moment.

The gist is that you can fix it yourself.

To use any software in these modern times, it’s not enough to simply get a snapshot and use that forever. That time has long gone. Users need updates for whenever the inevitable incompatibilities arise, and since switching to some other software is a lot of work, users need to be able to depend on regular, timely updates. Indeed, many people choose what software they use solely on that basis. Therefore, any software project which presents itself as usable is implying that the project will provide these things.

(This is a bit like how a stable economy depends on there being a crucial threshold number of long-term, high-trust relationships. You cannot have a functioning economy when everybody is always backstabbing everybody else.)

> The problem is that the barrier to use any software is so low that it attracts people who have no clue and demand support.

I think this phenomenon is caused by:

1. Some users being a bit whiny and entitled, just like some people are rude to waiters. Some have been taught and brought up to behave this way, and others have just gotten into bad habits.

2. Many developers being overly defensive when presented with legitimate complaints from users. This is just human nature, harmful as it may be.

3. Due to 2., users exaggerate and act rudely when reporting complaints, because they expect pushback from developers. This then exacerbates 2. again, leading to a vicious cycle.

Some developers who are burnt out by 1., and are not realizing what is going on, are, as a way of psychological self-defense, adopting an attitude of “I don’t care about you users, you’ll get nothing and you’ll ******* like it.” This then necessitates the same developers to argue that all users who expect anything are merely “entitled”, because if any user’s expectations would be reasonable, then the developer’s attitude would be unwarranted, and the developers feel that they need that attitude for their own well-being.

> Be clearly labelled, in its public-facing information, as being offered as-is

If you read the license (for most licenses anyway), that info is clearly right there.