On 22/05/02 at 14:28 Dave wrote: >> The part that they should contribute are the changes necessary to have >> this support as an external module, AND THAT'S IT.
>So who develops the kernel? That is a good question. It is really a cooperative effort, and the key to keeping it that way is finding a balance between the authority of the registrar and the contributors. The registrar has the final word on what goes in and what stays out, but this is balanced by the fact that he can only add what he is given in the form of contributions. In addition, it is reasonable to expect that the registrar will get feedback from people who get the new official core releases, and may consult others about his decisions, so that's another way his decisions can be influenced. This is why I mentioned that some reference to a set of guidelines will have to appear in the licence, the above needs to be formalized. It seems to me that one major concern is about how reasonable the registrar will be. The fact of the matter is, no regulations can guarantee a reasonable registrar - you can only implement a 'security measure' in the licence. One way you can do this is implicitly: if the registrar is unreasonable, the probability of someone sufficiently modifying or completely rewriting the OS using the source as a reference, to 'free' it from the constraints of the licence, and doing whatever they want with it, becomes higher. This possibility may not be such a bad thing (and it is extremely difficult to do anything against it anyway - with or without available source, availability of the source just makes it easyer. Another way is to do it explicitly: for instance, having someone/body that can veto the registrar's decision. If you want to expand that concept further, you can appoint a board of 'consultants', which then begs to define under which circumstances one can become a member, or stop being a member, etc (after all you have to guarantee that the board is reasonable too) - and you are well into red tape already. The reality of the matter is that the registrar is going to consult other people, and is more likely to consult some people than others. For one, the author of a contribution will be consulted if the contribution is unclear in some of it's elements. Then, people like TT, Jochen Merz, Marcel Kilgus, Joachim Van Der Auwera to name a few, are likely to have stronger voices than others. It would be very difficult to formalise a board of consultants right now, but effectively, some people are just that - people who are/were 'closer' to TT than others. The best you could do is to 'invite' a starter set of people and have that starter board vote in other members - and you would then have to include a possibility for a member to resign or be voted out. After that you get into conflict-of-interest issues with people who are developers and distributors, and defining wether it really is a conflict of interest or not, etc. The other way is sort of retroactive - through peer review, i.e. feedback. Anyone who gets the source can review all the inclusions, and provide feedback about them. It would even be possible to include, with the authors permission, contributions that are in the process of being decided about or even rejected, in a distribution, or even separately. This is really implied as, again, no part of the OS is 'the last word' and that includes contributios. As they say, there is always one last bug somewhere. This has repercussions to the notion of support as well. The registrar has to keep a trace on who contributed what. A contribution where no support (guaratees of absolute functionality, usage in life support systems, etc, etc) is intended or implied, is entirely possible. It would be up to the registrar to decide about this. Wether there is a board of consultants that gets to see this and can influence the registrar before the fact of inclusion, or it's negative feedback that gets it excluded (assuming it influences the registrar) is something to put in the guideline document mentioned above. >> Under the licence, nothing prevents anyone from rewriting the whole thing >> based on the source, and then doing anything you please with it. As long >> as you don't submit it to the registrar and it's not added to the official >> release, it is not covered by the licence. >Aye. And if I send 100 Euros to TT, I can get SMSQ, mod it any way I see >fit, and sell those new versions under the first sale doctrine, outside of >the license, as they're licensed copies. Can of worms. :/ This is something that is ONLY up to TT. Wether he has surrendered rights to further licence SMSQ or not is something that has not been mentioned so far. This certainly needs qualification in the licence. My guess at this point would be that TT himself would have to work under this licence as well. It may give him the right to licence the current SMSQ 'snapshot' elsewhere, but it should not give him the right to suddenly proclaim something else the 'official' SMSQ. And, just like everyone else, he can rewrite the whole thing and put a naw name to it, and get from under the licence, and he would be in the best position to do so. But it's (c) TT anyway, so this is a given. >> The registrar will, if something really happens with all this and things >> do take off, find himself overwhelmed with the task of actually having to >> know and understand intimately every nook and cranny of the SMSQ sources, in >> order to make decisions about it. >And have the ability to test it on any and every hardware combination, or >on hardware that may itself be under development and changing ten times a >day. Which is one more reason why specific hardware support must not be part of the core _in_principle_. The point is NOT: "give the developers the chance to test and debug under the licence", rather: "have the developers develop, test and debug without ANY licence being involved". The problem I have with the flurry of argument (left over after I delete the various squabbles with epithets and metaphors in them every day), is that people keep repeating that completely free binaries _of_SMSQ_ MUST be alowed for developement. I am fully aware that for the time being this will have to be the way to do things, but let's be reasonable: this is pulling in the wrong direction, and it should have limitations. A parallel: The windows equivalent of that argument is that the source code of windows must be available just so you can recompile it with the driver for your new hardware included, and then the distribution of binaries must be alowed so you can freely and quickly distribute binaries to your testers. Try pulling that argument there and see them die of laugther. I'm not saying that the licence as it is now is the best possible one, what I am saying is that some arguments have become cases of not seeing the trees because of the woods, and verging on not being worth the bits they were encoded in. Expecting the registrar to provide support is equally futile. The registrar should be the one that knows WHO can provide support. This does not mean that he must not provide support when he can or wants to. As I said, the registrar has to maintain a 'trace' of contributions in order to be the final authority that can point the distributors, and indeed other developers to the origins of the code they find problematic. It is up to the distributors/developers to then contact these people and see if they can get to an agreement. If a developer is about to develop something that will impact other platforms, it would be in his best interests to include users of those platforms (or indeed their developers) in his alloted number of testers. As far as the registrar is concerned, if he gets a contribution stating that 'it works on everything', he is encouraged to consult prominent developers/contributors about this and verify the claims. If it turns out not to be so, the registrar can either reject the submission, or more likely, return it for corrections or include as a 'beta' alongside the official distribution, but not as a part of it. Once again, the traceability of the contributions through the registrar is what should provide the principal means support - i.e. who the author was. All that being said: I return to the argument that platform support should not be part of the core _in_principle_. However, once a new feature has been sufficiently established, there is no reason not to include it in the core, provided: a) it is sufficiently universal and properly documented (the licence guarantees that when included the source will be visible to anyone having the current official version where either peer review or the ability of a third person to make changes to it and re-submit takes over) b) it can be removed if needed (for instance, it's a module). During the lifetime of the core it is to be expected that things will be added and phased out and a mechanism for this has to exist. The reason for this is, many things can originally start as platform dependant and then cross-evolve onto other platforms. It would be the responsibility of the registrar to decide if/when a feature that started as platform speciffic should be included in the core. The original authors can, until that time, lobby with other developers or negotiate to agree on a more universal speciffication for the proposed feature, but all that has nothing to do with the licence, perhaps only in a very roundabout manner as such an agreement, be it verbal or more formal, may influence the registrar. >I agree with you 'mostly', that the emphasis of debate is on the wrong >things, but the things you discuss are not worded in the license, and the >things that *are* worded in the license are the rules under which we must >work. I agree, however i see no reason to word 'platform speciffic support is not a part of SMSQ core' in the licence. I do se reason to put in a reference to guidelines on SMSQ extension, then define those outside the licence. The reason is because the licence regulates the avaiulability of the source and not only it's expandability. Putting everything in one lump needlessly postpones the availability of the sources, and we are all debating about something only a few people really know sufficiently about to debate it. Nasta
