On Tue, 26 Mar 2002, Phoebus Dokos wrote: > >In light of Dave's clarifications I must totally agree with him.
Wahey! > That should read Wolfgang's clarifications and not Dave's :-) Oh. Booo! Funny thing is, I can see many sides to the debate, and when I read your email saying you agreed with me, it seemed you did. Now you corrected yourself to say you agree with wolfgang, I reread it and it still seems you agree with me. :o) Please reread yourself, Phoebus, and separate the *intent* (where Wolfganga nd I are in 100% agreement) and the implementation (where we're not, and you recommend changes also) May I propose the following... That there be two licenses: A reseller/user license, which allows for profit distribution of sources and executables by resellers, and not-for-profit distribution of sources. A developer license, which allows not-for-profit distribution of sources and executables by developers, with the following limitations: Executables may only be distributed directly to known parties, who are forbidden from redistribution. Executables must be marked BETA on the startup screen, with a statement of who produced the executable and when. They may not be distributed to more then 10 users, or 1% of the user base, whichever is greater (which allows reasonable beta testing). They must be uniquely identifiable. Where a beta executable is distributed, the recipient name and contact details, and the unique identifier in the executable, must be forwarded to the code maintainer. Where the system has a RTC, the executables must not exceed 30 days useful life. Where no RTC is available, the beta tester must accept a 30 day limitation on use for that particular version. If the developer later needs to include the executable with a hardware product, he may obtain permission directly from the maintainer, and when given, seek bids from any authorised resellers for fees for the number of copies intended to be manufactured (bearing in mind the developer is making the copies and all the reseller is doing is extending a license for X number of copies at no cost to themselves) so appropriate license fees flow back up the tree to TT. The maintainer could grant or deny permission based on compatibility, but would not unreasonably deny permission where there are variances, if the product is designed for a very specific use that would not affect other users (eg embedded, control, etc) and/or the change is a superset of existing functionality that is clearly stated not to be standard. If a user already has a licensed copy of SMSQ, a developer should be entitled to include the modified or updated version at no cost to the user. This should be true for same version groups only - eg an upgrade from 2.X to 3.X would be chargeable but from 2.2 to 2.3 would not. Thoughts? Dave
