On 27 May 2002, at 23:20, Jeremy Taffel wrote:
(cut) > They are just that, suggestions. I can't make you do anything -unfortunately ;-) Ahem! (...) > 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 Umm, ket's suppose somebody change WMAN to use the new colour drivers (sounds ESSENTIAL to me), but in such a way that only the Q40/Q60 could profit from it (or only QPC, or only the QXL). Wouldn't I be right to refuse this? On the other hand, suppose the same situation arises, but the only reason it wouldn't work on the other machines was the fact that the screen layout is different, and that it would take only a trivial amount of work to adapt it, with the changes fully documented. Wouldn't I be reight to allow it in, and ask the "key developpers" for the other machines to see whether they could adapt? The problem is that htese are situation for which it is extremely difficult to provide for in advance - you have to rely on me being reasonable. > > 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? Ok, why not? > > 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. No, if I refuse something, I HAVE TO tell the developper why. To me, that seems essential, if only because I (still!) believe that most developpers, if not all, will want to play by the rules. Thus, me telling them why I can't acccept a development will be (I hope) more along the lines of attempting to correct an honest mistake, for which, of course, I'll need to point out the mistake... Since these things will probably be done via private mail or email (I'm thinking about it, see!), the developper already is allowed to make this issue public, which I belive, is a good safeguard against me being unreasonable. (commercial developments) > 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? Well, juts about ANYTHING, apart from very "initmate" things (e.g. a new scheduler) can be done in a separate module, so that would somehow make the entire point moot... However, I admit that this point requires further thought. The trend here on this list seems to be that commercial developments should be kept separate. In fact, apart from mine, there seems to be no voice advocating for letting commercial developments in, even if they would be essential, other than through modules. So I'll bow to the vox populi, keeping my fingers crossed that we don't cut ourselves off from important developments. > 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**. I agree that these are some of the important points, together with the binary distribution restriction. What I would do, if anybody wanted some commercial development to be paid for, is that I would ask all of the resellers if they thought that the price asked was something that could be sold because, to be quite frank, I try to keep away from teh commercial side as much as possible. If yes, then we would see how it went. If not, I'd probably (attempt to) negotiate with the author. . > 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! You could also contact me early on and tell me about your expectations. I could then let you know -admittedly in a tentative way- what I think about it. (cut) > > As I said, it is your decision when to end the discussion and get on with things. >However, (cut of the 2 scenarios) I'm not sure how likely any of these will be. I rather think that, if new "linux" users have a look at the system, they'll run away pretty fast, since there are no killer apps, no modern window manager etc... I just can't see it happen. As for scenario 2, Richard could become a reseller, and point this out on his website. After all, all he has to do is pay 10 EUR to TT for each copy sold. After that, upgrades can be free. Is that really so difficult. He would NOT have to advertise, since, in your scenario, it would be the people that come to him... As for the SMSQ demo version, this results from a prior agreement MArcel Kingus has with TT, and which is NOT changed by the licence. > > 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 all. His view, >while unfortunate for me, is logical, and in his position I would do the same. I wouldn't. > > 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 The problem being that there is no EOF... Whereas your argumantation would be: Rep lp print "Do what I want" end rep lp Seriously though, I still don't agree. The resellers are better off when selling the binaries rather than entering into a support contract, because the user gets something immediately for his money AND the support later on. The user also is better off because of that as he can immediately see into what he put his money. TT also is better off, because he can be sure to get at least a little reward for his immense work. Your scenario where the user, after having problems says to himself "oh, now I will buy support from a reseller" is so unrealistic as to be utopean. > 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). That is simply not true - they DO have a choice, and nothing you have said above invalidates this. As to my explanaing myself, I have the feeling that I already have set out what I have just said above so many times,that everybody already has seen it. Were the above reasons suficielntly clear (mind, I don't ask whether you agree with them, bacause you won't, but were they at least intellectually understandable?). (cut) > 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? Because the scheme I set out is what I had understood from the Eindhoven discussions and had agreed with TT. I must also say that, personally, I still am against excluding them, and obliging any commercial development to be done only in modules. I perceive this as being against the aim I try to achieve, i.e. have a single coherent version. If you have 10 different new modules, then you may have many things, but not a coherent version. We then run the risk of having something like the Windows DLL situation, where one version of a DLL will not work with another, or conflict with something else on the system etc... These kinds of conflict are easier to avoid when you have a monolithic system, as then you can test something new under a single condition. However, as mentioned above, since now everybody on this list seems to agree that commercial developemnts should be excluded or obligatorily put into separate modules, I'll go back to the drawing board and think about it some more. This also means that, far from not "liking" your ideas (or anybody else's), I always take them under consideration... Finally at least this discussion and the fact that Roy and I don't see eye to eye on it shows that I am not being "remote controlled" by Roy, as some seem to have feared... Wolfgang
