Hi All,   (ramble mode on --- sorry)

> Adrian: And at this point the problem arises.  Who is the original author?

The original author is THE (our) FreeCard ORGANIZATION (name and
organizational strucuture yet to be formally determined). The FreeCard
Entity, its community development gang -- US. So, it is safe to say we are
the ORIGINAL authors of FreeCard. We can hold the copyright. We can license
how we wish (including multiple licenses). And, we can even give away our
original author status to others ---- (example: Free Software Foundation,
MetaCard, etc., etc.).

We are the baazar. And as a baazar we need to stay in the driver's seat as
the original author. That means getting everyone's trust and cooperation. As
the greater world has confidence in the gang that is running this show, they
will make contributions and make those contributions ours.

So, the problem arises when we FUMBLE that trust, that leadership, that
cooperation of acceptance of all comers at all junctures.

Plus, a "SIGNIFICANT CONTRIBUTION" is necessary for someone else to put
copyright ownership upon it. That becomes a hair-splitting tasks. Many have
said in the past elsewhere that a "patch" is NOT a significant contribution.
So, the patch is not able to be of a different owner other than the original
work. So, a patch could be re-assimilated into our umbrella -- and we can
wrestle with being the original authorship.

But, come the day when someone does something wild, significant, much above
and beyond a patch, then IF that someone wants to ONLY LICENSE as GPL, ....
there is a sticking point. That someone can keep authorship.

> We've discussed this at length and it will quickly become impossible to get
> "the author"'s permission for anything.  Don't count on getting it.

Pragmatic pessimist. =:[
I'm more of a pro baazar evolusionist. =;]

>I also
> don't think we should dual release as that splits the workforce.
Ahhh, but the dual release would serve to greatly recruit more to the
workforce as well. The dual release enables serious contributions from Scott
(MetaCard) and perhaps, in turn, all the MetaCard customer base.

Here is where the evolutionist come forth in me. IMHO, timing is a vital
factor. In the early days, at the 1.0 release, there will be many who are
going to NOT quickly embrace the GPL because it is DIFFERENT. Face it, any
GPL develpment tool is something that the bulk of the folks (mostly Mac and
WIN folks) are used to seeing. They won't rush to our ranks. (Rest of us
ain't Linux today.)

However, even sooner than the 1.0 days, if we could get a model in place
where there was going to be a dual release, and the benefits were to include
a Free GPL as well as an "upgrade" that was smoothly transitioned into
MetaCard too, and super-friendly for all commercial developers too, no
quesitons, no doubt about it, --- then we'd score big-time with those
commercial folks INSTANTLY.

WHY: They'd help. They'd embrace the mission as it is helping themselves.
Our baazar is more inclusive sooner. Critical mass. Crossing the chasam,
blah, blah, blah.

Execution of the model and retention of all into the flowing community --
where contributions are given back to us all --- avoiding the forking ---
well, that is our challenge. I'd rather ride the wave of early popularity
and try to tame against later forks vs. never getting wide-spread acceptance
and being a cult endeavor.

Part of my thinking is HYPE. To others, its sensible marketing. We gotta get
an organizaition. We gotta get a license. We gotta get more helpers. Since
we gotta do all this anyways -- why not build a vision that is going to
allow for the 1.0 release to go to MetaCard and the MetaCard community in an
open-source way, but without the TAINTING of the GPL. They get what they
want. Scott's (MC) license can cover our contribution in that direction.
PLUS, we can also release the GPLed FreeCard 1.0. Then, we try to hold it
together as long as we can. Everyone WINS as long as this works.

Should it fall apart, (FORK), we'll still be miles farther along than when
we started, and our start point isn't too too far from where we are today
(in terms of bragging).

> Also,
> MetaCard should have no problem complying with the GPL as they would simply
> package our Home Stack with their distribution in the "Alternate Home
> Stacks" folder like HyperCard provided.  They would still provide their
> normal Home stack.  Also, the Home stack is never mixed with proprietary
> code, it is just run by the engine.  Perhaps making it into a MetaCard
> standalone will have to be ruled out, but that's not a problem.

The example, like HyperCard, works except our Home Stack is GPLed. None of
the other Alternative Home Stacks for HyperCard were GPLed. So, we need a
valid legal opinion if its possible.

Q: What is legal and what is ideal? I'm not able to judge (not a lawyer),
but I think this might be okay as the user does the links. ????

If "GPLed-Alternative Home Stacks" is legal in a MC distribution, does it
cause problems or become too much of an extra burden on either
Scott/MetaCard and the MC customers? If putting a GPLed HOME STACK into
MetaCard's suite (alternative or otherwise) is a big burden, it won't happen
and shouldn't be advocated. What is ideal?


>>>> And it'd be pretty hard for Scott not to include source code for the
>>>> home stack we give him, so he'd be complying with the GPL anyway.
>>>
>>> Adrian: At this stage, I don't think it is important to consider how the
>>> choice of licence affects our arrangements with MetaCard.  We choose a
>>> licence that provides the freedom and protection that we want - then if
>>> MetaCard want to make an agreement with us under those terms, we discuss
>>> it then.  Changing our aims for the licence because it might increase
>>> development time isn't wise.  It's better to take longer to achieve
>>> something great, instead of quicker to create something poor.
>>
>> Hummm. Since we had a disagreement on what was POTENTIAL above, its hard to
>> do anything but ignore what follows. However, I do think it is important to
>> think and talk it through, slaving over the details, so as to get the
>> desired synergy with MC AND the "something great" too.
>
> Adrian: I agree.  This should be discussed fully, but I stand by the fact
> that MetaCard shouldn't be a topic of discussion.

Why NOT? I guess you say we shouldn't slave over decisions that may or may
not impact MC because of a "wag the dog" perspectives. My words. Sorry to
pin them to your opinions if my hunch isn't on target to your feelings.


Ta.

Mark Rauterkus
[EMAIL PROTECTED]

Reply via email to