massiv-devel Mailing List for Massively multiplayer game middleware

Massiv 1.1c has been released.

This release contains updates to the code base to make sure the project 
compiles cleanly with new compilers and new versions of external libraries. 
Massiv now builds with MSVC 7.1, 8 and 9 as well as GCC 3.4 through 4.3. 
CryptoPP 5.2.1 and 5.5.2 are now supported.

Massiv is a distributed game middleware whose purpose is to simplify 
development of distributed persistent massively multiplayer online games.

http://massiv.objectweb.org

>Massiv core features seems promising. What's its status now? Is it
>still under development by others than David Li?

Nobody is working on the project as far as I know. I can not speak for the
David Li's team but haven't seen anything from him yet.
-- Markoid

Hi, Marek:

I see it. Thank you for your comments.

Massiv core features seems promising. What's its status now? Is it
still under development by others than David Li?

Regards
Derek

On 8/22/05, Marek Vondrak <ma...@us...> wrote:

> -------------------------------------------------------------------------=
---
> ----
>=20
> Hello.
>=20
> The primary reason is that it was our school assignment to write such a
> system. The other reasons are that we do not find CORBA suitable for the
> development of massively multiplayer games. If you know CORBA I believe y=
ou
> will agree with the following arguments. Basically, what a MMO developer
> wants, is not a RPC only system like CORBA or DCOM, but requires at least
> some support for object state serialization and replication, so that the
> simulation could be presented to clients. Support for consistent simulati=
on
> archivation is required on the server side. Not any of these requirements
> can be fulfilled with basic CORBA, because ORB cores do know nothing abou=
t
> CORBA object structures but their interfaces (except for so called CORBA
> value types, in other words ORBs can not serialize objects, can not acces=
s
> their attributes, etc. but can only call object methods through published
> interfaces). Also since MMO game components are usually written in a sing=
le
> language (mostly C++), it is highly encouraged to use that middleware tha=
t
> integrates with that particular language as much as possible so that
> programmers are not forced to write akward (unnatural) code. CORBA, on th=
e
> other side, is a multilanguage middleware and is "mapped" to multiple
> languages (OMG standard defines how CORBA objects described by IDL have t=
o
> be coded in that particular language). I reckon you would agree with me t=
hat
> CORBA mapping to C++ is _horrible_ and unusable.
> But enough. If you are still not convinced, try comparing the list of
> features supported by CORBA and Massiv side by side and try to answer to =
the
> following questions "Do I really need to use this CORBA feature in my MMO
> game?", "Is it useful to have Massiv core do this thing for me
> automatically?", "Can this Massiv feature be ever supported by ORB core o=
r
> do I have to implement it myself on the application level?". Maybe you
> should look at the sources of the Demo (the "managed" part, say
> src/demo/lib/server) to see how a MMO game can be written in Massiv and w=
hat
> (little) differences there would be if the game was written as a single
> stand-alone (not distributed) application.
> However to be faithful I have to say that most people failed building the
> demo application if anything or were discouraged from using Massiv due to
> its complexity. As it is with all middlewares I have seen, one has to get
> acquainted with the guts of the middleware in order to write even the
> tiniest "hello world" application on top of it. Usually, the initializati=
on
> part is the most complex one and requires the knowledge of the whole syst=
em.
> However I still believe that Massiv might be useful for those people how =
are
> fluent in modern C++, are qualified enough to write a simple network-base=
d
> game without the use of a network middleware and can understand how the
> principles used in their network game are abstracted in Massiv.
>=20
> -- Markoid
>=20
>=20
>=20
>

Hi,

How about implementing the massiv managed object system with CORBA in
the first place? I mean why the massiv developers chose to design
their own? Thanks

Derek




----------------------------------------------------------------------------
----

Hello.

