>We could also consider names involving 'page' - as the site/page metaphor has
>prevailed over the card/stack metaphor: why fight the collective
>unconsciousness?

Eric,

 I think the idea to use something similar to HyperCard was that we wanted
to create the successor to HC, to carry on the torch. The intention was to
show we haven't forgotten our roots. But other names have been discussed,
too.

>If Apple is really thinking of dumping HC (i doubt it) then maybe we can ask
>them to take it over for them? They already tried spinning HC off to Claris
>(unsuccesfully) and also tried to spin and sell of the Newton before they just
>dropped it. Again, this could be turned into a charitable write off for apple
>if we then license the program to schools.
>
>Personally, I doubt apple will dump HC but I also am not expacting HC-III any
>time soon : so maybe we can talk them into licensing/sharing source code with
>us?

 Until Apple have formally decided to drop HC they'll never release the
sources. Also, I'm not sure whether it would be desirable to try to take a
program that is written mostly in Pascal and 68k assembly (and a little C,
I think) into a world of C++ fanatics. But I'm sure we could re-use some of
the sources when Apple finally decides what they want to do with HC. But at
the current state of affairs this point seems moot.

>I have no problem sharing source code with end users per se, but once we do it
>is no longer trade secret and can be used by anyone commercially or otherwise.

 The original premise was that OpenCard was to be open source. This will
make it possible for other programmers to contribute to OC and to help us
in tracking down bugs etc. like it happened with Linux. I don't think we
could ever work under trade secret. It has to be open.

>Also nu in french means naked, so i do not think nuCard is such a good idea...
>VolksCard would also lead to confusion? I mean, really, its neither a car,
>nor a political nightmare...

 I kinda like it. The original Volkswagen (known as the Beetle in the US)
was supposed to be the affordable car for everyone. If that isn't a
striking similarity to HyperCard, I don't know what is.

>It would be nice to integrate WWW with openKard as much as possible... (I am
>writing a _very primitive HTML editor using HT)

 Alain also has an interest in this, so I can pretty much assure you this
will be done.

> Someone's trying to draw up a HC interpreter for Java - only good on
>PPCs though... There are lots of HTML externals.

 If you mean running HyperTalk scripts using a Java application, forget it.
It's going to be *very* slow. If it's some kind of Java Plug-In, this is
something that could come out of OpenCard anyway since the interpreter can
stand alone So, if someone's interested, they can create this, but I don't
see what the relevance is to us in this current state of affairs.

>If it were possible to cross platforming the HC externals that would be
>nice... Does MetaCard have any insights on this?

 Scott Raney (the "MetaCard guy") has told me they'd be discussing this
format on the xTalk list and that means we'll have a say in how it'll be
developed. There will be collaboration on this, when the time is right.

>Names?
>freePage? freeCard?
>ezPage? ezCard?
>multiPage? multiCard?
>basicCard? basicPage?

 "freePage" sounds like free web space.
 "ez..." sounds like SyQuest's disk drive and might get us in trouble with
whoever has the rights now (Iomega?).
 "multi..." sounds like a multi-vitamin drink to me. What's the connection
to OC/HC?
 "basic..." sounds like we were using the "Basic" programming language,
which has an even worse fame than HyperCard has.

>Regarding TM - maybe we can talk metaCard into paying the TM fee? This can be
>done via a contract with not partnership.

 I doubt it. MetaCard very likely has no interest in funding us. They would
like to get their UI laid out, that's what the collaboration is for. Also,
I wouldn't want to be dependent on them. Don't get me wrong -- I think
Scott has done a great job on MC, and it's very nice they gave us this
list, but it just doesn't go with OpenCard's concept, and I don't think
Scott had something like this in mind.

>Also, do people oppose/support/indifferent a partnership with metaCard? This
>could be useful. In any event metaCard should know that our efforts could
>constitute a charity, (i.e. free distribution of openKard to schools) and thus
>would permit them a charitable tax write off for incurred expenses.
>(if metaCard or Apple want details on the tax aspects, please ask for I
>have an
>LLM in tax law...). That said, I would say our relationship with metaCard
>should not be a partnership unless we expressly enter into such relationship
>in writing - which MC may not want to do anyway, so this could all be moot.

 See above.

