Jeremy Taffel writes:
If you want to be read please send plaintext only. Per ----- Original Message ----- From: "Jeremy Taffel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 27, 2002 11:20 PM Subject: Re: [ql-users] Source Code ----- Original Message ----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 27, 2002 8:34 AM Subject: Re: [ql-users] Source Code cut ...et al. Just put this in so that everyone else on the list knew that I wasn't trying to have a private discussion with you, but was interested in their approval/disaproval. Big cut > May I suggest the following additions/modifications to the >licence. All suggestions are welcome - provided I don't have the duty to implement any or all of them. They are just that, suggestions. I can't make you do nything -unfortunately ;-) > a) The Registrar undertakes to accept and distribute any >submissions > received that are essential for the continued support or >development of any hardware platform. No. This has to be reworded to take into account that I may refuse a development which is not in the spirit of things, i.e. could profit all machines but (deliberately or through shoddy workmanship) doesn't. Moreover, this will go into an annex to the licence, not the licence itself. I refuse to be bound by too strict rules. Note the use of the word ESSENTIAL This is to prevent hardware developers being left high and dry. I cannot see how the cases you just described can be considered essential. ( I wonder how many of the disagreements are due to the semantics of language, as opposed to real disagreements). Reword if you wish, but please retain something of this nature somewhere in the licence > b) Any developer who informs the Registrar of the intent to >develop > particular facilities/enhancements will be provided with a list of >any known > conflicting or duplicate development activities. I intended to do that anyway. So no harm in stating it, so that that everyone knows? > c) Any developer will be given a written explanation for any >submission that > is rejected. ( Do we need an appeals process?) No, my decision is final. However, I hereby officially authorise anybody to publish, here or elsewhere, my refusal and the explanation I could give as to why I refused a submission. Don't you think that this will keep me "honest" ? Sorry, do you mean that you refuse to give reasons, but are happy for us to speculate on this list, or are you stating that we don't need an appeals process, but that you will explain in private? Disagreements can obviously be aired on this list. I don't think anyone doubts your honesty, only your judgement. (Everyone makes mistakes). I tend to agree that we don't need an appeals process. > d) Any commercial development requiring payment shall be kept > as separate > modules to the core operating system. No, absolutely not. There MAY be commercial developments that are integrated into SMSQ/E. I don't know that there WILL be. If it can be done that way - OK. If not, then that's just too bad and the development will be incorporated into the "core". But would you allow it to happen if it COULD be implemented as modules? > No development will be accepted which > prevents the core operating system to be used without the >purchase of the > commercial module. No. See above. > Users who so desire, can purchase the core operating system > alone. No, this would be entirely against the philosophy of having a coherent OS. Taken together, these 3 Nos capture the problem. You may decide that it is desirable to accept some commercial offering into the operating system which no-one wants to spend the extra money on, and in so doing (inadvertantly) kill it, and stop any of the other commercial developers from making any sales. Say I were to integrate the internet into the operating system (like Windows 98), and ask you to charge �100 a go. I could advance all the specious arguments that Microsoft came up with as to why my development is an integral part of the OS, and can't be modularised. I hope you would tell me to F*** O**. What if, I had done that with the licence in my hand expecting it to be accepted. Perhaps at an early stage of design I made a design decision which forced it into the core operating system, but if I had known that this would be received badly, I could have modularised it. By the time you reject it, much rework is required to modularise it. If only the licence had that clause in it about the core being free of commercial offerings, I could have developed something to be stand-alone from day one. I might not get many sales, but at least I have a product! > e) Binaries of the core operating system can be freely distributed > provided > that they are accompanied by a prominent warning that a fee for > registration > must be paid before any support (or full manuals???) can be > > received. No, I don't agree. Distribution of binaries via the resellers, is, IMHO, a better way. This also applies to your other comments below. I have stated the reasons for this a number of times, do you require this again? As I said, it is your decision when to end the discussion and get on with things. However, Consider scenario 1. You accept my proposed changes. Richard develops UQLX for SMSQ/E, touts it with Redhat/SuSe/Mandrake/Slackware/Debian (at least one is already interested) , and as soon as one has it, the others want it as well because that is the way they are). ....user buys/downloads set of CDs Does a full installation, and starts to play. Soon, in a fit of nostalgia, he finds himself playing with the emulators. And "what is this??.... a QL brought into the modern world?! Wow, I wonder if I have any listings of my old SuperBasic programmes??", then " I can't work out how the demo's do XYZ, pity the documentation isn't up to it, better send of my xx Euro (10 to TT, something TBD to a reseller to pay for his support) to get some support". Multiply that by n% of the Linux world and even though n is small, it represents a worthwhile increase in our community. These users then start to buy or even develop applications software, the QL compatible scene is rejuvenated. Scenario 2. Licence stays as proposed. Richard (against his better judgement) develops UQLX for SMSQ/E, puts the UQLX part of it on his website, which only gets visited and revisited by the the same crowd. The resellers report no interest. What does he do now? Spend money advertising it? As far as I can see, he won't even be able to put a limited functionality demo of SMSQ/E (like that which accompanies QPC demo which IS downloadable) on his site, nevermind onto Linux distributions. (In this day and age, who is going to buy without the opportunity of trying?) So He shrugs his shoulders, and tells himself he was right in thinking it would be a waste of time working with the licence! You smugly reflect that you were correct, there are no new users to be found. SMSQ/E and the QL scene continues its' slow terminal decline. But of course, neither will happen. You won't change the licence, and Richard won't develop UQLX under it. I will continue to use UQLX with Minerva for "legacy" work , and use other operating systems for everything new.Eventually another long time user lost. > I for one am a potential new user for SMSQ/E, but only if/when it > is running under uQLx. Wee, yousee, what prevents you, from my pont of view, to get SMSQ/E under UQLX, apparently, is not the licence, but the fact that one man, Richard, Zidlicky, is unwilling to work under it. I think that my illustration above explains why it is unreasonable for him to work under this licence.If he doesn't develop it, I won't blame him at al l. His view, while unfortunate for me, is logical, and in his position I would do the same. > These are only suggestions if you don't like them, then fine. The question isn't really whether I like them or not. The question is whether they will be able to create an envrionment where everybody, including the resellers and authors, will be able to work. As you mentioned earlier, there is a rift - I see that rift between those who, like me, want to ensure continued support fro SMSQ/E, and see that as coming in a great part from the resellers and comemrcial work, and others (like Richard) who want a true "open source" (incuding binaries). Like you, I have come to the conclusions that these positions are ot reconcilable. I try to do what I think is right. My suggestions were intended to provide the best of both worlds. I don't think that any of my suggestions would hurt the resellers. The opposite; As has been pointed out, they don't actually make much of a living out of it, so "commercial is a bit of a misnomer. It is only by expanding the user base that their sales would increase. My suggestion could hook new users with something that is free initially, but needs a payment to get documentation and support, and then further payments to buy the commercial add-ons which I hope get produced and although not essential turn out to be highly desirable. What is wrong with this logic? I have no problem with the resellers providing support, they can finance. Even if my belief that the user base can be increased is wrong, why would the existing users, developers or resellers be served worse by my suggestions than your original model? Perhaps I am stupid, but to me, your respond reads as REPeat until EOF Print,"NO I don't agree. My way is better" END REPeat but you don't seem to have explained why you don't agree (other than it is not what you had in mind), or who benefits your way. So, perhaps you could explain it to me, because I really don't understand how adopting an approach which is going to drive developers away can be of benefit .(Please don't tell me that is their choice - the illustration shows why there is no choice). > As has been > said, as the Registrar, you should do what you think is right. I do > think however, that this discussion could go on for ever, > >preventing the development work from ever starting; so one last >suggestion.. Post a cut-off date when the discussions end and >you publish the licence. > > Regards, Thanks - I have already had a half hour to begin drafting the licence, and will publish it here in a few days. I would like some input on it when that is done. Your idea of of cut-off date is great,a nd I will make sure to include it. A pity you didn't like any of the rest of my ideas then! Jeremy P.S. Having just read Roy's response, it seems that you and he have a different view as to whether commercial offerings will be accepted into the core operating system. No wonder I'm confused. If he has no problems with some of my suggestions and even thinks that some of the ideas have been agreed already, why are you so negative?
