New GPL Name: ScarletDME
Diccon
name.
The project and product will now be called Scarlet DME (Data
Management Environment)
We've had this ready for some time but Its about time we announced it.
This should help everyone distinguish Between Ladybridge's Commercial
QM and the OpenSource version.
We can be found at http://www.ScarletDME.org (Same server as before,
just new domain available)
http://gpl.openqm.com will continue to function as long as Ladybridge
will have us.
Changing every name reference is going to take a little while so bear
with us and the name OpenQM and ScarletDME will be considered
synonymous until we have tidied up all the loose ends.
This is simply a name change, nothing else. We hope to continue our
good relations with LadyBridge and will happily share information and
code. Most of the current services will continue to work as they are
(Wiki, Subversion, downloads, website, etc). Any significant changes
change will be announced separately on the main page of http://www.ScarletDME.org
There is a new Google group (http://groups.google.co.uk/group/
scarletdme?hl=en-GB) , but your welcome to stay on OpenQM-OpenSource
if you don't want the hassle of changing. All developers will stay on
both for now.
--
Diccon Tesson
ScarletDME - The red hot Data Management Environment
http://www.ScarletDME.org
eppick77
anything about this. This is not a question that you are posting - it
is a statement of fact. WHO determined this course?
I certainly did not get to vote on the issue.
Eugene
On Aug 10, 12:51 pm, Diccon <diccon.tes...@gmail.com> wrote:
> Its worth noting the pure GPL version of OpenQM is moving to it's new
> name.
>
> The project and product will now be called Scarlet DME (Data
> Management Environment)
>
> We've had this ready for some time but Its about time we announced it.
> This should help everyone distinguish Between Ladybridge's Commercial
> QM and the OpenSource version.
>
> just new domain available)http://gpl.openqm.comwill continue to function as long as Ladybridge
>
> Changing every name reference is going to take a little while so bear
> with us and the name OpenQM and ScarletDME will be considered
> synonymous until we have tidied up all the loose ends.
>
> This is simply a name change, nothing else. We hope to continue our
> good relations with LadyBridge and will happily share information and
> code. Most of the current services will continue to work as they are
> (Wiki, Subversion, downloads, website, etc). Any significant changes
Diccon
It was initiated from the Developers mailing list. The decision to
change the name was detailed and discussed via IRC on the 7th of May.
Nominations continued for about a week and then a vote was cast on the
12th of May.
I'm very sorry you missed out on this, this mailing list here has been
considered the Users mailinglist since it's creation. All larger scale
decisions and votes have been held on that Dev list.
I am happy to send you minutes form the meeting if you want. If you go
to http://gpl.openqm.com/mailman/listinfo/openqm-dev to sign up to the
Developers list so you can follow and participate these kinds of
decisions. Please do come join us.
Never meant to Leave you behind Eugene, or anyone else, I'm really
very sorry.
Anyone who wants to help forge where the open source project is going,
please come join us on the Dev list, your all welcome.
-Diccon
On 10 Aug, 21:39, eppick77 <eppic...@yahoo.com> wrote:
> Where did this come from. This is the first that I have heard of
> anything about this. This is not a question that you are posting - it
> is a statement of fact. WHO determined this course?
>
> I certainly did not get to vote on the issue.
>
> Eugene
>
> On Aug 10, 12:51 pm, Diccon <diccon.tes...@gmail.com> wrote:
>
>
>
> > Its worth noting the pure GPL version of OpenQM is moving to it's new
> > name.
>
> > The project and product will now be called Scarlet DME (Data
> > Management Environment)
>
> > We've had this ready for some time but Its about time we announced it.
> > This should help everyone distinguish Between Ladybridge's Commercial
> > QM and the OpenSource version.
>
> > just new domain available)http://gpl.openqm.comwillcontinue to function as long as Ladybridge
Glen Batchelor
the stance of the rebranded project. The dev mailing list is where
most of the discussions take/took place. I'm not sure where I stand on
the whole thing. I still support the GPL effort, but not at the
expense of losing portability between commercial and GPL developed apps.
Glen.mobile
RewriteRule ^(garbage|junk)$ /$1 [NC,L]
Diccon
compatibility. There never has been I'm not sure where you getting
that from. Any breaks will because by LadyBridge, not us.
If Martin would actually tell us the bare minimum information on
future changes (opcode numbers he uses, or changes to byte code
formats) then we can match him or at least avoid treading on each
other toes, but so far the response to such information on the
QMClient system has been negative.
As we stand we will have to take a look at some Ladybridge code I
found that seems to show Ladybridge has put traps to prevent binary
compatibility from Commercial QM to OpenQM. But Personally I will do
everything in my power to maintain compatibility despite this.
I was aware you didn't respond Glen. You couldn't make the IRC meeting
that started the process, you said you weren't sure if you'd make it.
Hell I stayed up til 2am that night to relay what was said to you. I
waited for your response on the mailing list hoping you followed the
discussion and read the minutes I spent hours writing up. But had to
presume you weren't interested or were too busy by the end of the
week. I wasn't going to badger you as I knew you received the mailing
list messages and were very busy.
I'm getting a bit hurt by all of these suggestions of cloak and dagger
as I have put LOT of work to make this open and fair. At the same time
making sure we are not sitting on our asses. Especially since I can
clearly show records of my efforts. The discussion lasted over a week
and many people voiced their opinions. I'm sorry if some of you missed
out.
The decision to re brand was unanimous from the IRC meeting, and as
quoted in the main list even suggested by Martin. It was simply down
to what we called outself's.
My mail on the 12th of May to the dev list initiated the Vote:
-------------------------------------------------------------------------------
Subject: A Rose by any other name
>Can I have final votes please for the name you want as our new name:
>Scarlet / ScarletDME / ScarletMV
>Rebel / RebelMV
>Requeium
>Reloaded / ReloadedMV
>Q*Base
>ChrysalisMV
>Those that have voiced an opinion but do not respond, your final words will be counted as your vote.
>I'll close this up same time tomorrow unless its obvious what has one earlier.
>Thank You
>-Diccon
On 11 Aug, 17:23, Glen Batchelor <batch...@bellsouth.net> wrote:
> I don't remember there being a vote and I still don't agree with
> the stance of the rebranded project. The dev mailing list is where
> most of the discussions take/took place. I'm not sure where I stand on
> the whole thing. I still support the GPL effort, but not at the
> expense of losing portability between commercial and GPL developed apps.
>
> Glen.mobile
> RewriteRule ^(garbage|junk)$ /$1 [NC,L]
>
>
>
>
>
>
> > Where did this come from. This is the first that I have heard of
> > anything about this. This is not a question that you are posting - it
> > is a statement of fact. WHO determined this course?
>
> > I certainly did not get to vote on the issue.
>
> > Eugene
>
> > On Aug 10, 12:51 pm, Diccon <diccon.tes...@gmail.com> wrote:
> >> Its worth noting the pure GPL version of OpenQM is moving to it's new
> >> name.
>
> >> The project and product will now be called Scarlet DME (Data
> >> Management Environment)
>
> >> We've had this ready for some time but Its about time we announced
> >> it.
> >> This should help everyone distinguish Between Ladybridge's Commercial
> >> QM and the OpenSource version.
>
> >> just new domain available)http://gpl.openqm.comwillcontinue to
Martin Phillips
> If Martin would actually tell us the bare minimum information on
> future changes (opcode numbers he uses, or changes to byte code
> formats) then we can match him or at least avoid treading on each
> other toes...
There is a group of opcodes clearly marked as being for GPL developer use in
the opcodes.h include record. As projects are integrated these would be
moved into their final new homes, releasing the opcode for re-use in a new
project.
> ...but so far the response to such information on the QMClient
> system has been negative.
I am unaware of any request. The only aspect of QMClient that we will not
reveal is how it handles encrypted network traffic.
> As we stand we will have to take a look at some Ladybridge code
> I found that seems to show Ladybridge has put traps to prevent
> binary compatibility from Commercial QM to OpenQM.
Odd. I know of no such situation. Can you cite an example? It is contrary to
the commercial licence but we have not done anything specifically to stop
this.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
Tom Potts
Hi Diccon,
> other toes...
> If Martin would actually tell us the bare minimum information on
> future changes (opcode numbers he uses, or changes to byte code
> formats) then we can match him or at least avoid treading on each
There is a group of opcodes clearly marked as being for GPL developer use in
the opcodes.h include record. As projects are integrated these would be
moved into their final new homes, releasing the opcode for re-use in a new
project.
Strange, I can't seem to find anything about that in opcodes.h. In any case, I think what is really meant is that you will share the opcodes used when and if you implement new opcodes into Commercial QM; otherwise we have to break binary compatibility, or reverse engineer the binary format to find out what goes where. Essentially we are all hoping that any changes you make to the binary structure of OpenQM bytecode you will tell us about so that we can at least attempt to keep the GPL version in sync.
> ...but so far the response to such information on the QMClient
> system has been negative.
I am unaware of any request. The only aspect of QMClient that we will not
reveal is how it handles encrypted network traffic.
Unfortunately I don't remember the specifics, but it was a real case similar to the hypothetical one above: you changed the way that the QMClient processes communicate with each other without letting the GPL developers know what the revised protocol was; without source code to understand it, we (and by we I mean Diccon) had to reverse-engineer the protocol to get the GPL version back to compatibility. I understand that you want to protect any USPs you've got, but our position is that breaking compatibility between the Commerical and Community versions of OpenQM is A Bad Thing (tm).
Odd. I know of no such situation. Can you cite an example? It is contrary to
> As we stand we will have to take a look at some Ladybridge code
> I found that seems to show Ladybridge has put traps to prevent
> binary compatibility from Commercial QM to OpenQM.
the commercial licence but we have not done anything specifically to stop
this.
There is a comment and some code that Diccon found in kernel.c:
/* Remap functions that are used in the non-GPL version only to become
illegal opcodes. Programs compiled on the non-GPL version and moved
to this version will now report an illegal opcode if they try to use
these functions. */
We haven't quite figured out exactly what it does, but it seems that it is there specifically to break GPL/non-GPL compatibility. If you could say what this is actually for, that'd be useful.
Thanks,
Tom
Martin Phillips
> Strange, I can't seem to find anything about that in opcodes.h.
It is clearly commented in the C version of opcodes.h as 16 opcodes starting
at xCFF0.
> In any case, I think what is really meant is that you will share
> the opcodes used when and if you implement new opcodes into
> Commercial QM; otherwise we have to break binary compatibility,
> or reverse engineer the binary format to find out what goes where.
Transfer of object code between the commercial and open source versions is
banned in the terms of the commercial licence, therefore, there is no need
for us to publish the list.
> Essentially we are all hoping that any changes you make to the
> binary structure of OpenQM bytecode you will tell us about so that
> we can at least attempt to keep the GPL version in sync.
The whole point of this long standing "discussion" about open source is that
there should not be two disparate versions. If developers had contributed
submissions back to the mainstream for integration, the GPL source would
always have been up to date. Sadly, this doesn't seem to be how the
community wish to work.
> Unfortunately I don't remember the specifics, but it was a real case
> similar to the hypothetical one above: you changed the way that the
> QMClient processes communicate with each other without letting the
> GPL developers know what the revised protocol was
We reserve the right to add new message pairs that are applicable only to
the commercial version. We have to maintain our own cross-rev compatibility
so we tend to add new features in a way that is backward compatible. There
should not have been a compatibility issue.
> without source code to understand it, we (and by we I mean Diccon)
> had to reverse-engineer the protocol to get the GPL version back to
> compatibility.
That is a clear contravention of the commercial licence.
> There is a comment and some code that Diccon found in kernel.c:
/* Remap functions that are used in the non-GPL version only to become
illegal opcodes. Programs compiled on the non-GPL version and moved
to this version will now report an illegal opcode if they try to use
these functions. */
This is not an incomaptibilty to force problems (even though transfer
between the two systems is against the terms of the licence). By way of an
example, the op_trace opcode that get remapped to being illegal is an
internal diagnostic tool that works only on Windows. There is a similar
remapping in the Linux commercial version. In every case, the remapped
opcodes are either irrelevant to the GPL version (e.g related to licensing
or features not in the GPL version) or platform specific such as op_trace.
Glen B
> Hi Tom,
>
> /* Remap functions that are used in the non-GPL version only to become
> illegal opcodes. Programs compiled on the non-GPL version and moved
> to this version will now report an illegal opcode if they try to use
> these functions. */
>
> This is not an incomaptibilty to force problems (even though transfer
> between the two systems is against the terms of the licence). By way of an
> example, the op_trace opcode that get remapped to being illegal is an
> internal diagnostic tool that works only on Windows. There is a similar
> remapping in the Linux commercial version. In every case, the remapped
> opcodes are either irrelevant to the GPL version (e.g related to licensing
> or features not in the GPL version) or platform specific such as op_trace.
>
>
So, you're saying that a GPL user can not design an app on OpenQM and
then move to the commercial product once they approve of the stability
and function?
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
> +44-(0)1604-709200
>
>
GlenB
Martin Phillips
> So, you're saying that a GPL user can not design an app on OpenQM
> and then move to the commercial product once they approve of the
> stability and function?
No, I am not saying that. There is nothing to stop you moving source code
and recompiling it.
Diccon
point.
In terms of QMClient I worked from the GPL source code, had to put in
break out's on occasion in the new API code to figure out exact what
was being done. The only documentation was in the BASIC code, it
served the purpose. Let me be absolutely clear NO licences or terms of
any kind were broken. I'm fairly insulted this was even suggested,
given how open I've been about the whole development.
My issues are about continued compatibility. Something I have no
personal or commercial interest in, but thought it would help the
uptake of QM if the new API libraries worked smoothly with both
systems. I asked for opcodes of any new features in commercial QM, via
private email. So I could avoid their use when I added my own
operations. In the end a couple emails later you stopped replying at
all without giving me details I needed (number of additional bytes on
the login header, new opcode numbers, etc). I never sent new protocols
back to Ladybridge in the end, as they were not completed, and thus
not put into OpenQM GPL. The requirement for them was diverted. We
started looking at JD3 as a complete alternative to QMClient, as a
more compatible, active and supported GPL avenue to integrate into
Scarlet. As a program that runs a daemon in Pick itself it would be
immune to the changes in QM and be compatible with D3, Qm, Scarlet
etc. Presuming this works I've frozen QMClient development. So for now
I don't really care.
As for binary BASIC compatibility, it is clear to me now that
Ladybridge never intended on this being possible. All we can hope to
do it maintain source code compatibility for Scarlet to QM. Hopefully
if documentation on the BASIC code continues to be updated and
published we can do this without any other input. I could make
efforts to try and make the commercial code run on Scarlet, but by the
sounds of it anyone who used the feature would get grief for breaking
terms of use of their commercial compiler, so I will avoid that (YES
Martin I will NOT do that). Despite some serious judgement on my
character (Freeloader, thief, "behind closed doors", "Arrogant and
selfish") I will continue to offer co-operation in information sharing
and inform Ladybridge about changes we make to the protocols, even
fixes and bugs. Given that the source code changes are already open
for view The extra work in collaborating is still something I am still
willing to do. As for submitting code which I currently hold copyright
on now under the GPL into a modified BSD licence where I give that up,
with any inerrant protection. Well lets just say you best come ask me
for anything you want Martin and we can discuss my time at that
juncture. I'm not going to continually commit my rights and my time to
something for which I am obviously not appreciated for and am held
under some strange moral debt I never asked for. I certainly am not
personally seeking to invoke any more GPL releases from Ladybridge. I
would appreciate if you would stop dangling such an offer like some
limp lettuce when no one I have worked with has asked for anything of
the sort for over 12 months.
This will be my last post on this matter of LadyBridge.
--
If i'd spent the time it took to write this email coding, everything
would be finished.