>others. Triple damages for misappropriation, and the infringer pays
>the attorneys fees and costs if the infringer acted in bad faith.

 and what if the infringer acted unknowingly?

>But, really, I think that the license and trade mark issues are actually
>secondary to the partnership question. I have the licenses, and believe I know
>what we want. While I prefere registering if we have to use common law
>protection (which is _much weaker) so be it.  But I would like to focus first
>on the partnership question: I would like to suggest two levels of membership:
>partner, and associate. Associates would be able to come and go as they
>please, and have no liability or responsability. In exchange for a reasonable
>amount of work they would be able to keep a copy of the metaCard engine, plus
>mention in the credits.

 I think we should leave out the MC engine of this. MetaCard has nothing to
do with OpenCard. It's just a prototyping environment we may use to create
the editor and its User Interface. Forget about it for this discussion.

 Also, the problem is determining what constitutes a "reasonable amount of
work" ???

>Partners would have decision making authority: they
>would have to agree unanimously before admitting a new partner. All persons
>(associates and partners) would have to agree to change the partnership
>agreement. Partners would determine whether the associate has done enough work
>to merit the engine. The partnership would be a charitable organization.
>Anyone may ask to enter into the association. Admission would be based on a
>majority vote of partners and associates, based upon the contribution offered
>by the associate.

 Sounds like it'd work. I think this partnership would only be necessary to
create a core group of "dictators", who would hopefully heed the decisions
and requests of associates. I don't think we can do more, as this is a
versy informal group. Who really wants to be can become a partner, but
anyone should be allowed to contribute.

>Since unanimity of all persons (partners and associates) is
>required to change the partnership agreement, do not expect the agreeement to
>be changeable - a single no would act as a veto. Advantage: guarantees the
>organization stays charitable. Which is also its disadvantage if you later
>decide you want to make money after all (at that point forking or splitting
>comes up - the partnership agreement would neither encourage nor prohibit
>splitting or forking).

 That splitting of forking is possible would be important. But would only
partners be able to split or fork, or everybody? If only the partners can,
this would mean that the partners could hinder development and distribution
of OC. I think a more PD-like license would be better. What about making it
FreeWare under the condition that people give credit to OpenCard and give
users information where they can get OC. This could be about 2 lines in an
about screen, which we could ask even from commercial users.

>Again, MC probably should _not be a partner. We can, in theory, get anything
>we want from them via contracts.

 Forget MC in this!!!

>So, what do you think? The licenses will have to be approved by the
>partnership to be formed - and they really are pretty straight forward (though
>unfortunately one line will not suffice - a page would).Any contract between
>the partnership and MC will be better negotiated (plus we will look more
>serious). By using unanimity of decision and two levels you obtain the
>protection (for associates) and stability and coherence (of partners) required
>for this project.

 Sounds sensible.

>I am rather enthusiastic and want to draft the partnership agreement but
>cannot do so until we determine the exact (and really it has to be a precise
>decision) structure of the partnership. I would like it all to be based on
>consensus - but different people will have different levels of commitment, and
>in the end some central decision making has to be done.

 I think it would be best if we made this "FreeWare with a condition" as I
already called it, under some working name (this could be Project:OpenKard
or whatever), and have an organizing committee of six or so partners who
coordinate the official distribution (under the name we decide on) and
distribute that including compiled binaries for end-users. Do the others
agree?

 And now, back to XBlockFile. The move to two separate lists, one for
wasted and one for used blocks has been made (technically). I just have to
get it to compile and then I can release a snapshot. And then I'll
re-activate compacting blockfiles. Sub-blocks have been prepared, but not
yet fully implemented (they can be read, but not written currently).

Cheers,
-- M. Uli Kusterer

------------------------------------------------------------
             http://www.weblayout.com/witness
       'The Witnesses of TeachText are everywhere...'

--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html

Reply via email to