The primary reason is that it was our school assignment to write such a
system. The other reasons are that we do not find CORBA suitable for the
development of massively multiplayer games. If you know CORBA I believe you
will agree with the following arguments. Basically, what a MMO developer
wants, is not a RPC only system like CORBA or DCOM, but requires at least
some support for object state serialization and replication, so that the
simulation could be presented to clients. Support for consistent simulation
archivation is required on the server side. Not any of these requirements
can be fulfilled with basic CORBA, because ORB cores do know nothing about
CORBA object structures but their interfaces (except for so called CORBA
value types, in other words ORBs can not serialize objects, can not access
their attributes, etc. but can only call object methods through published
interfaces). Also since MMO game components are usually written in a single
language (mostly C++), it is highly encouraged to use that middleware that
integrates with that particular language as much as possible so that
programmers are not forced to write akward (unnatural) code. CORBA, on the
other side, is a multilanguage middleware and is "mapped" to multiple
languages (OMG standard defines how CORBA objects described by IDL have to
be coded in that particular language). I reckon you would agree with me that
CORBA mapping to C++ is _horrible_ and unusable.
But enough. If you are still not convinced, try comparing the list of
features supported by CORBA and Massiv side by side and try to answer to the
following questions "Do I really need to use this CORBA feature in my MMO
game?", "Is it useful to have Massiv core do this thing for me
automatically?", "Can this Massiv feature be ever supported by ORB core or
do I have to implement it myself on the application level?". Maybe you
should look at the sources of the Demo (the "managed" part, say
src/demo/lib/server) to see how a MMO game can be written in Massiv and what
(little) differences there would be if the game was written as a single
stand-alone (not distributed) application.
However to be faithful I have to say that most people failed building the
demo application if anything or were discouraged from using Massiv due to
its complexity. As it is with all middlewares I have seen, one has to get
acquainted with the guts of the middleware in order to write even the
tiniest "hello world" application on top of it. Usually, the initialization
part is the most complex one and requires the knowledge of the whole system.
However I still believe that Massiv might be useful for those people how are
fluent in modern C++, are qualified enough to write a simple network-based
game without the use of a network middleware and can understand how the
principles used in their network game are abstracted in Massiv.

-- Markoid

Hi,

How about implementing the massiv managed object system with CORBA in
the first place? I mean why the massiv developers chose to design
their own? Thanks

Derek

----- Original Message -----
From: "John Barrett" <ke...@co...>
To: "Users Massiv" <mas...@ob...>
Sent: Saturday, April 02, 2005 11:46 PM
Subject: [massiv-users] 1st Client/Server issues


