gnupic: gpal fork
Subject:
Re: gpal fork
From:
James Cameron ####@####.####
Date:
10 Mar 2004 03:24:05 -0000
Message-Id: <20040310025123.GA11140@us.netrek.org>
On Tue, Mar 09, 2004 at 10:01:17PM +0100, pic00 wrote:
> The decision was choosen to not fork a open source gpal branch.
I cannot see why not. Your reasons for the decision are not clear to
me. Forks of open source are quite acceptable microevolutionary
outcomes. It seems to me that you had good reasons to fork.
> The source tree is removed from the disk's.
> If someone want a copy of it, it's can be requested to recive a backup
> copy until the end of this month.
I don't recall if you're talking about GPL source or not. If you are,
then the GPL doesn't limit how long it has to be available for. If this
is not GPL source, then I'm not concerned. Nobody would want source that
they cannot use; there'd be the risk of infection.
> The backup copy will be be delivered
> after the QSO have screened the sources.
I've probably missed something. I've no idea who QSO is. Sorry about that.
> It's has to be noted, that the orginal author have pronunciate it's
> dissense to most of the source changes or coding decisions.
Nothing wrong with that. If you didn't listen (adapt) to why the
original author pronounced dissent, then it's no wonder you have ended
up with a fork. But that doesn't at all relate to the licensing issue.
It would be disingenous to suggest it does.
> Albeit the compiler is full functional to the specifications given
> by the orginal author. In addition, it's have macro capability, variable
> and static bitfields with slices greather then a bit, float types and
> integer up to 32 bytes with full math support. Arrays to structures of
> bits different sizes is supported. The code generator supports pic
> micros from 12xxx
> to the new 18xxx series including the popular 16xxx types.
But you're just quibbling over features. I'm sure if they were needed
they would eventually be done in the open source author's base sources,
though perhaps not the way you envisaged. To me the development process
is more important than mere features. Arguing from the features to the
license or fork decision is improper.
Craig: I'm curious, I've been developing open source in many projects
over the past ten years, and I understand the accept/reject algorithm
that the original author has to go through ... would you like to show
me an example of the changes these guys were suggesting? Privately. ;-)
All: I observed at the Linux.Conf.Au conference in January that the
microcontroller community in general contains far more people who do
not understand open source, and that I felt conflicts would occur more
frequently on gnupic than on other mailing lists. The frequency has
been low until now; kinda well done?
When a project of mine forks into two or three variants, *then* I am
pleased that I have created something with sufficient community interest
that the community is able to divide *itself* into focus groups.
p.s. keep the reply to sender, reply to list drives me up the wall. ;-)
If reply to sender drives you up the wall, use Reply-All, or whatever
your mail client calls it. If you know when you are posting where you
think the conversation should go, add a Reply-To header. If your mail
software can do neither of these, upgrade it.
--
James Cameron ####@####.#### http://quozl.netrek.org/
