gnupic: Thread: gpal fork


[<<] [<] Page 1 of 2 [>] [>>]
Subject: gpal fork
From: Craig Franklin ####@####.####
Date: 8 Mar 2004 04:59:14 -0000
Message-Id: <1078719978.2048.4.camel@r2d2>

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.

I have only seen a few of the changes.  Some are insignificant.  Minor
changes not driven by bugs or features, but personal preference.  Other
changes are major.  They align gpal with his goals and his target
users.  I will forward more details to this list when I have them.  I
will also encourage this individual to provide contact information, so I
am not a middle man.

I will try to monitor his developments and merge what I can back into
gpal.  I bet the really good stuff will be in the commercial binaries. 
We won't have access to their sources.  So we will get very little
benefit from this project.  As I understand it, GPL will be satisfied.

Most of you can probably guess I am not fond of forks.  So I am not
completely happy with this situation.  Not to mention the fact that the
work being forked is not even complete.

This situation is causing me to reevaluate my approach to gputils
support.  I have been happy to contribute many free hours to gputils.  I
will continue to do so.  I fully support people using gputils to
generate closed source PIC applications.  But this case, my copyrighted
gpal code will be used in a commercial project.    

I believe in capitalism.  I also believe in his right to make money off
of my free work.  Because of my beliefs, if you make money off of the
distribution of gputils and want support from me, you will have to pay
for it.  I don't need the money.  This is about the principle.

This won't effect 99.9% of the users.  Most people use the tools as is
and don't try to resale them.   I have no idea how to enforce this or
what my rates will be.  I will probably operate on the honor system and
setup a PayPal account.  Any "donations" will be used to benefit
gputils.  Contributing code back to gputils will also satisfy my new
policy. 

Subject: Re: gpal fork
From: j_post ####@####.####
Date: 8 Mar 2004 07:20:47 -0000
Message-Id: <200403080648.i286mH1l014479@mta7.pltn13.pbi.net>

On Sunday 07 March 2004 08:26 pm, Craig Franklin wrote:
> We won't have access to their sources.
> GPL will be satisfied.
>
Those two statements contradict. Unless there's more to the story than you've 
presented, the person in question will be violating your copyright. Time to 
see a lawyer ;-)

JP
Subject: Re: gpal fork
From: Michiel Boerman ####@####.####
Date: 8 Mar 2004 10:55:58 -0000
Message-Id: <65FCA6B4-70EA-11D8-AFE1-000502D16926@id5r.nl>

I expect the other guy is smart enough not integrate his software with 
Craig's but call gpal as a seperate process. Not much you can do 
against that under GPL. And my guess is that Craig is not  pissed off 
at the legal issue but at someone making a profit out of his efforts 
while keeping theirs for themselves.
...Like cycling into a strong wind for hours and then finding somone 
has been riding in your wake all the time. They havent hurt you in any 
way but still you feel like stopping at a quiet spot and breaking all 
their bones (if they have any)

Michiel


On Mar 8, 2004, at 7:48 AM, j_post wrote:

> On Sunday 07 March 2004 08:26 pm, Craig Franklin wrote:
>> We won't have access to their sources.
>> GPL will be satisfied.
>>
> Those two statements contradict. Unless there's more to the story than 
> you've
> presented, the person in question will be violating your copyright. 
> Time to
> see a lawyer ;-)
>
> JP
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

Subject: Re: gpal fork
From: "Kevin L. Pauba" ####@####.####
Date: 8 Mar 2004 13:28:49 -0000
Message-Id: <404C6D58.7020102@cox.net>

IANAL, but I think the interpretation of the GPL by the "other guy" is 
against the licensing restrictions of the GPL.

Craig, you should contact the Electronic Frontier Foundation 
(www.eff.org) for some guidance.  The EFF agressively pursues GPL 
violators and might decide to send the "other guy" a letter from their 
lawyers.


Michiel Boerman wrote:
> I expect the other guy is smart enough not integrate his software with 
> Craig's but call gpal as a seperate process. Not much you can do against 
> that under GPL. And my guess is that Craig is not  pissed off at the 
> legal issue but at someone making a profit out of his efforts while 
> keeping theirs for themselves.
> ...Like cycling into a strong wind for hours and then finding somone has 
> been riding in your wake all the time. They havent hurt you in any way 
> but still you feel like stopping at a quiet spot and breaking all their 
> bones (if they have any)
> 
> Michiel
> 
> 
> On Mar 8, 2004, at 7:48 AM, j_post wrote:
> 
>> On Sunday 07 March 2004 08:26 pm, Craig Franklin wrote:
>>
>>> We won't have access to their sources.
>>> GPL will be satisfied.
>>>
>> Those two statements contradict. Unless there's more to the story than 
>> you've
>> presented, the person in question will be violating your copyright. 
>> Time to
>> see a lawyer ;-)
>>
>> JP
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

Subject: Re: gpal fork
From: Alex Holden ####@####.####
Date: 8 Mar 2004 14:46:56 -0000
Message-Id: <404C7FA5.3080102@linuxhacker.org>

Kevin L. Pauba wrote:
> IANAL, but I think the interpretation of the GPL by the "other guy" is 
> against the licensing restrictions of the GPL.

The way Craig described it, they're going to bundle a compiler derived 
from gpal along with the gputils and some commercial programs they wrote 
themselves. If so, then as long as they make all the source code of the 
gpal derivative and the gputils available to anyone they distribute 
binaries to, AFAIK that satisfies the letter of the GPL.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
Subject: Re: gpal fork
From: Craig Franklin ####@####.####
Date: 8 Mar 2004 15:16:12 -0000
Message-Id: <1078756994.1450.10.camel@r2d2>

