gnupic: gpal fork
Subject:
Re: gpal fork
From:
Scott Dattalo ####@####.####
Date:
8 Mar 2004 15:34:46 -0000
Message-Id: <Pine.LNX.4.44.0403080621050.4459-100000@ruckus.brouhaha.com>
On 7 Mar 2004, Craig Franklin wrote:
> Although it isn't finished yet, an individual is planning a fork of
> gpal. They will be using it as an OO compiler for flowchart based
> designs for robots. A wrapper will invoke the gputils tools and some
> commercial tools. That's all I know. It sounds like he will be writing
> and selling the commercial tools. It also appears it will be win32
> based.
Hey someone's doing something like to gpsim too! Only they won't be
re-packaging it and selling it as a commercial tool. Fortunately, they've
showed me every single change they've made so far. And also fortunately,
that person is me! (In my case, I'm creating CPU models for proprietary
microcontrollers that will plug into gpsim's module interface. Stage 1 has
been the massive API restructuring to enable this. Stage 2 has been the
module update. Stage 3 will be the proprietary processor. Stage 4 will be
external scripting [Python]. In the long run, gpsim will benefit from this
commercial endeavor.)
Craig, my advice is "so what". And I don't mean this in any kind of
demeaning sense. The fact is that you have exhibited over the years an
extremely high integrity. It's going take more than a little leech to
diminish your stature.
Let's step back and put things in perspective. First, gpal is not
complete. This implies that the fork has quite a bit work left before
it's usable. What are the chances that they'll take the same path as you?
Furthermore, if they were as good as you, then they probably wouldn't have
started with gpal as a base. So what are the chances their fork will be as
good as yours? Probably little. What are the chances that they'll end up
having to grab a future copy of your development? Probably high. What are
the chances that your new implementations will break assumptions about
their design? Probably high. What are the chances that they'll lose money
waiting on your full implementation? I don't know.
I imagine that they'll attempt to closely follow your development and will
submit patches that will make it easier for their development. Since you
and this person (or group of people) are not on good footing, I'd refuse
the patches. Remember - they need you but you don't need them.
Here a couple of options that you can try. 1) ignore them. 2) change the
license from GPL to something that explicitly disallows packaging with
third party commercial products. 3) Design (or re-design) to have strong
dependence on other tools. 4) Close a key portion of gpal and distribute
it just as a binary object.
I'd personally do (1). Option 2 has greater impacts beyond this particular
case. For option 3, you could split the optimization of gpal between gpal
and gplink. Or you could make gpal depend on something like Python. Option
4 is only viable if the portion of gpal that this person needs to modify
his hidden away in a binary.
Regards,
Scott
