On Tue, 26 Mar 2002, Jerome Grimbert wrote: > } The decision to have two official sellers of SMSQ/E is flawed. It prevents > } growth to not have a clear way for additional people to become resellers. > } If there isn't a way for people to become resellers, it's also probably > } illegal. There should at least be a procedure for one person in each > } country/territory to apply and be accepted as an official reseller. > > That's easily answered by specifying either that: > - Reseller must be directly nominated by Tony Tebby.
Reseller Nominee forst has to get TT to acknowledge him and respond. > - a would-be-Reseller must get clearance from the college of actual Resellers. > the procedure for the college of Reseller is up to them. > In case of conflict, the coordinator or Tony Tebby get the final word. This would clearly be illegal under anti-competitive legislation in the EU and US. <SNIP - regarding no fees for distribution> > Outdated argument, might has been valid ten years ago. > Moreover, personnaly speaking, as I'm still the QLCF librarian, > French people could get free access to the sources from me the same > way as they get access to the QLCF library (even more easily, > because accessing the QLCF library required to be on the right list!). > I would not have to make any change to my management for these sources. If I want to download the source, I could. If I don't have access, or have slow access, I have to send some IRCs (which I can't get here) and media, and wait, and they have to burn and return, and I have to wait. How silly. > The only way to force fancy developpers to share their code is to forbid > the distribution of binary. This way, code related to new hardware is > forced to go back to the coordinator for inclusion in the main code. What happens when this is, as I said, custom hardware? The code would not be accepted into the master code tree. If the code is customized enough to not be relevant/applicable to the main code tree, you can not release your code except as sources. So, for argument's sake, I decide to make a new QL add-on which requires SMSQ, and it handles files or devices in a unique way, and my code submission is rejected as not relevant (which would be the right thing for the code maintainer to do) I can never burn that cod eon an EPROM and ship it - my customer has to compile the code and burn the EPROM themself. > It is also the only means to have the reseller doing their work. Only if the code is relevant to the whole community and is accepted, or if the master sources quadruple in size, and are full of #includes for each branch *yuck* > Your argument for beta-testing is void, because, for a beta, I want > to have the source available. Thus you distribute the source, I compile, > and get back to you with comment on behavior and code. > Testing a black box is not a good testing for code! > Dissiminating time-unlimited beta is not a good thing either! The kind of beta testing you describe is the minority of testing. Say I sell an XYZ to Fred, and he has a problem, and I suspect the bug may be ABC - I have to send him sources and get him to compile them. Now, Fred is a) not equipped with the software tools to do that, and b) doesn't know how. It makes helping your customers difficult. Homogenized SMSQ. One code tree fits all, and if you're outside that, the license forbids it, unless your customers are all knowledgeable programmers. No customer service for unique situations. No testing patches or updates for custom hardware. You're not allowed to help the people who most need the help. The future board I am working on will be flashable. But that feature is rendered redundant because my potential customer would be required to download/be sent sources, plus the tools to compile them, plus detailed instructions on how to use those tools. I can't just send them an image. That is such a major issue, as a developer, I would just use a different OS. > He should provide its sources to the coordinator, > Get the status of Reseller (see first point) or buy them the needed binary > for the customer or just refers its customer to the Resellers. I like the idea of providing the sources to a reseller, but again, there are practical considerations. Hey, maintainer, here's versions for you. 0.1, 0.2, 0.2b, 0.3, 0.4, 0.4X (custom for Fred), 0.9, 0.99, 1.0, 1.0a Now, no developer will work in isolation. There will be, maybe, 5 people who would have hardware and be using/testing, and some will be capable of handling sources, and some wouldn't. Do the math. It's bulky, lots of excess work, and not relevant to the SMSQ code tree. Also, say I write something, which is new, but needs to be part of SMSQ, like, say, a complete new FS. I want to retain my (C) and collect fees or royalties. How do I do that? (No, this isn't happening, I have my devil's advocate hat on). Modifications to TT's work create a derivitive work to which he retains copyright, but an entire new FS that doesn't base off his work would have its own copyright, which would remain with me. This clause is, in its own way, more virulent than the GPL. It allows but discourages development. It makes distribution of anything not 100% mainstream virtually impossible. It removes any commercial incentive. If it adds value, the two resellers reap the benefit. How could you disarm the devil's advocate position? o Allow non-commercial, free, distribution of binaries for testing purposes only (not for general/public distribution) o Allow people to set up sanctioned branches of the main code tree o Allow developers with unique requirements to pay on a published fee schedule for the right to distribute a fixed known quantity of binaries, say in flash, with a right to offer upgrades to existing customers. Dave PS: This is devil's advocate, not my personal opinion.