On Mon, 2004-03-08 at 04:21, Michiel Boerman wrote:
> I expect the other guy is smart enough not integrate his software with 
> Craig's but call gpal as a seperate process. Not much you can do 
> against that under GPL. And my guess is that Craig is not  pissed off 
> at the legal issue but at someone making a profit out of his efforts 
> while keeping theirs for themselves.
> ...Like cycling into a strong wind for hours and then finding somone 
> has been riding in your wake all the time. They havent hurt you in any 
> way but still you feel like stopping at a quiet spot and breaking all 
> their bones (if they have any)
> 

That is pretty much how I feel.  Though I won't be breaking any bones.

For the rest of you:

I thought I had explained this, but from the number of emails I received
I must have not been clear.  The individual is not linking my code and
his code, neither statically nor dynamically.  He is maintaining
separate binaries to satisfy the licensing.  He has one wrapper that
invokes the binaries, but that is GPL (though it probably doesn't
matter).  His binaries process intermediate output files.

As required, he will provide his changes to gputils, but as I stated in
the original message the interesting stuff is in his binaries and we
won't have that source code.

This has precedent.  Some of the Linux IDEs do this with gcc.  Although
maybe not in the spirit of the license, it does appear to follow the
letter of the license.  That is all that matters.

My ISP's mail server is getting blacklisted because of SPAM.  Very few
of my messages are getting through.  I may not be able to respond to any
more messages for a few days.

> Michiel
> 
> 
> On Mar 8, 2004, at 7:48 AM, j_post wrote:
> 
> > On Sunday 07 March 2004 08:26 pm, Craig Franklin wrote:
> >> We won't have access to their sources.
> >> GPL will be satisfied.
> >>
> > Those two statements contradict. Unless there's more to the story than 
> > you've
> > presented, the person in question will be violating your copyright. 
> > Time to
> > see a lawyer ;-)
> >
> > JP
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

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

Subject: Re: gpal fork
From: pic00 ####@####.####
Date: 8 Mar 2004 17:23:13 -0000
Message-Id: <404CA5D8.2040706@users.sourceforge.net>

Is someone interrested in the fork ?
It adds some OO capability, and more types compared to gpal.
In difference, the language is stronger, variables and procedures
must be declared prior it's usage, subprocedures and -functions are
allowed and for the main program's and modules little changes or
addition are planned.



Subject: Re: gpal fork
From: Byron A Jeff ####@####.####
Date: 9 Mar 2004 12:59:49 -0000
Message-Id: <20040309122713.GA3525@cleon.cc.gatech.edu>

On Mon, Mar 08, 2004 at 05:56:56PM +0100, pic00 wrote:
> Is someone interrested in the fork ?

No.

> It adds some OO capability, and more types compared to gpal.

Doesn't matter.

> In difference, the language is stronger, variables and procedures
> must be declared prior it's usage, subprocedures and -functions are
> allowed and for the main program's and modules little changes or
> addition are planned.

Here's why. The author is planning to subvert the spirit in which gpal is
produced to make a closed source private fork. I'd by very interested if
these enhancements were offered in the same vein Craig created gpal to
begin with: a Open Source, open development system. But despite Scott's
suggestion to "take it down a thousand dude..." I feel like Craig does.

All of the advantages in the world will not overcome the fact that because of
the closed source nature of the additions percludes anyone else from regression
testing, optimizations, bugfixes, and the like.

What closed source authors have not yet figured out is that there really isn't
a constituency that exists anymore that benefits from the closed source model.
There used to be a time where it was a viable profit model. It just isn't
anymore. Here's what's going to happen: Developers won't use it because it
won't meet their needs. Someone will need a Mac or FreeBSD or other kind of
port. Others will need better performance or a specialized interface. But
in the closed source model only one person (or a small group) can fulfill
all of these requests. So it'll move slowly.

This will be compounded by the cost model. While that works fine for end users
who do not have the time or inclination to compile something much less do
actual development, gnupic folks are used to getting their hands dirty.

The final element is that gpal, and Craig as a driving force is still out 
there. Craig understands from previous development that if you keep it simple
and make it work, then folks will use it. He understands that the fastest way
to kill a project is to give it featuritis. As a language developer myself
adding all that other stuff when the target is a limited memory microcontroller
is a recipie for disaster. So what will happen is that Craig's stuff will
work, work well, have fast bug fixes, and be multiplatform in short order. 
So most of us will use it.

Open Source is a volume model with distributed development. So more people
will be working on improving gpal, and more people will be using it.

So no I'm not interested in a closed source fork.

BAJ
Subject: Fwd: gpal fork
From: Michiel Boerman ####@####.####
Date: 9 Mar 2004 15:50:19 -0000
Message-Id: <AA695EAE-71DC-11D8-B0A2-000502D16926@id5r.nl>

Hmm, I find this thing that when you reply to a message from the gnupic 
list it only gets sent to the original poster quite annoying. Can't 
that be changed?

anyway. I'll repost my previous messages to the list.

Begin forwarded message:
>

> OF COURSE we are interested in the fork. OO and extra types sound 
> interesting enough. I'ts just that I personally would like to see  a 
> good open source language standard  optimized for pics being 
> developed. Gpal is a very promising candidate but not yet fully 
> evolved. Forking in this stage is too close to sabotage in my book
>
> Michiel
>
> On Mar 8, 2004, at 5:56 PM, pic00 wrote:
>
>> Is someone interrested in the fork ?
>> It adds some OO capability, and more types compared to gpal.
>> In difference, the language is stronger, variables and procedures
>> must be declared prior it's usage, subprocedures and -functions are
>> allowed and for the main program's and modules little changes or
>> addition are planned.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ####@####.####
>> For additional commands, e-mail: ####@####.####
>>
>

[<<] [<] Page 1 of 2 [>] [>>]


Powered by ezmlm-browse 0.20.