Request for Comments

[Henningsen]

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.