second life client goes gpl - ryzom.org forum archive

An archived topic, merged from 23 captures made between 7 February 2007 and 24 October 2007. ryzom.org · Forum index · All captures

Author

Message

< VCA General - English ~ second life client goes gpl

valentin

Posted: Mon Jan 08, 2007 6:06 pm

Joined: 07 Dec 2006 Posts: 23

second life just released the source code of their client under gpl v2 licensing.

http://secondlife.com/developers/opensource/

not shure exactly where this will lead and whant is linden labs intent, as i understand from a quick dive the protocol is cyphered and the cypher library is not gpl.

the server code, art, rules, are not released, seems a 'me too' using the client is legally possible.

happy hacking,

valentin

Xavier Antoviaque

Posted: Tue Jan 09, 2007 4:15 pm

Joined: 15 Nov 2006 Posts: 386

valentin wrote:

not shure exactly where this will lead and whant is linden labs intent, as i understand from a quick dive the protocol is cyphered and the cypher library is not gpl.

the server code, art, rules, are not released, seems a 'me too' using the client is legally possible.

On my side, I'm quite pleased to see this happening, but I'm still fearing this could just be an attempt to get the "free software" flag and get free work. On the other side, they announced they are willing to release the server code, said they saw no issue seeing others doing their own shards (IBM example), and I couldn't find any flaw in their licensing tactic. And Second Life, despite some technical drawbacks, has much of what we want to see implemented.

Is someone willing to go have a deeper look at the code ?

The FSF is also looking for comments on this subject for tomorrow, so if you can comment on this this evening, I'll pass it on.

_________________
Xavier.

Cayle

Posted: Tue Jan 09, 2007 4:39 pm

Joined: 20 Dec 2006 Posts: 77 Location: Germany

One question:

SL uses havok, which is a closed source physics engine. What do they plan to do about the licenced dependencies? In the worst case scenario, what is left in the release after they gut it is the same as NeL for example.

Making the client OSS is not all that big a deal. A designer has to assume the client is hacked anyway, so if it is OSS it does not change anything from the perspective of the world designer. Hacked client == legit. mod to OSS client from server perspective.

_________________
The Ruleset Modeling Language - A project for making it easier to design virtual worlds.

Han

Posted: Wed Jan 10, 2007 4:00 am

Joined: 21 Dec 2006 Posts: 34

I'm making my way through the code now... but I'm not sure what you want to know. :) I'm not seeing anything mindblowing atm, somewhat making my way through the network code. Actually seeing the messaging code is an interesting read. Mind you I've never played second life but I can see the depth of transaction abilities here.

The ll before everything is getting to me though. hard to look at for a long time.

Hannon

Xavier Antoviaque

Posted: Wed Jan 10, 2007 1:14 pm

Joined: 15 Nov 2006 Posts: 386

Han wrote:

On my side, I have a few questions:

- How much of the client code seems to be GPL'ed? 100%, or less?
- Are you able to compile the whole thing and have the full SL client?
- Are third-party, closed source binaries used in the process?
- How is the documentation? A quick look at the wiki showed it seemed quite empty.
- How well is it written? Is it well commented?

_________________
Xavier.

Han

Posted: Wed Jan 10, 2007 5:18 pm

Joined: 21 Dec 2006 Posts: 34

Xavier Antoviaque wrote:

- How much of the client code seems to be GPL'ed? 100%, or less?
I see a GPL statement in every cpp I have looked at thus far, so pretty good.

