I really appreciate all the different points of view on the license policy, and truly believe they reflect the variety of different needs and expectations of SpiderBasic's userbase. I'd like to join the discussion and share some personal thoughts on the issue too...
The yearly subscription is probably to short, seen the unfrequent updates. But we must also keep in mind that the decision to switch from the life-time license policy of PB to that of a time-bound subscription is the result of Fred's personal experience with PB over the past decades.
On the one hand, there are those aficionados who see the yearly subscription as a way to keep the project(s) alive — including PureBasic, which is still actively maintained and alive. On the other hand, there are those who look at it from a mere commercial licensing point of view, and can't avoid comparison with other commercial software applications (in terms of license lifetime/cost, and updates frequency), and of course this line of thinking also makes sense.
Personally, I think that a two-years license scheme would be more appropriate, not so much because of the updates frequency, but comparing to how other commercial tools handle their licensing schemes. Add to that the fact that currently SB is not fully mature, it would make more sense to relax a bit the license lifetime.
What really sucks (IMO) is the fact that renewing the license starts from the day you pay for it. From the SpiderBasic website:
If you want to, you can renew your SpiderBasic license for a special price (25% off) !
NOTE: the one year extension will start from the new ordering date, so be sure to not extends too soon.
I don't see why we can't just renew our license at any time, with the confidence that the website is able to extend our license from its expiry date, instead of counting one year from today (seriously, both SpiderBasic and PureBasic can handle this, the former via JS, the latter via CGI/FastCGI, so why is this happening?). This is really more of a matter of principle than anything else, for it seems unfair the way this is currently handled.
Also, aficionados might prefer an auto-renewal scheme, allowing their favorite payment method to accept automated future charges (most online services work like this nowadays, e.g. NetFlix, etc.).
Furthermore, if I might enter a more speculative territory, I'm not sure that the current licensing scheme is benefiting Fred either. For example, my subscription will expire in about 5 months, but so far (if I remember correctly) I've benefited from a single stable release (v2.31) in the whole duration of my subscription. Surely, I have no interest in renewing the subscription today, because I'd loose 5 months of potential updates; but also I might not be motivated to update it at its expire time either, unless there's a new release.
The point is that some users might decide to update their subscription only if there's a new stable release, and if they deem it worth it, otherwise they might procrastinate renewal based on the reasoning that delaying it six months (for e.g.) would increase their chance of "catching" one more update with it. Hence, the two-years scheme seems more reasonable and relaxed, for all parties (seller and customers).
I'm also strongly in favor of a life-time license, at a higher fee. I think this would be particularly useful, especially in this initial phase of the language, which hasn't yet reached full maturity. License schemes and fees don't need to be written in stone, and Fred could change the schemes at any time, and even withdraw the lifetime subscription when SB is full fledged. From my experience, during the initial stages of any software, licensing schemes and fees should be more forthcoming, as a reward and incentive for early adopters of the product.
If I may end this license thoughts with a practical consideration, after having purchased SpiderBasic for a project I was working on, I immediately realized there were some problems with the SB license file, which apparently is merely taken from PureBasic (as is). See this post on PB Forum for the details:
You only need to compare the license files for SB and PB applications to see that their identical:
According to the SB license, it contains third party components like PCRE, Scintilla, etc., which is quite unlikely.
Ultimately, when I discovered this license problem, I didn't use SB for the project I intended to use it for, to avoid any license breach problems. I'm not complaining about it just for the sake of it, for I'm OK with supporting SB (also as indirect way to support PB development, as I've also done my occasional small donation to support PB), but rather I'm trying to point out that the product's maturity is not only measured in terms of functionality, but also other issues like third party components' licenses, documentation, etc., which all contribute to defining how mature and usable the language is.
Being a PB aficionado myself, I tend to be rather lenient when it comes to various issues (bugs, out of date documentation, etc.) with PB and SB, and I do understand the amount of work it takes to maintain and develop these two projects, and also manage all the community requests, etc., and that Fantaise Software is basically a one-man company, even though the PB Team does add a couple of people helping out.
But ultimately, SpiderBasic is a commercial programming language, and as such is must meet the standards of a commercial product. The license problem described above is no small issues, especially if you are a small company creating a commercial product; imagine if you received a legal notification by the lawyers of the creator(s) of some third party component which is not properly licensed! That would be the worst nightmare for a small software company.
I'm not even sure if SB uses third party components at all; but I'm definitely sure that the current licenses file doesn't mirror its actual components — and crediting components which are not part of a software is a problem too, for you're basically lying about what it contains (it's ingredients, so to speak).
In the end, when I bought my SB license it was out of immediate need for a project (for which I wanted to recycle some PB code I had written), but ultimately ended up not using it due to the license problems. I will still support SB, and at some point renew my license, but the problem remains that I would not consider it using it for any public project until the license problem is solved.
