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
anything -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 all. 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!