> OK... I'm confused :) (as can be expected having oinly worked with Massiv
> for a week so far)
>
> I've got Massiv and the Demo building fine off the command line under
> MSVC7.1 with the
> MSVC STL libs (havent actually tried to run the compiled demo... )
>
> I've copied most of the Demo::Lib stuff and rearranged namespaces more to
my
> tastes, and
> created a build environment in VS.Net 2003 that appears to correctly
> classlist/factgen/compile/link
> my bare minimum server code.... however... when I run "SPOServer -s 1 -i"
> this is the output I get:
>
> ======================================================
> Initializing Massiv core...
> !archive_database warning: No valid archives found.
>  system info: System was successfully initialized. The following
subsystems
> were started:
> base_services
> config
> threading
> file_systems
> networking
> simulation_helper_subsystems
> data_management
> object_management
> system_context
> Creating startup archive...
> Creating startup archive provider (id 1)...
>  object_localization info: Registering local object provider 1.
> Creating naming service object...
> !generic error: Assertion failed: class_pointer_type_info == object.type
> (file 'object\metaobject.cpp', line 134, function void __thi
> scall Massiv::Core::MetaObject::initialize_offsets(const class
> Massiv::Core::VariantPointer &) const)
> Stack backtrace:
> 1  : Massiv::Core::StackTracerMSVC::dump_stack + 0xbf SPOServer + 0x47d81f
> 2  : Massiv::Core::StackTracerMSVC::dump_stack + 0x15 SPOServer + 0x47d5b5
> 3  : Massiv::Core::`anonymous namespace'::debug_die + 0x16b SPOServer +
> 0x32ef3b
> 4  : Massiv::Core::debug_assert + 0x1a        SPOServer + 0x32f04a
> 5  : Massiv::Core::MetaObject::initialize_offsets + 0x63 SPOServer +
> 0x497013
> 6  : Massiv::Core::MetaObject::initialize_property_hierarchy + 0x95
> SPOServer + 0x497c95
> 7  : Massiv::Core::ObjectProperty::initialize_object + 0x1a3 SPOServer +
> 0x342923
> 8  : Massiv::Core::ObjectFactory::initialize_object + 0x2a SPOServer +
> 0x54c34a
> 9  :
>
Massiv::Generated::ObjectFactoryImpl<SPOLibrary::NamingService>::create_obje
ct
> + 0xa0 SPOServer + 0x715200
> 10 :
>
Massiv::Core::CreateObject<SPOLibrary::NamingService>::create_uninitialized
> + 0x48 SPOServer + 0x3252b8
> 11 :
>
Massiv::Core::CreateObject<SPOLibrary::NamingService>::CreateObject<SPOLibra
ry::NamingService>
> + 0x4f SPOServer + 0x32449f
> 12 : SPOServer::`anonymous namespace'::create_initial_objects + 0x9a
> SPOServer + 0x3228fa
> 13 : SPOServer::`anonymous namespace'::create_startup_archive + 0xe0
> SPOServer + 0x323000
> 14 : SPOServer::server_main + 0x7d            SPOServer + 0x3234ed
> 15 : main + 0x4b                              SPOServer + 0x32399b
> 16 : mainCRTStartup + 0x12c                   SPOServer + 0x87064c
> 17 : RegisterWaitForInputIdle + 0x49          kernel32 + 0x16d4f
>
> Fatal error. Consult logs for more information.
> Assertion failed: class_pointer_type_info == object.type, file
> object\metaobject.cpp, line 134
> ======================================================
>
> The logs are empty, and I dont know enough about Massiv internals (yet !!)
> to track this one down
>
> Can anyone give me some ideas what I may have done wrong, and what needs
to
> be done to fix it ??
>
> Running Massiv-1.1b win32.x86_msvc7.debug.static.stdcpp
> Library/Client/Server compiled with Multithreaded Debug DLL code
generation
>
>
>
>
>


----------------------------------------------------------------------------
----


>
> --
> You receive this message as a subscriber of the mas...@ob...
mailing list.
> To unsubscribe: mailto:mas...@ob...
> For general help: mailto:sy...@ob...?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>

> We should start to committing codes in March once we get it to a stable 
> state.

Excellent!
Let us know if you will have any problems regarding compiling Massiv or 
any other technical questions.

Regards
-- Markoid

Sorry to be so quite for a while. We are working with a partner in 
China to use Massiv as the backend for their MMORPG title. The 
improvement we are working at on massiv including:

1. SWIG integration: SWIG is a integration with scripting 
(http://www.swig.org/)

2. P2P integration on the protocol. STUN (a UDP based P2P tunneling 
program)

We should start to committing codes in March once we get it to a stable 
state.

David

> I have read through the documentation, very impressive
> work the team has done!

Thank you.

> 1. I am curious, is there ongoing development?

All the major work finished at April 2004 when the project was completed and
successfully approved (it was a school project, you know). Several people
have been interested in using/improving the Massiv, mostly David Li, that
migrated the project from SF to ObjectWeb and wanted to estabilish a new
development team. Unfortunatelly we have not heard from him for quite a
while and do not know if the new team has made any progress.

> 2. If I were to use this in a commercial application,
> what kind of support is available?

I can help you understand the core internals. However I can not guarantee
anything.

Also there are some issues with the core that would probably have to be
resolved prior using the Massiv in a commerical application. These are
network subsystem, that now stupidly relies on TCP services provided by the
OS (we need a "session layer" that can overcome TCP connection dropping;
probably not to use TCP at all) and missing automatic archive management.
See TODO list on the web page for complete information.

On the other side, everything what we planned to support is fully
functional.

> 3. What kind of load can the system support?

We ran several clients (30 if I remember correctly) with disabled rendering
(ctrl+r) on a single box without problems. Also note that the current Demo
might be rather "slow" because it is designed to excersise the object model.
For example sectors were intentionally made very small (8x8 tiles; where
each entity occupies at least one tile) so that object migration and its
impact on the resource load could be tested (any inter-sector communication
is treated as if it were remote, because each sector can be on a different
server); there is a lot of small objects, everything is implemented as a
managed object (for example sector tile), etc. So certainly there is a
potential for a speedup. If sectors spanned hectars, the majority of the
load would be local. And yes, there is a load balancer.

> I am looking forward to getting into the guts of this
> system.  The most impressive part is the amount of
> documentation.  The reason most open source systems
> don't is their documentation.  Good job to all!

Thank you.
-- Markoid

Hi, finally got around to do the moving of Massiv to ObjectWeb.

<http://massiv.objectweb.org/>

David Li

> Sorry for the long long delay.

It is great to hear from you again. We have just become worried that you
abandoned your ideas on improving Massiv.

> Doing the moving of the CVS and web pages this week. Is the web site
> stored in the CVS as well? I seems to remember some mentioned on this
> but I can't find the web site's files in the CVS.

Yes. It is located under massiv/doc/www. There are two subdirectories, one
contains the web content sources ("src"), the other ("dist") will contain
the generated html if you run massiv/doc/www/src/makecmd.bat or
massiv/doc/www/src/Makefile.

As a side note, please crosspost to massiv-devel as well, so that others can
comment on the topic and the response time could be shortened. Thank you.

-- Markoid

> On Oct 26, 2004, at 2:23 PM, Marek Vondrak wrote:
>
> > Hi,
> >
> > Since I have not heard from you for quite a while I am curious what the
> > current status of moving Massiv to ObjectWeb is. In the meantime we
> > have
> > already changed the license to LGPL (which applies to the
> > documentation as
> > well right now) and released the LGPL version as 1.1b on the
> > SourceForge.
> >
> > Regards
> > -- Marek Vondrak
> >
> >
>
>

Hi.

I did all the necessary steps to release Massiv under LGPL. New sources
containing the updated copyrights can be download from sourceforge
downloads.
-- Markoid

Markoid ( or Marek, which do you prefer for these type of correspondances?)

Thanks for the reply.

"Well, I am no C# expert but I am aware of some of its features and I can
tell that if Massiv was to be written in C#, some of its features would not
have to be implemented because they are directly supported by the CLR
runtime or they could be implemented differently. Support for introspection
or garbage collection come to mind, for example (another question is how the
Massiv semantics would fit to CLR). Also in C# you can tag class members by
user defined attributes which could have been exploited to dump the need for
describing classes in IDL."

Yes, the first few things that popped to mind were exactly what you 
suggested - using CLR's reflection, and using using attributes on classes 
instead of Massiv's IDL to describe classes. I am concerned about replacing 
Massiv's garbage collection, but it would make sense so I'll have to look at 
that a lot more when I get to it.

"I do not know if the current architecture can easily be adopted to the CLR 
environment as it is been designed to exploit modern C++ features and to 
make the use of the middleware easier than using other (read no "C++ 
friendly") systems like CORBA. It is quite likely that
some of the subsystems (properties, pointers) would have to be completely
redesigned/rewritten in order to target the CLR."

Well, I don't think it'll be easy. I realize that Massiv relies heavily on 
c++ templates, and yes, the trickiest systems are the properties and 
pointers. I've read through those classes, and while they will be the worst, 
they shouldn't be impossible to port. I'm counting on using the new support 
in .NET 2.0 for generics (similar to templates in C++ in most regards). The 
"pointer" folder will be the trickiest, with the way Massiv handles remote 
objects, strong and weak pointers, casting, etc.

"What is the intention of the port? If you are going to write a C# based
middleware using the ideas taken from Massiv, then go ahead, but remember
that we (6 members) were writing Massiv for almost 3 years and it was not an
easy task."

I know - there is a crazy amount of code in Massiv. That's what I'm counting 
on actually - that you guys knew what you were doing when you created this 
framework. The intent of the port is threefold - I want to use Massiv for my 
game project, and I want to prove that games can be written in almost any 
language as long as the time critical pieces are optimized, including C#. I 
want to learn C#, since my experience lies more in C++ (I'm a senior 
programmer at a game development company), then Visual Basic and Java. I 
want to learn Massiv. There's no better way to learn a complex system like 
Massiv, than porting it. To port it, you need to learn how every little 
piece of the system works, in its entirety. I've spent hours pouring over 
the docs, (very very nice job by the way), now to see if I can actually get 
it running in C#.

I'll do my best to get the port done. If it doesn't work, then it doesn't 
work. I've been working on a massively multiplayer game for almost 6 years 
now, with varying degrees of success over the years. 
(http://www.legendsoftacendia.com). I've written it by first creating the 
client application using 3rd party libraries for graphics and input, and 
then hacked in simple networking using DirectPlay. I always knew that I'd 
have to replace the networking portion of that, but it turns out I had to 
scrap the graphics portion as well because I had to change engines 
completely. I then started looking at middleware network libraries, and 
seeing if I could write the networking portion first. Like I said, I really 
liked Quazal, but it costs $70k plus royalties for commercial use, or $500k 
without royalties. In the end, I would like to keep the option of going 
commercial open, and not lock myself into a closed source networking 
library.

"Anyway, good luck! I did not want to discourage you from the work on the
port I only wanted to point at potential pitfalls."

Definitely! Thanks for your tips.

I'm pretty sure i have a grasp of Massiv as a whole, and how the systems 
work. The code and documentation are excellent. Great job to all of you.

I'll probably post a big "this is how I understand Massiv architecture as a 
whole" message, which will help me gather my thoughts about how Massiv 
works, and may help others who read it.

Regards,

Clay

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

On Monday 11 of October 2004 11:56, you wrote:

> V docs neni nikde ani zminka o licenci. Ale uz existuje soubor
> massiv/doc/COPYING, takze spis bych dal do zdrojaku odkaz sem a zmenil
> obsah toho souboru?

Osobne nejak predpokladam, ze COPYING bude GPL. Udelal bych 
massiv/doc/licenses, tam hodil texty licenci a soubory:
- documentation.txt
- sources.txt
- data.txt
Ve kterych bude napsano, ceho se tykaji a jake licence na to plati. Do 
documentation.txt a sources.txt bych zatim napsal jenom LGPL, do data.txt 
GPL. Ze zdrojaku se pak odkazuj na massiv/doc/licenses/sources.txt. Mozna 
dopsat i odkazy do zdrojaku dokumentaci.

Pozn.: data se tyka vsech nasich dat, tedy textur, meshu apod. Tam bych nechal 
globalne GPL, uz jenom protoze tam mame veci z egoboo, ktere byly pod GPL, a 
to proste na LGPL/BSD zmenit nemuzem.

-- Sipak

> Sorry, I realize this list is usually Czech only, but hopefully someone
will
> be able to read this.

The list used to be private and has been opened to public quite recently.

> Just thought I'd let you know that about a month ago I was searching
> SourceForge for massively multiplayer middleware. I do this every few
> months, because you never know what might pop up. Imagine my surprise when
I
> found Massiv, a project that's obviously been in development for several
> years, with full documentation!
>
> I have taken a look at several pieces of massively multiplayer middleware,
> including Quazal Eterna, Planeshift, Nevrax, and a few non massively
> multiplayer networking libraries that implement distributed objects such
as
> ReplicaNet and ZoidCom.
>
> Quazal Eterna was never really a viable option cause it's very very
> expensive, but I really like their architecture. Planeshift seems to send
> XML based messages, and the overhead seemed pretty high. Nevrax was good,
> but I originally thought the networking code was too tough to follow, and
I
> wasn't sure about whether they were going anywhere with their engine.
Turns
> out I was wrong because Ryzom looks amazing - but still, Massiv seems to
> have a really nice architecture.

This is nice to hear!

> So... I started porting this thing to C#. Why C# you might ask? Because,
> although I am a very experienced C++ programmer, within the last few
months
> I've started playing with Axiom, which is a 3D engine based on a popular
> LGPL rendering engine called Ogre. Axiom seems to run on par with Ogre,
and
> that was very impressive. Since C# can be much easier to write tools in, I
> decided to see if I could use C# for my game instead of C++. So, now I've
> decided to see if I can port Massiv to C# as well.

Well, I am no C# expert but I am aware of some of its features and I can
tell that if Massiv was to be written in C#, some of its features would not
have to be implemented because they are directly supported by the CLR
runtime or they could be implemented differently. Support for introspection
or garbage collection come to mind, for example (another question is how the
Massiv semantics would fit to CLR). Also in C# you can tag class members by
user defined attributes which could have been exploited to dump the need for
describing classes in IDL. I do not know if the current architecture can
easily be adopted to the CLR environment as it is been designed to exploit
modern C++ features and to make the use of the middleware easier than using
other (read no "C++ friendly") systems like CORBA. It is quite likely that
some of the subsystems (properties, pointers) would have to be completely
redesigned/rewritten in order to target the CLR.

What is the intention of the port? If you are going to write a C# based
middleware using the ideas taken from Massiv, then go ahead, but remember
that we (6 members) were writing Massiv for almost 3 years and it was not an
easy task.

Anyway, good luck! I did not want to discourage you from the work on the
port I only wanted to point at potential pitfalls.

> So, I just wanted to let you know that I really agree with moving the
> license to LGPL, since in my opinion it makes Massiv much more appealing
to
> a broader range of developers, and Massiv will benefit from it.

OK. Since David Li seems to have been busy recently I will do all the
changes.

> If anyone wants to help with a C# port of Massiv, please let me know. I'm
> currently half-way through the files under the "net" folder of core.

To test if the port is ever possible please look at the sources in the
property and pointer directories. These contain the most "advanced" parts of
the core that heavily realy on the use of C++ templates.

-- Markoid

Sorry, I realize this list is usually Czech only, but hopefully someone will 
be able to read this.

Just thought I'd let you know that about a month ago I was searching 
SourceForge for massively multiplayer middleware. I do this every few 
months, because you never know what might pop up. Imagine my surprise when I 
found Massiv, a project that's obviously been in development for several 
years, with full documentation!

I have taken a look at several pieces of massively multiplayer middleware, 
including Quazal Eterna, Planeshift, Nevrax, and a few non massively 
multiplayer networking libraries that implement distributed objects such as 
ReplicaNet and ZoidCom.

Quazal Eterna was never really a viable option cause it's very very 
expensive, but I really like their architecture. Planeshift seems to send 
XML based messages, and the overhead seemed pretty high. Nevrax was good, 
but I originally thought the networking code was too tough to follow, and I 
wasn't sure about whether they were going anywhere with their engine. Turns 
out I was wrong because Ryzom looks amazing - but still, Massiv seems to 
have a really nice architecture.

So... I started porting this thing to C#. Why C# you might ask? Because, 
although I am a very experienced C++ programmer, within the last few months 
I've started playing with Axiom, which is a 3D engine based on a popular 
LGPL rendering engine called Ogre. Axiom seems to run on par with Ogre, and 
that was very impressive. Since C# can be much easier to write tools in, I 
decided to see if I could use C# for my game instead of C++. So, now I've 
decided to see if I can port Massiv to C# as well.

So, I just wanted to let you know that I really agree with moving the 
license to LGPL, since in my opinion it makes Massiv much more appealing to 
a broader range of developers, and Massiv will benefit from it.

If anyone wants to help with a C# port of Massiv, please let me know. I'm 
currently half-way through the files under the "net" folder of core.

Regards,

Clay

_________________________________________________________________
Designer Mail isn't just fun to send, it's fun to receive. Use special 
stationery, fonts and colors. 
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

I guess it's probably best to keep this under LGPL until a suitable 
license can be decided in the future. LGPL with some strange 
implication on document is at least less controversial then GDPL.

We will start moving things to ObjectWeb forge next week and followed 
up with a development plan for the future.

David

On Oct 1, 2004, at 4:17 PM, Marek Vondrak wrote:

>> Yup. There are some problems associated with GFDL under the most 
>> strict
>> interpretation of the terms. Will study further. Damn lawyers. ;)
>
> So what are we supposed to do now? I think that we could accept GFDL 
> if you
> think that this is the way to go and do not come up with an 
> alternative (in
> that case
> I will ask other team members for their permissions). However, Stepan 
> would
> obviously like to use a different documentation license, because 
> GFDL-based
> documentation would probably end up in the non-free Debian pool, at 
> best.
>
>> Maybe I am thinking too much. However, I think either way, you'd like
>> to see Massiv to be used in more places and we'd like to have a good
>> base to bootstrap our game development. I am don't think BSD could
>> work because of the above reasons.
>
> Okay!
> -- Marek Vondrak
>
>

> Yup. There are some problems associated with GFDL under the most strict
> interpretation of the terms. Will study further. Damn lawyers. ;)

So what are we supposed to do now? I think that we could accept GFDL if you
think that this is the way to go and do not come up with an alternative (in
that case
I will ask other team members for their permissions). However, Stepan would
obviously like to use a different documentation license, because GFDL-based
documentation would probably end up in the non-free Debian pool, at best.

> Maybe I am thinking too much. However, I think either way, you'd like
> to see Massiv to be used in more places and we'd like to have a good
> base to bootstrap our game development. I am don't think BSD could
> work because of the above reasons.

Okay!
-- Marek Vondrak

Yup. There are some problems associated with GFDL under the most strict 
interpretation of the terms. Will study further. Damn lawyers. ;)

My primary concern with BSD is that it's harder to grow a community 
around open source. There are two objectives when I ask Massiv to be 
changed to LGPL. First, we could use it in a commercial product! Thanks 
guys!

Second, to grow a community of developers around it. Open Source is 
gaining momentum in gaming, especially in the component and middleware 
level. Open Source game logic/art works are of different issues. One of 
the most important aspect of open source project is the community of 
developers. BSD doesn't promote sharing and it hard to grow a community 
if nobody shares. It allows commercial developers to take the codes and 
make a proprietary version of it. As a commercial vendor, I'd like 
that. However, the boarder problems for our future is that our studio 
is relatively small and small organizations depends heavily on 
individuals. We have 4 programmers working on middleware right now and 
anyone of them left would cause problem for our development. It's a 
fact of life with proprietary software development, especially with 
non-standard driven system like Massiv. If this is CORBA or J2EE, I 
won't worry that much. Be able to grow a community of users help to 
solve this problem. The members of the community can share the solution 
to similar problems encountered and there are always options to hire 
good contributors to the system.

Also, with multiple commercial parties sharing, it helps to ensure the 
development of the project and build sustainable open source software. 
One key problem with the adaption of open source project by commercial 
vendors isn't really the cost but the maintainability. JBoss would be 
more expensive the WebLogic is the users have to maintain the 
development themselves. Commerical interests and sharing are base for 
sustainable open source project.

Also, looking at the economy of middleware. Commercial vendor for game 
middleware layer typically charge about 4% ~ 6% of revenue for 
licensing their software in source form. Having Massiv in BSD to 
develop a commercial version around it would cost more then licensing a 
commercial version. LGPL help to grow a community so the development 
and maintenance can be amortized across the developers, especially 
those used it in commercial apps.

Maybe I am thinking too much. However, I think either way, you'd like 
to see Massiv to be used in more places and we'd like to have a good 
based to bootstrap our game development. I am don't think BSD could 
work because of the above reasons.

David

>> On the other hand, GFDL has been defined in terms of documentation and
>> has clearly define the derivative works for documents. I think it's a
>> better license to be applied to documentation.
>
> Unfortunately many people do not like GFDL, for example it seems not 
> to be
> compatible with Debian defintion of "free 
> software/documentation/anything".
> Here are links to some interesting articles about these problems:
>
> http://en.wikipedia.org/wiki/GNU_Free_Documentation_License
> http://people.debian.org/~srivasta/Position_Statement.xhtml
> http://home.twcny.rr.com/nerode/neroden/fdl.html
>
> Unfortunately, I don't know anything about documentation licenses, so 
> I'm
> unable to decide which one to choose right now.
>
> Personally, I think that licensing everything under BSD license would 
> be ok.
>
> -- Stepan Vondrak

On Saturday 25 of September 2004 09:21, David Li wrote:

> On the other hand, GFDL has been defined in terms of documentation and
> has clearly define the derivative works for documents. I think it's a
> better license to be applied to documentation.

Unfortunately many people do not like GFDL, for example it seems not to be 
compatible with Debian defintion of "free software/documentation/anything". 
Here are links to some interesting articles about these problems:

http://en.wikipedia.org/wiki/GNU_Free_Documentation_License
http://people.debian.org/~srivasta/Position_Statement.xhtml
http://home.twcny.rr.com/nerode/neroden/fdl.html

Unfortunately, I don't know anything about documentation licenses, so I'm 
unable to decide which one to choose right now.

Personally, I think that licensing everything under BSD license would be ok.

-- Stepan Vondrak

>>    Just realize that there is no discussion on the license for Massiv
>> document. We are looking to maintain it as well as have it translated
>> into Chinese and Japanese.
>
> What do you mean by document? The content in the massiv/doc directory? 
> There
> is a file massiv/doc/COPYING that contains the current license. As I
> understand it, the license should apply to the whole CVS repository 
> (sources
> & documentation). If it was not stated explicitly, please update it.

Using LGPL for documentation is kind of strange for the following 
reasons:

1. The terms of LGPL define the "derivative works" in term of a 
software program instead of documentation. This makes it ambiguous on 
the term of the derived works such as modification and new addition to 
the documents. After all, it's hard to define whether a new chapter is 
"static linked" or "dynamic linked" to the original. ;)

2. LGPL doesn't specify how to deal with the translation of the 
document into another language. In terms of a computer programs, if 
Massiv is rewritten completely in Java, the Java programs would not 
have to follow the copyright of the C++ version under LGPL. This may 
cause ambiguity when doing translation of Massiv document into say 
Chinese.

On the other hand, GFDL has been defined in terms of documentation and 
has clearly define the derivative works for documents. I think it's a 
better license to be applied to documentation.

---

I hope all these legal discussion doesn't bother anyone on the mailing 
list. It's in my view that it's best to have a clear license terms for 
an open source program before the project itself can be grown properly. 
Need to get these tedious stuffs out of the way before getting into the 
fun technical stuffs. ;)

David

>    Just realize that there is no discussion on the license for Massiv
> document. We are looking to maintain it as well as have it translated
> into Chinese and Japanese.

What do you mean by document? The content in the massiv/doc directory? There
is a file massiv/doc/COPYING that contains the current license. As I
understand it, the license should apply to the whole CVS repository (sources
& documentation). If it was not stated explicitly, please update it.

-- Markoid

>    Will try to separate out the other codes in the demo. For those fit
> into a library, will move them to LGPL and put the rest under BSD. What
> do you think of this approach?

I think that the Demo should be considered as a simple reference application
only and do not know if it is good to extend it to a full MMO game. If you
won't use anything from the Demo LGPL might be okay for you.

> 2. Move the project (home page, source and others) to ObjectWeb forge

What will happen to the source repository on SourceForge?

> 3. Set up redirection in the Sourceforge home page to ObjectWeb home
> page.

Please note that the current web content is generated from php sources
located at doc/www at the CVS repository. If you are going to make any
changes and do not plan to create new content from scratch, update doc/www
sources.

> If possible, please add me 'taweili' to the Sourceforge developer list
> so I can handle all the migration from here.

Will do.
-- Markoid

Hi,

   Just realize that there is no discussion on the license for Massiv 
document. We are looking to maintain it as well as have it translated 
into Chinese and Japanese. We would need two things:

1. A license to be applied to the document. GNU Free Documentation 
License is recommended.

http://en.wikipedia.org/wiki/GNU_Free_Documentation_License
http://www.gnu.org/copyleft/fdl.html

2. A letter from the copyright holders to permit the translation work 
to start.

Thanks.

David Li

Hi,

   Thanks everyone's support for moving Massiv to a new license. From a 
pure commercial point of view, I think BSD makes much sense. However, I 
do believe LGPL would be better for Massiv's future as an open source 
middleware. It's harder to build an open source community around BSD.

   Will try to separate out the other codes in the demo. For those fit 
into a library, will move them to LGPL and put the rest under BSD. What 
do you think of this approach?

   We will do the following as we are moving the whole Massiv project to 
ObjectWeb forge.

1. Look through the source codes and change the license to LGPL/BSD.

2. Move the project (home page, source and others) to ObjectWeb forge

3. Set up redirection in the Sourceforge home page to ObjectWeb home 
page.

If possible, please add me 'taweili' to the Sourceforge developer list 
so I can handle all the migration from here.

Again, thanks to everyone for the support. We look forward to using 
Massiv in our project.

David Li