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).
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.
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.
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.
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.
