Ready.
This page presents the Beta-0 version of my prospective software-license agreement. I have been thinking of this for a year or two. Let me have it on-line somewhere. Opinions welcome.
Notice that this agreement is meant to match my publishing strategy of public releases in gradual steps, communicating with the users (or, in general, subscribers or readers), and colleagues, to check for any patent claims or suggestions-for-employing-some-patents and for publicizing own work in the appropriate public place/folder so that it could be located by the users.
My basic payment option is pay-when-you-would-not-like-to-delete. You pay only when you would not be willing to delete the software when given the choice to either delete it or pay it at the declared price. This is a question you answer yourself, with your own criteria (or with the ones the software comes by, if any) and your conscience.
All patent claims and suggestions may accumulate to meet the user preferences. And indeed, the users themselves, then, may prefer such-and-such patented options from a menu, and I may integrate those options into the release I compile for the particular user, and, of course reflecting it to the price.
I also introduce the IOU-payments for the currently-unable-to-pay would-be-registered user records the payments on his/her own records. Coupled with the pay-when-you-like, this is an alternative way to the current shareware agreements which demand being erased within 30 days or such, even if the reason for not paying may not be something in the user's discretion. That may be payment-method unavailability, being short for money at the time, etc.
I do not guarantee, in any terms, the correct operation of the software I am presenting.
All I am presenting is the software as-is, and also some examples that I used myself with my software, and that appeared to be working fine. I do not even guarantee that I can solve any problem that presents itself when you use them, with or without modifying them. But I am very willing to, indeed, I base my software strategy on it that, if you are a user (especially, a registered user), and my software is short of meeting your requirements, whether by errors, or for want of some features that you think should be, then I would be willing to get some e-mail, and provide the solution. The solution may either be an error fix, a new feature, or a telling of why I do not prefer that feature, and, if available, in what alternative ways you could use the software to meet those needs you tell me in your e-mail. But let me repeat again: I am not guaranteeing anything.
I think this is fully honest because my software license agreement, already asks for you to pay only when you find my software so useful that you would not want to delete it from your hard disk, and the like, for avoiding the payment of the price. I believe this already means that you are convinced already, and with your own observations, that the software deserves its price. You are not obliged to pay, by any criteria, until you are convinced. Once you are convinced of the worth, then it is a matter of your conscience,
Under some circumstances, although you are convinced of the worth, the available means for payment may not be present. For buying icecream, some usual options could be, not buying, borrowing some money from a friend, or letting the salesman record it to your account, if any such. The credit cards payments, and in cases of larger payments, loans and multiple- installments for payments, may also be available.
In my case, I suggest an accounting system which, just like the payment decision, again relies on your conscience. With this, you record it as an IOU to me, in your own records. And pay it even if you switch to some other software later. A usual example is being a person short for money, or other means, but using some software to develop some essential projects, but after the project is delivered, you may not need the software anymore. This may be, in the usual, a student in some long-term institution. In my world-vision, indeed, this could be anyone who meets the requirements of a particular job at a particular time, and gets into agreements. The only sensible revoking of the IOU records are where some majority of your initial reasons turn out to be false; and those may ONLY be related to your own case. For example, at the first month of a full year project, you may think my software is indispensable for that year, at least. But the next week the project is stopped. In other words, the software should be evaluated only as it already is; no assumptions; and, as a result, no revoking of decisions because of "software-relevant decision-reversals." That should never be the case. For the case of such project-related problems, I leave it to your judgment. That may only be one of the reasons you may not be sure of its worth. But then, you can set some time-limit for it that, for example, if the condition goes on for that five months, or for the duration of the project (if a relatively acceptable period; not a life time, presumably), you then do the payment or do the IOU recording.
In cases of intermediate upgrades, the amount to add the IOU records, depends on two decisions. One of them is your decison, the other is mine. Your decision is to decide whether you would like to upgrade to some new version(s). (There may be a variety of custom versions, like pizza-ordering, that you choose for your special case).
My decision is whether there is a base for less-payments. This may be because during the time of the IOU records, you are still not recorded as registered-users in our databases, and some of the specific options available to the registered users may not be fully applied in your case. The less-payments, whenever applicable, will be announced along with the regular or upgrade prices. In other words, when you are using versionX and willing to upgrade to versionY, you pay the upgradePriceX-to-Y. And in case you were only an IOU-recorded user, you subtract the lessPaymentX for the versionX.
If you were a registered user for versionX, then upgraded to versionY in your IOU records, then upgrading to versionZ along with full payment, then the less-payment to subtract is the lessPaymentX-to-Z, if any. There may have been some difference in the service between the versionY and versionX users, maybe because some new feature required some more service.
This may happen through many versions, whichever upgrades you like to have. An example may be using versionX without registering at all, only recording in IOU. versus upgradesprovide ment n such a case, the usual solutions are either < (An example to the latter is, if you are unable to pay because none of my payment transfer options fit your case. For example, I myself, so far, cannot get an internet domain name, because not only I do not have credit cards, neither my brothers, nor anyone they know having credit cards are not willing to use it in internet transactions. In your case, the reverse may be true. Because I do not accept credit cards, or because, at least for some of the software, licensing requires authorization with your (non-anymous) full ID, you may have to postpone a payment.
In such a case, you record the time you decided that, and keep