Short-Term Demands from the Software Industry – II
What is becoming clear is that I’m biting off more than I can chew with this list, since there are too many details to consider and my ability to express myself is certainly not getting any better. Still, I started it and now I have to find a way to get to the end, even if that’ll require focusing only on the more technical side of being fair towards the consumers now and leaving the part supposed to ensure a higher degree of fairness for developers, as well as the issue of DRM, for a third post that I’ll add to this series later.
Even so, I’m sure that there will be plenty of issues and loopholes that I’ll fail to cover in the list below, as there have been in the section included in the first post from this series as well, so in case anyone’s reading, do point them out if you spot them and tell me how you’d fix them. The whole thing is very much a work in progress anyway, so I will be making changes if I’ll find ways to improve on what I currently have, the final goal being to put together a list that’ll cover all the relevant aspects reasonably well.
But let’s not get ahead of ourselves. If and when I’ll have the whole list, including whatever changes I’ll see fit to make to what you’ll see in these initial posts, I’ll probably put all of it in another post and then see what else could be done with it. For now, however, I need to write the second of what currently seem to be three parts and, since you’re here, you should probably be reading it. Just keep in mind that, if you care to help in any way, you should actually be looking for flaws and potential loopholes and pointing them out.
2) All software products that are sold must benefit from proper support, otherwise they will immediately become freeware. More specifically:
2.1) All software products except those meant specifically to test or modify a particular operating system feature:
2.1.1) Must, on release, function properly on all fully updated versions of the operating system(s) listed as being supported that have originally been released six months to three years previously.
2.1.2) May or may not immediately function properly on a version of a supported operating system released less than six months before the software product in question. However, if such functionality is not available on release day, a patch that fully enables it must be issued within 90 days.
2.1.3) Must be tested on any new version of a supported operating system released up to three years after the the software product in question. If the software product fails to function properly on the new operating system, a patch to fix the issue must be released within 90 days.
2.2) The maximum amount of time allowed to develop a patch meant to fix verifiable reported bugs and other known issues that have a significant negative impact on the software product’s functionality under conditions that the customer wasn’t specifically notified may have such effects prior to purchase, counting from the day the first verifiable report regarding the issue in question was submitted, is:
2.2.1) 30 days for major security flaws.
2.2.2) 90 days for issues known to cause the software product to completely cease functioning as intended.
2.2.3) One year for any other issues.
2.3) If the developer(s) currently contracted to provide such support become(s) unable or unwilling to provide the required fixes within the time limits listed at points 2.1.2), 2.1.3), 2.2.1), 2.2.2) and 2.2.3), the distributor(s) that still desire(s) to sell the software product:
2.3.1) Will be granted up to 90 additional days to find other ways to fulfull these requirements if the existing relevant contract(s) between the distributor(s) and the developer(s) in question have been breached by the developer(s) and this happens no more than five years after the original release of the software product.
2.3.2) Must find other ways to meet the original deadlines, without being granted any additional time, if there was no breach of contract by the developer(s) and/or this happens more than five years after the original release of the software product.
3) In order for the existing support to be readily available and easily accessible for all users of the software product:
3.1) All patches that fix flaws must be offered as free and direct downloads, without requiring any verification or the use of any software other than a generic browser. Other methods of obtaining such patches may be offered, but only in addition to, and not instead of, the direct download.
3.2) Patches that add content and/or functionality that wasn’t included in the software product on release day, such as plug-ins, expansions, DLCs, etc., may require verification and/or payment only if:
3.2.1) They are released more than 30 days after the software product itself. All patches released within the first 30 days are considered to be fixing flaws, regardless of their actual content.
3.2.2) They do not also fix flaws of the original software product that can’t be fixed otherwise. If a patch that adds content and/or functionality and isn’t available in a way that respects point 3.1) also fixes flaws, a separate patch that fixes the same flaws, even if without adding any new content and/or functionality, must be made available in a way that respects point 3.1).
This should be it for now. Toyed with the idea all week and couldn’t come up with anything that seemed anywhere near good enough, but today it’s Sunday and I had to post something, so I’ll have to settle for this. As I said in the beginning, I know I’m missing things and leaving loopholes, but at the moment this seems to be the best I can do, in good part because I just can’t express what I mean to say in a way that’ll seem to make sense for others as well. For example there’s an obvious loophole at point 2.3.1) that I know how to get rid of, but can’t figure out how to say it, especially since that part sounds particularly bad as it is. Not that laws, regulations, contracts and other such things are meant to sound good, of course, and in fact they often are difficult to understand for those who don’t specialize in them, but I’m not one of those and, if you’re reading this, probably neither are you…



