nel-all
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nel] Congratulations + concerns


From: Brenden Towey
Subject: Re: [Nel] Congratulations + concerns
Date: Sat, 30 Jun 2001 11:34:30 -0700

Good point.

I haven't looked at the source code at ALL, but the idea behind GPL is that
you only have to GPL your code if you base it on existing GPL code.

So, if NEL doesn't already do this, first you take the GPL code and make a
well-defined API that allows one to separate the "game rules" from the rest
of the package, and release that.  "Hey everyone, look at the spiffy API I
added to the NEL code base.  Please look at it and add it to your GPL code
base if you like it."

Then you take the GPL game rules on the other side of the API, delete them,
and write your totally new rules, using only the API.  Tah da, they are
yours, and you don't have to release your code to anyone.  The game rules
are a separate binary (library, .o file) just like the game data.  Use
dynamically linked libraries if you want more separation.  (But I'm pretty
sure that when compiling proprietary apps (see below) under GNU/Linux, at
least some GPL code gets bound directly in.  Also, the concept of
"contamination" my apply, but hey, we are talking a GAME here.  Do you
really think anyone is going to bother suing you?  Unlikely I think. )

This is the same as developing proprietary apps on GNU/Linux.  GNU/Linux
provides a public, GPL'd API, but the app you write that interfaces to that
API is totally your own.

(I'm pretty sure that when compiling proprietary apps under GNU/Linux, at
least some GPL code gets bound directly in, though this doesn't seem to
bother anyone.  Also, the concept of "contamination" may apply, but hey, we
are talking a GAME here.  Do you really think anyone is going to bother
suing you for GPL license violation?  Unlikely I think, unless you really do
overtly violate the license. )


My 2 cp.

Brenden

-----Original Message-----
From: Yann Morvan <address@hidden>
To: address@hidden <address@hidden>
Date: Saturday, June 30, 2001 11:06 AM
Subject: [Nel] Congratulations + concerns


>Hullo,
>I've been following the development of NEL for
>some time, I haven't been contributing due to lack
>of spare time, but I wanted to congratulate the
>Nel team for their idea and work.
>
>However, I have one major concern with the licence mecanism.
>Indeed, your idea is that what the people will pay for in
>games based upon Nel is content and not code. Saying this, you
>implicitly state that content and code are completely distinct things.
>It is true for the most part (graphics, sounds, AI scripts, background,
>plots etc),
>but I can't convince myself that it applies to the rules of the game,
>for I can't help to think that for efficiency matters they should be
>hardcoded in the different services. (The reason being that because of
>their level of abstraction, using a scripting mechanism would be terribly
>painful and would require a design of the services architecture allowing
>for total flexibility).
>
>I played Ultima Online for 3 years, I read the rantings of lum the mad
>daily, I read the dev boards of currently in development MMORPGs, I'm
>aware of the specificities of the "big three" and all this leads
>me to the conclusion that the rules (i.e. economy system, combat system,
>advancement system etc) are a part of the content at least as important
>as the rest regarding a game's interest (I wouldn't be willing to
>create a MMORPG if I wasn't utterly frustrated by the current trends
>in those games).
>
>Therefore, while I totaly agree that any improvment
>or further development of Nel's features should be shared, I'd
>like you to reassure me about the protection of one's rule system
>in your design philosophy.
>
>Sorry for this long mail and for reviving this probably old and well
>debated issue :)
>
> Yann
>
>_______________________________________________
>Nel mailing list
>address@hidden
>http://www.nevrax.org/mailman/listinfo.cgi/nel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]