Request for Comments

[Rod Dixon, J.D., LL.M.]

This is quite a proposal you are presenting on this list. I am unsure what
you want us to do with it other than to say it sounds interesting and to
encourage you to launch the project as an open source project.

I suppose people can e-mail you off-list if they are interested in the
business aspects of your proposal. From what I can tell, I am unsure whether
you are quite ready for license discussions since you seem to be at
preliminary stages in this. I will say this: I agree with those who think
that open source projects are best suited for software development that has
past the stage of  "creation." You are going to give a lawyer a nightmare
assignment, if you do not get this initial stage correct.  I suggest that
you get your creation in some tangible form first, and then re-post to the
list for responses on the licensing issues.

Good luck!

Rod

----- Original Message -----
From: "Henningsen" <peter at alifegames.com>
To: <license-discuss at opensource.org>
Sent: Saturday, January 20, 2001 12:07 PM
Subject: Request for Comments


> I think I have found a cool way to make money with open source, but I
don't
> expect to become rich with it. I'd be well pleased if it would generate a
> normal income. I think what is needed is not a new license, but a way to
> organize the use of dual license schemes. So this is somewhat off-topic
for
> this list, and I apologize for that. However, if you are willing to take
the
> time, I am very willing to listen to your inputs. This document is
intended
> to promote a vibrant Linux Game Programming community, and it is a first
> draft that *will* be changed. (If this is too long, just read sections
2.1,
> 3.1 and 5., or even just the last two paragraphs, which refer to earlier
> discussions on this list.)
>
> Linux Game Programming (LGP) Compact
> (c) Peter Henningsen 2001 - You are free to write similar agreements for
> your own project, using the same language if desired.
>
> Preamble:
>
> The LGP Compact (LGP-C) is intended as a way to organize a group of
> developers and artists so they can develop a successful series of games
and
> make money in an open source environment. The LGP-C provides for code
> releases both under the GPL and commercially. Its intention is to organize
a
> group of developers and artists so that the group can effectively
negotiate,
> take counsel, make decisions, propagate itself, organize cooperation, and
> share income fairly. This compact is not a legal document that is
> enforceable in court, but constitutes the guidelines we resolve to follow.
> These guidelines can be amended by consensus any time.
>
> LGP Compact:
>
> The participants in the compact organize themselves into a social organism
> ("group") with the purpose of producing and releasing a series of games
> codenamed "DungeonHack". Group members can have one of the following
> functions, which will be explained in detail:
> 1. Maintainer
> 2. Coder
> 3. Artist/Author
>
>
> 1.1 The maintainer(s) are responsible for the following product-related
tasks:
> a) define a task list, and keep tabs on progress
> b) discuss with newcomers to the project what task they should do
> c) support newcomers on their chosen task until they're up to speed
> d) integrate contributions into a main code branch with regular releases
> e) contribute code, art, and/or documentation to the project
> e) do everything else that needs to be done and for which there is no
> volunteer, such as
>    maintaining a website, doing publicity, etc.
>
> 1.2 The maintainer(s) represent the coders, authors and artists in all
> negotiations, and make decisions on their behalf after taking counsel with
> them. In particular, the maintainer(s) are responsible for
> a) deciding who gets a license and who does not
> b) determining the price of commercial licenses
> c) making agreements with new contributors, particularly artists and
> authors, about the percentage weight their contribution will have in the
> overall project - e.g. they could make an agreement with a graphic artist
> that professionally animated 3D-figures of the protagonists count for 30%
of
> the project (meaning the artist will get 30% of all contributor income).
>
> 1.3 The maintainer(s) are the people who are actually maintaining the
> project, and have done so in the past. Who is a maintainer and who is not
> should be amicably agreed upon by the contributors to the project. In case
> there is no agreement, the following rules apply:
> a) There are 1 or more maintainers. At the start of the project the active
> and only maintainer is peter at alifegames.com.
> b) If there are two maintainers, they are called the active maintainer
(who
> is actually doing most of the tasks under 1.1) and the backup maintainer
> (who used to do them earlier). The backup maintainer(s) give support to
the
> acting maintainer, and help with difficult problems.
> c) If there is a person in the group who consistently does more of the
tasks
> in 1.1 than the active maintainer, the active maintainer steps down and
> hands the post over to that person. If he does not, the group members can
> force him to step down if a majority (counted by percentage contributions
to
> the project) votes for him to do so.
> d) When an active maintainer steps down, he becomes backup maintainer.
> Several people can share the job of backup maintainer.
> e) The maintainers should earnestly try to come to consensus decisions
when
> performing the tasks in 1.2, but if they cannot, their votes are counted
> with the following weights: Every maintainer has a percentage of the votes
> that is equal to his percentage contribution as a coder/artist/author,
> except that if there are several backup maintainers, then their percentage
> is divided by their number.
>
> 2.1 The coders are the people who have written code for the project. They
> assign their copyright in the code to alifegames.com in exchange for their
> share of the income generated by the project. Coders agree that the
> DungeonHack code should be released both under the GPL and under
commercial
> licenses, with new code often only available commercially. It is
understood
> by all that commercial releases will contain code that encrypts program
data
> and/or enforces the use of keys, and that is intentionally obfuscated and
> will only be released as machine code. It is understood that such parts of
> the code will never be released as source code.
> 2.2 Coders who write an independent module (such that DungeonHack is fully
> playable without that module, though possibly with reduced functionality)
> can decide themselves on whether and when this module should be released
> under the GPL. Coders who write an unseparable part of the project agree
> that it is up to the maintainers to decide when to release their code
under
> the GPL. It is understood that all code that is part of the main branch of
> the program will eventually be released under the GPL.
>
> 3.1 Artists and authors are the people who have contributed art or written
> text to the project. They assign their copyright to alifegames.com in
> exchange for their share of the income generated by the project
(Exception:
> Major contributing artists can retain their copyright if desired, and
> instead give alifegames.com an irrevocable right to use the graphics in
> future DungeonHack releases in exchange for their share of the income).
When
> the code of the project is released under the GPL, the maintainers can
> decide how much of the graphics and documentation to release to the open
> domain for other people to use in their own GPL-games. However, it is
> understood among the participants in this project that in general a strict
> copyright will be maintained on graphics and texts that come with the
> project, and that third parties will be prohibited from distributing
these.
> Older assorted graphics that are not used in commercial releases any more
> may be given over to the public domain at the discretion of the
maintainers
> (however, this will not be done over the objections of the artists).
> 3.2 Artists and authors who have made a major contribution can decide
> themselves whether and when to release their contribution to the public
domain.
>
> 4. Income Sharing
>
> 4.1 Income from a commercial DungeonHack game-release (as in 4.3a and
4.3b,
> after paying for costs of production, distribution, etc.) are shared
> according to the basic formula:
> 25% for the designer Peter Henningsen in recognition of the fact that he
has
> worked for 6 years, writing and playtesting 4 different games, to come up
> with the DungeonHack design;
> 25% for the maintainers of the project, to be shared by consensus
according
> to the amount of work they have invested into the project. If consensus
> cannot be reached, their share is passed on to the contributors;
> 50% for the contributors to the project, shared according to the amount
they
> have contributed as further defined later.
>
> 4.2 The coders' and artists' share is determined as follows:
> a) If a coder has contributed X% of the code lines, he will get X% of the
> coders' part of the income. It is the responsibility of each coder to
count
> his lines. Contributions smaller than 1% do not receive a ahare of the
> income to avoid excessive bookkeeping chores. Shares that are smaller than
> US$50.- will not be paid out, but they will accumulate and be paid out at
> the end of the business year when they have gone over that amount.
> b) The percentage of the coders' and the artists' share of the income, and
> the part each artist gets from the artists' share will be determined
through
> negotiations when the artists join and present their work, or failing
that,
> by a decision of the maintainers that they will make after taking counsel
> with artists and coders.
>
> 4.3 The authors share is different for different types of release:
> a) For a code release where the documentaion is released in electronic
form
> only, their share of the overall income is determined by the maintainers,
> but for fully functional documentation it would be no more than 10%.
> b) For a boxed game release where the documentation is included in booklet
> form, their share of the overall income is determined by the maintainers,
> but for fully functional documentation it would be no more than 20%.
> c) For a book release where heretofore commercial game code (which becomes
> GPL'd with the release of the book) is included on a CD, the writers'
share
> is no less than 50%, and determined in negotiations between the editor and
> the maintainers. If an agreement cannot be reached, the book is not
published.
> d) For a book release which includes only previously released GPL'd code,
> the writers' share is 100%, to be shared with any artists whose
copyrighted
> works are used in included code.
>
> 4.4 Book releases like in 4.3c and 4.3d make use of the services of an
> editor and a publisher. The initial editor for the project is Peter
> Henningsen. If an outside commercial publisher is used, the writers'
income
> is shared 30% for the editor, and 70% for the authors. If the book is
> promoted and distributed on the internet, the person who does that takes
the
> role of publisher, and the writers' income is shared 20% for publisher and
> editor each, and 60% for the authors. The authors' share of the income is
> divided up between the authors so that a person who wrote X% of the pages
> will get X% of the income. It is the responsibility of each author to
count
> his pages by adding up partial pages. Contributions smaller than 1 page
> total do not receive a ahare of the income to avoid excessive bookkeeping
> chores. Shares that are smaller than US$50.- will not be paid out, but
they
> will accumulate and be paid out at the end of the business year when they
> have gone over that amount.
>
> 5. DungeonHack vision and strategy
>
> The DungeonHack games operate in a grid-based world, where every cell can
be
> either open or blocked for movement. This world is populated by artificial
> life "monsters" similar to those in alifegames::bSerene, and by player
> characters. Teams of player characters (which can also be operated by the
> computer) fight each other in an environment where all teams are also
> threatened by monsters. (The first version of the game will have only one
> player character.)
>
> The game is highly modular. In particular, there will be an interface for
> renderers, which will make it possible to easily incorporate new
renderers.
> Initially there will be a top-down map-view renderer, but the game should
> eventually be fully 3d-rendered with beautiful animations. It will also be
> possible to write new brain modules for player characters. The intention
of
> the DungeonHack series is to have different brain modules compete and
evolve
> towards true artificial intelligence.
>
> As more complex brain architectures are introduced, the environment is
made
> more complex to present a greater challenge to the evolving brains. This
> implies that with most major new versions the world file format will have
to
> be changed to introduce new functionality and accomodate new brain
> input/output modalities.
>
> DungeonHack users will engineer, evolve and train their brain modules, and
> then run them through a series of contests against standardized brain
> modules to derive a standard score. This process will run under encryption
> to make evil hackers work hard if they want to try and derail the project.
> Users will be able to post their brains with their scores to a central
> website, which will keep a ranking of the best brains, and the most
creative
> users. Users will also be ranked according to trust, and people who break
> the encryption and post bogus scores will be banned from the system, which
> will only be accessible to licensed key holders who run the current
version
> of the program with internal encryption. Users will be able to download
all
> the best brains for study and use in breeding.
>
> All commercial releases will make use of code obfuscation and encryption,
> whereas all releses under the GPL will not. Other differences between the
> commercial releases and the GPL releases can be:
> a) Newer and better renderers in the commercial release. A renderer will
> typically be released under the GPL when it is superseded by a better one
in
> the commercial version.
> b) Proprietary brain architectures: Anybody who develops and codes a new
> brain architecture can decide whether and when to release it under the
GPL.
> There is no guarantee that the best types of brain will ever be released
as
> open source, this is purely up to their author. Brain modules can use code
> obfuscation and data encryption.
> c) More and better graphics in the commercial release - even using the
same
> graphics engine, the graphics data can be of very different quality. GPL
> releases will come with screenshots of the much improved graphics of the
> current commercial releases.
>
> A special consequence of releasing game code under the GPL together with
> copyrighted graphics should be noted: While people can modify the code,
they
> cannot release and distribute the code together with the graphics without
> the agreement of the copyright holders to the graphics. In particular, if
> the GPL'd code contained material that promotes the commercial version of
> the code, no distributor could remove that code without also having to
> supply their own graphics.
>
> While it is the intention of the DungeonHack project to freely license all
> but the latest graphics of the game to non-commercial developers, keeping
> the copyright on the graphics makes it possible to prevent much of the
> unfair commercial exploitation that open source developers otherwise can
be
> exposed to.
>
>
>
>
>
>
>
>
>
>