> >> programmers writing the [platform] support... should not contribute that > >> support in the first place. The part that they should contribute are the > >> changes necessary to have this support as an external module, AND THAT'S > IT. > > >sort of BIOS? No problem but the problems with generic SMSQ remain.
.... > Next big candidate is the OS bootstraping. There is a lot that happens > before the actual OS takes over, yet there is no way to change this > speciffically for a platform unless the actual start-up code of SMSQ is > changed. This should be a module. actually it should be something more like a BIOS, without all the weird aspects of BIOS. > You mentioned in another email that it > may benefit 'some strange hardware'. Actually, it doesn't have to be that > strange at all. One good candidate would be an emulated system without a > host OS (i.e. hardware intended to run SMSQ based on a different CPU). in this case it is part of the emulator, not SMSQ. SMSQ will than probably have no HW drivers at all except stub drivers to transfer control to native code. The drivers could in theory be part of SMSQ but I suspect you would very quickly hit the limits of the current emulators. Things that are necessary for HW access aren't always emulated properly. > >> * Problem: special platforms like emulators that may have parts of the > OS > >> rewritten as native code. It would be in everyones best interest to > >> devise a standard way of doing this, not just for a speciffic case but > as a > >> general resource (yes I am aware this is not easy!). > > >I don't see rewriting parts of the OS as useful, only OS part where > >emulators spend noticeable time are screen drivers. > > That may well depend on the particular case, some emulators are closer to > the real machine than others. A way to go into native code for cases where > this is needed would be a good idea. Candidates, aside from graphics you > mention would for instance be floating point operations, and parts of > drivers in general. FP should be emulated by emulating some of the 68K FPUs. I am definitively against rewriting SMSQ itself or QDOS application software in "native code". There are at least 2 good free just in time compilers available out there. All current QL emulators have *huge* speed reserves so fix the emulators. > > I agree. Essentially there is very little work to be done to the core > > OS, mostly bugfixes, a few missing features on various platforms and > > a better framework for supporting filesystems. I do not believe that > > this would require "commercial" development. > > Neither do I, but I don't think that work on the core OS could be called > 'minor'. > There are things that could prove quite demanding, for instance interrupt > handling (multiple levels), memory management (slave block problem), > multiple processors... multiple processors? SMSQ won't be the hardest part, it is all the applications that have no idea there might be another CPU and do fun things like manipulating system variables. Loadable drivers will also be a nightmare. I don't think interrupt handling would be any problem. > >> Availability of the binaries in any circumstance cannot be guaranteed, > >> and it is absurd to even ask this. > > > sure. On the other hand, should the license explicitly prohibit > > someone from compiling and making the binaries available when > > noone else wants to support this platform or the master repository > > gets struck by a meteor? This is absolutely ridiculous and I am > > becoming tired of reading about buses and meteors as an excuse > > for poor license. > > Of course it is ridiculous, but if you demand a guarantee (without > gualifying it somewhat, and preferably in detail), you can expect your > demand to be taken to it's absurd exaggeration. > .... > I suspect one of the things you are getting at is support for a platform > that may be considered 'obsolete' rather than 'lost interest in'. For > example, a platform is 'abandoned' (no hardware suppliers, for instance) at > SMSQ X.YZ, and since then SMSQ has progressed to > X.YZ, yet you cannot > provide binaries X.YZ _for_free_. I wonder if it would be possible to > automatically make old versions of the binary free - I mean, sufficiently > older than the current one. Otherwise the scenario outlined should be > somehow catered for. well all the users in question already bought SMSQ so why so complicated? Simply allow free distribution of binaries for that platform. I do not require a guarantee that someone actually will care to compile the binary and make it available, nor that it would work. I want a guarantee that he is allowed to do it without artificial hurdles. We have already have hundreds of "discontinued" projects in the QL market and typically extremely small series so I think this is of no little importance for the user. And if the user thinks the licence could shoot his feet than he will go elsewhere. > >Show me an open source project that would be so openly arrogant > >to the users as to create artificial hurdles if they wish to help > >themselves. > > I think this is a case of improper semantics. you think so. But should we really loose every comparison with systems that are completely free hands down? It is bad enough that SMSQ is technically slightly behind. It desperately needs to attract developpers and users otherwise it is a dead project. > My point is, no it's not 'Open source' (note capital O), but it's still > better than what it was thus far. At least now you can get to read the > source and see if it's worth your time. I am really wondering whether its better than it was so far. Beeing somewhat involved with a few projects I have learned a lot about SW licenses. Should the license be approved as it is now than it is by far the worst licence I have ever heard of. As you say, it is more open than it was so far, unfortunatelly it is also much more open for abuse. > >> * Problem: a LOT of work needs to be done to SMSQ before it reaches that > >> stage. This work is ABSOLUTELY NECESSARY in the long run. > > > Consider the Q40 hardware - all drivers except parts of keyboard > > handler and soundsystem are fully generic. You supply different > > constants for the IDE definitions, 16550A base address etc and > > it will work on every other machine that uses this HW components. > > Hardly - interrupts would be a problem for one thing. The way it's > currently set up, you either have to emulate one interrupt as it's set up > on the QL or as it's set up on the Qx0. > A good case could be made to have multiple interrupt levels (as long as > their usage is clearly defined) for certain peripherals. this is way easier than you make it appear, you need a machine specific interrupt dispatch routine that would do the dispatch to the SMSQ supplied handlers. The rest is fully portable. So far SMSQ uses interrupts only for serial ports and maybe keyboard so everything else is really fully generic as I said. > Another thing would be some specifics for peripherals that may not be > currently supported, as an example I can mention the FIFO in the floppy > controller (this would enable true background floppy operation). if you have a FDC with fifo. Background operation should work even without it, it does work on Linux and SMSQ should have big advantages here. > >sure, but: > > - distributing source by snail is costly. I would be a complete > > idiot would I volunteer to port SMSQ to UQLX and then have > > 10 Euro expenses on each copy I would send out to anyone. > > I agree, which is why I put that in the 'problems' section just after this > paragraph. I can see some sense in not wanting the source to end up > 'everywhere', with this licence (it could be a different matter if it were > truly 'Open source'), and I suspect the snail mail is a 'slow down' > measure. OTOH, if the source does end up 'everywhere', it would be very > difficult to trace how this happened, who is responsible, and how to > enforce the licence prohibition to do so. > IMHO two exceptions are worth considering, both to do with a class called > 'developer': > One is beta versions of something that have to be tested, the other are new > releases of the source. The fact of the matter is, not everyone can use > IRCs (If I were back home in Croatia and asked for them, they would laught > their asses of, and once they managed to get their senses back, they would > say 'don't tell me you actually think you live in civilisation here'). > There are many ways this could be done, but the problem is really agreeing > on something that everyone can do. For instance, you could do a digitally > signed PGP, kept on file. Ask the registrar by sending the signature, which > is verified against the PGP key on file, and if it checks out, he sends you > the sources PGPd with your key (on file) and signed with his signature (so > you can verigy the source). But now try to agree on the exact same version > of PGP... the one which works under QDOS course :) The whole argumentation is a joke imho. If the registrar agrees to a more realistic distribution method then he should make it as simple as possible. Nobody will upload it for fun to hundreds of sites, and if he should than this would paradoxically only strengthen the authority of the registrar because he would be then the only one who has the real sources. > > - you can't "distribute" the assembler/linker that easilly, > > iirc they are Quanta property. > > I think only the linker, but I though it can be freely distributable? There > is a free assembler, assuming of course you can assemble the sources with > it (gwass?) no idea, the code makes some use of macros so this may not be trivial. I've not looked at the (c) status of Quanta assembler and linker closely. > > - you need at least TK2 to do the bootstrapping > > Not sure what you mean here (I may be limited by the platform I use) it means that you can't grab freely available tools and software from the internet and compile SMSQ. > >This might be easy enough for QDOS tinkerers but should I dare > >to offer this on freshmeat.net they would in best case laugh > >at me. Look how many excellent OS's are available under GPL > >licenses, it doesn't have to be Linux. > > Well, agreed, but this is not GPL. Wether it would be better if it was GPL > is a matter of opinion, with TT ultimately being the one who decides under > what kind of licence SMSQ will appear. You can try to influence him in that > direction. Until the licence is hammered out, it is after all still HIS > stuff. it is *his* stuff even afterwards, except for code other people may eventually write. > >> Also, from this licence, it follows that TT, should he wish to > contribute > >> to the core, would have to do so under the same rules as everyone else! > > >imo this doesn't follow from this license and I don't care under which > >conditions TT would contribute. > > I think it does follow by virtue of not making an exception for anyone how > to submit anything. One problem would be the registrar himself (see what I > wrote about conflicts of interest, balancing the registrars powers with the > contributors, peer review, etc...). no. Copyright holder has the power to grant whatever special permissions to whomever whenever he likes, especially to himself. Other copyright holders may than disagree for their code to be used under this conditions. Licencing and copyright can be pretty hairy and for this reason I think the licence needs to be very well crafted and clear. Richard