- Are you able to compile the whole thing and have the full SL client?
Theres a list of Dependant libraries, I was on a windows box looking at it with VisStudio (don't hate), I didn't have time to do the library gathering it requires to compile (family stuff) .... I don't think it will be even hard to compile theres a whole guide to it - so thats good for beginners also.

- Are third-party, closed source binaries used in the process?
Off the top of my head...Yes.

I see a mix of Open and non open Libraries. For example they use a Quicktime library I would assume for media streams, DirX calls, Winmain ect.

- How is the documentation? A quick look at the wiki showed it seemed quite empty.
I dove straight into the code, for me that tells the story. I did see the wiki had a good framework for helping people get settled. I don't know how much has been filled in yet.

- How well is it written? Is it well commented?
Not hard to understand, there is no nastiness I can see... Theres a lot of it, a lot of things going on... so getting the core concept into your head could take some doing.

Comments.. well not really. I see things like //I'll get back to explain this later

and that never happens...

very thin on comments.

All in all I think people can learn from it, I however wasn't very impressed looking at some videos of the game.. thats me though.

Hannon

Xavier Antoviaque

Posted: Thu Jan 11, 2007 3:01 am

Joined: 15 Nov 2006 Posts: 386

Han wrote:

- How much of the client code seems to be GPL'ed? 100%, or less?
I see a GPL statement in every cpp I have looked at thus far, so pretty good.

I meant: does it seems to have missing parts, included in the binary version, but not in the FS tarball? It seems there isn't, as it is possible to actually play SL with hand complied version, but one never knows...

Quote:

- Are you able to compile the whole thing and have the full SL client?
Theres a list of Dependant libraries, I was on a windows box looking at it with VisStudio (don't hate), I didn't have time to do the library gathering it requires to compile (family stuff)

I've got the client compiled on my Linux box, and the process is quite straightforward. However, the OpenJPEG FOSS replacement library seems to be *really* slow. I don't know how much implementation optimizations it lacks, but it would be a first issue for any third party project willing to redistribute the client.

Quote:

I see a mix of Open and non open Libraries. For example they use a Quicktime library I would assume for media streams, DirX calls, Winmain ect.

Except for the use of FMOD if you want any sound at all (but that was also an issue with Ryzom), it doesn't seem to require any other closed source libraries.

Quote:

I dove straight into the code, for me that tells the story. I did see the wiki had a good framework for helping people get settled. I don't know how much has been filled in yet.

I had a look, and the documentation is very thin. I don't know if that will really help, but they are aware of the need, and promised to improve this. Considering the good quality of the available documentation, the use of a wiki and the general transparency methods they seem to be using (have a look at the blog), we can have reasonable hopes this will be the case.

Quote:

All in all I think people can learn from it, I however wasn't very impressed looking at some videos of the game.. thats me though.

True, the graphics aren't terrific. But Mosaic wasn't pretty either back in its early days, beauty and web is a recent wedding, now that the technology is mature. I expect this should work quite the same way for SecondLife, if Linden Labs follows the promised "standards" road.

What I like about SecondLife is the fact that they already have developed the core feature a community driven online universe needs: the ability for everyone to create objects, furnitures, buildings, features, directly from inside the game.

To learn more on our side while the FSF is discussing, I've dropped an email to Philip Rosedale, Linden Lab's CEO. He promptly answered, and included Cory Ondrejka (CTO) and Rob Lanphier (FOSS Community Liaison) in the discussion. I've started asking the few questions from this thread. If you have specific questions you'd like an answer on, write them here, I'll copy-paste them.

_________________
Xavier.

Xavier Antoviaque

Posted: Thu Jan 11, 2007 6:57 pm

Joined: 15 Nov 2006 Posts: 386

And the answer from Cory Ondrejka (CTO):

> So, I'm even more eager to get reassured about a few points which,
> depending on your answers, could be issues preventing free software
> contributors from participating to the project.
>
> - The first, and probably most important point, is the server code. You
> have written several times that you are willing to release it. Would it
> be possible to know precisely what are the elements still restraining
> you from doing it? A timeframe? It won't be a surprise to you that the
> ability to run its own shard is a high incentive for a developer or a
> team to contribute. Without the server code, most of them wouldn't
> consider moving to develop on SecondLife.

I feel that we still have a lot to learn about running a FLOSS project,
so one of the reasons for releasing the client code first is to allow us
to build expertise in that area. The client is relatively self
contained, has a great deal of potential for exploration and
improvement, and lets the community and Linden Lab learn from each
other. Beyond that, the servers as currently written, are not ready to
be run in non-Linden Lab environments. Fortunately, the road map to fix
those issues (primarily trust relationships between the simulators and
each other, moving some transactional logic out of the simulators) is
pretty clear to us. I am not able to place a time frame on those
changes other than "as quickly as we can." We continue to be
constrained by development resources, so while we will do everything to
get those changes done -- and believe me, we understand the benefits
that will come with that transition -- it is going to take a while.

>
> - What about Havok? How do you plan to release code which depends so
> heavily on a closed source library as GPL?

Much like FMOD or Kakadu on the client, we use Havok right now because
it is the best choice. Fortunately, it is wrapped within a fairly nice
abstraction layer, so part of the preparation for a server code release
would be the parallel strategies of asking Havok whether they are
comfortable opening up their source and exploring which of the existing
FLOSS physics engines could be substituted.

Note that one unique aspect of Linden Lab's decision to release our code
is that no market leader has ever made this decision before. Other
competitors have gone the FLOSS route in an attempt to disrupt the
market, but to our knowledge this is a first. If this proves as
successful as we believe it will be, it provides an incredibly leveraged
argument to take to Havok, because we'll be able to say "Look, we were
the market leader, we released source, and now we have this incredible
community working on our code. You should do the same!" So, there are
some potential meta benefits to the Ryzom community generating strong
support for SL.

>
> - About the client, a local compilation using OpenJPEG showed me that
> this is *really* slowing down loading time. I know this is in the FAQ,
> but currently it is to the point where it is barely usable - for sure
> no third party distribution could be serious before this is solved. Do
> you plan to work on this?

We have heard from both the libsecondlife folks and others that they
have already been working on optimizing this code, so I am confident
that this will be addressed soon. After all, improving OpenJPEG is
exactly the kind of self contained and well understood change that FLOSS
approaches have repeatedly demonstrated success with.

>
> - This raises the more general question of the convergence between the
> official binaries and the FOSS distribution. To be efficient and avoid
> having a FOSS version lagging behind the official one, effectively
> discouraging contributors, one needs to have as much differences as
> possible between the two. And a willingness to reach zero differences -
> the FOSS version should become, at the end, exactly the same as the
> official version. Are you willing to work in that direction?
>
> - A side topic here is the current CVS discussion running on your
> development mailing list. As Duffy Langdon pointed out, "getting access
> to a CVS system, where the stable and head branches can be retrieved is
> a priority, otherwise the code made public will quickly grow
> stale." If you are only syncing every now and then, it won't work.
> Others have already done this mistake, I have seen the effects of this
> myself, please tell me you won't do it. ;p

These two questions are tightly related. The goal is to achieve zero
differences. As I explained in the first point, we still have a lot to
learn about being a FLOSS project and we continue to be resource
constrained, so it will be months before we achieve this. The more
interest we see from capable contributors the easier it will be to
prioritize those changes, however.

>
> - One remark made by Phoenix on the ML ("Currently, agni is the only
> grid open for connections. We will probably be opening siva for test
> use with the open source client.") made me wonder if this is temporary
> or not, and if there was any limitations you planned to try to enforce
> for users using their own version of the client.
>

My understanding -- and Robla can chime in -- is that we will always
have a grid up that is designed to interoperate with the currently
released code. Once we are all working from the same code, we won't
need that but for now we do.

As for an arms race around official versus non-official clients, you
will see in the town hall transcript that I specifically said we
wouldn't be doing that. It is a waste of development resources. This
is why there isn't some silly "security.lib" piece that is closed source.

> I hope I'm not scaring you with all these questions and remarks. I
> reiterate that we appreciate your step forward; but it is important to
> know clearly where you stand from the start, to make sure we all talk
> about the same things, and that potential contributors can judge with
> all the required information.
>

Not a problem at all. What I ask in return is realistic expectations.
We are committed to FLOSS and to the many communities that want to
explore Second Life in every possible way, but we won't always move as
quickly as any particular constituency wants us to because I just don't
have sufficient development resources. The best way to ensure that the
servers are released ASAP is to get involved with the client code. The
more fixes and improvements are driven by the community, the more I can
free up developers to drive the server code forward.

I hope this helps.

Cheers!
Cory

Xavier Antoviaque

Posted: Thu Jan 11, 2007 7:21 pm

Joined: 15 Nov 2006 Posts: 386

So. This is evasive on some points, but in general I think it is definitely looking good. A promise is nothing in itself, but the time I have taken the last few days to study more in details what Linden Lab is doing gave me a bit of confidence.

The high degree of openness and transparency they display, the general philosophy of the project and views about the future are way too rare in commercial companies. The title of the blog post for announcing the GPL'ing of the client, "Embracing the inevitable", is quite representative of the way they talk about Free Software, and I think their comparison to Mosaic is realistic and visionary.

While I can't comment for the code, they have done a lot of things the right way, including the emphasis on user-created content through an in-game and unmoderated SDK, with the right IP approach, granting the ownership of user creations to their authors, with an easy way to let them allow free duplication.

On the other side, releasing the client is only a first step, and not sufficient in itself. They seem to be using the client release as a test bed before embracing a more complete Free Software approach. It is a fair way I think, but there is a risk of never seeing the code of the server if the success of the first phase doesn't match their expectations. I hope these expectations aren't too high.

All in all, I think what they are doing is good. Not enough to change any of the plans being discussed on these forums, but enough to praise the initiative and give them some help when needed.

The FSF thinks the same, and Peter Brown (FSF's Executive Director) is proposing to release a joint statement (FSF & VCA) "welcoming the freeing of SL and why this is important to the community". I think we should do this, and also use the opportunity to let people know where we are at (the MMO shard project by Project Angela/Peragro Tempus/Planeshift using Crystal Space, Ryzom.org becoming the Virtual Citizenship Association).

I'll work on the Virtual Citizenship website this evening to reset the donation meter, as we hadn't enough time to discuss this and are in no hurry, and rework the text content accordingly, so we can do this cleanly.

Probably later tonight, or tomorrow morning, I'll setup polls, to run over the next three days, to decide if we want to do this. I will also send an email on the newsletter to let the whole ryzom.org community participate to the decision.

In the meantime, let me know what you think, and kill me nice and clean if I'm doing it wrong.

Edit: Other sources of answers include the following blog posts from Linden Lab:

_________________
Xavier.

Xavier Antoviaque

Posted: Thu Jan 11, 2007 8:36 pm

Joined: 15 Nov 2006 Posts: 386

Another answer, from Rob Lanphier (FOSS CL), is just in.

On 1/11/07 7:02 AM, Cory Ondrejka wrote:
> Xavier wrote:
>> - One remark made by Phoenix on the ML ("Currently, agni is the
>> only grid open for connections. We will probably be opening siva
>> for test use with the open source client.") made me wonder if
>> this is temporary or not, and if there was any limitations you
>> planned to try to enforce for users using their own version of
>> the client.
>>
>
> My understanding -- and Robla can chime in -- is that we will
> always have a grid up that is designed to interoperate with the
> currently released code. Once we are all working from the same
> code, we won't need that but for now we do.
>
Yup, that's the plan. At first, things may be bumpy as we figure out
exactly how to make this a reality. We made a few changes (mostly
license and packaging changes, but a few architecture tweaks in the
way we work with proprietary third-party libraries) to make it
possible to release our source code. Until those changes make it into
all of the active development branches, we have to tread lightly in
our source releases. Once all of those changes get made, my goal is
to release source code corresponding with all beta and gold releases
that we make at the time we make them. This will make the grid
issues less of a challenge.

Over time, as this work gets done:
http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/

...the need to update code to still hook up to the grid will be
reduced, and we'll be able to further decouple grid updates and viewer
updates.

Rob

_________________
Xavier.

Yves

Posted: Fri Jan 12, 2007 11:24 am

Joined: 11 Jan 2007 Posts: 2

Xavier Antoviaque wrote:

On the other side, releasing the client is only a first step, and not sufficient in itself. They seem to be using the client release as a test bed before embracing a more complete Free Software approach. It is a fair way I think, but there is a risk of never seeing the code of the server if the success of the first phase doesn't match their expectations. I hope these expectations aren't too high.

Releasing the client is the logical first step, since it's certainly smaller than the server's code, and it's easier to try at home. However, I totally agree with the risk of Linden never releasing the server code if the client experience is not satisfying for them.

But I think the most interesting thing in this release, is the possibility to extract the protocol used between the client and the server (I guess, since I haven't look at the code). Having a fully (or almost) functionnal client is a huge step, and building something with the same protocol seems to me an important requirement for the future. If Linden open the server's code, it will permit to have the same client to use on different servers. It's another step in having a multivers. But if Linden doesn't open or is too long to open its server's code, we can concentrate our strengths on improving (eventually) the protocol (and Linden has to support/improve it too), instead of having different and incompatibles protocols between Linden and the community, which can be a waste of resources.

Yves

PS: I'm new on this forum, but I was following the situation since december...

augmento

Posted: Fri Jan 12, 2007 11:12 pm

Joined: 22 Dec 2006 Posts: 9 Location: South Korea

the GPL and open source side of this smacks of pure marketing spin. functionally this is no different than wow-addons from blizzard. market leader? phooey!

Vengeance

Posted: Sat Jan 13, 2007 6:18 pm

Joined: 05 Jan 2007 Posts: 7

Second Life brags about how little of their code is on the client in this presentation here.
. The entire client download is <20MB and all meaningful work done in the SL world is done on the server side. This is why it takes them 2000 servers (!) to support a 5500 concurrent user average. Anyone who thinks this is a meaningful step for an open source MMO is deluding themselves.

Yves

Posted: Wed Jan 17, 2007 9:13 pm

Joined: 11 Jan 2007 Posts: 2

Vengeance wrote:

Linden Labs doesn't use 2000 servers for 5500 concurrent users. They have around 2000 servers for the main islands, and individuals servers for private islands. And around 20 000 users connect the grid at the same time these days (peak of 26 000 I think). They have such many cpu because they choose to have splitted their world into individual pieces on a CPU. So the server code doesn't support a lot of people at the same place, but a lot of people distributed all around their world. It has pros and cons, it a design choice.

However, this is good news because they released not only the code of their client, but also the protocol they use. We have a working client, with a working protocol, all in an open and "libre" license. Creating a new protocol, new API with a client seems to me to be to consider after looking and understanding the existing GPLed code. This is a starting point, and the goal is not to build the same SL infrastructure, but using their contributed work as a starting point to something new.

Yves

sdahan

Posted: Fri Jan 19, 2007 7:05 am

Joined: 06 Dec 2006 Posts: 67 Location: Tsukuba, Japon

I started to take a look at the llmessage directory. This is where all the code about networking, message processing, mail, instant messaging, etc... is located.

My first impression is pretty bad:
- encryption algorithm ultra-weak: see llxorcipher.cpp
- Throttle class that does not seam to throttle: llthrottle.cpp
- do they really need xmlrpc?

Good point:
- they use xmlrpc instead of soap
- their protocol are not hard coded.

I am going to take a better look at it and try to write a review for next week or the week after.

_________________
Sylvain Dahan

arnaud

Posted: Mon Jan 22, 2007 8:24 pm

Joined: 10 Jan 2007 Posts: 3

sdahan wrote:

- do they really need xmlrpc?

Yes !
You can call a method on an in-world object from the outside.
In-game scripting is a really great feature for a virtual world. That's the main reason of the vast number of CPU they need. Most of the cpu power goes to users' scripts execution.
BTW, they plan to replace their LSL engine with Mono. The tests they ran gave them a x600 faster script execution ! And Mono will allow users to use several script langages ...

sdahan

Posted: Wed Jan 24, 2007 5:07 am

Joined: 06 Dec 2006 Posts: 29 Location: Tsukuba, Japon

arnaud wrote:

sdahan wrote:

- do they really need xmlrpc?

You can call a method on an in-world object from the outside.
In-game scripting is a really great feature for a virtual world.

The thing is more codes, more bugs, bad security. I understand the strength of xmlrpc. But knowing that their protocol as the same flexibility and is also script based, I do not see the necessity of using xmlrpc. Maybe the answer will come when I will finish to study their code.

I start to read their code and my second impression is still bad. I do not think they have lot of experience in network programming:
- buffer overflow.
- bad use of the socket API

However, I think that the scripting part can be interesting. I still study it.

_________________
Sylvain Dahan