Without these efforts, Second Life is not an open source project.

What will a "more liberal" licence bring ?

Sorry in advance if that question misses some important point.

for Catherine Pfeffer - sometimes GPL is not accelerator: think of huge project where you have many components and not all of them GPL compatible and for particular part of timeline it is better to keep that component in... you ought to try to see it from Linus Torvalds perspective - licenses are not that important, important is what makes it valuable/important for people to embrace and use.

In an ideal world we would have perfect documentation on how the primitive system works, but as it stands we have only code and a community that is working toward building a standard.

Eddy - OK, now I understand the issue, thanks for your explanations.

I think that a source code file can hardly be regarded as a "standard". I think we are on the wrong track here.

What happens, for example, if the source code in llvolume.cpp changes? Does the new code "violate" the "standard"? Or is the new source code becoming the new "standard" automatically? Or will any source code change in that file be prohibited? All solutions sound weird.

My opinion is that this issue should be rephrased. It should read:
"Petition to build a normative document relative to primitive rendering in collaboration with Linden Labs".

Perharps they even already have such a document. After all, most companies that produce software use to document their code...

I think Linden Labs has a lot to win if they build standards. I feel it's the only way for them to make SL become the Web 3.0 and to remain a major actor of this new world. After all, we can't imagine the Web without RFCs...

I hope that helps.

This is the reason we're in this mess at all! They don't have documentation.

OTOH, I don't really know what is in llvolume.cpp so feel free to ignore me. Normally I'd be in favor of this issue, though. I think it would be good to build better rendering algorithms if someone out there was clever enough

Thanks in advance,
Thoys.

I don't think there would BE an Internet as we know it, there would be dozens of online-services networks using X.400 email gateways and their own proprietary protocols, some using Microsoft Lan Manager over OSI CLNP/TP0, some using DECNET, some using Netware... virtually nobody actually using the official OSI terminal and file transfer protocols. I was watching this develop and it was horrible: we had to use Intel System V boxes running dual network stacks to gateway between our Microsoft-based Xenix OSI network and our DEC nominally-OSI-based DECnet.

If Linden Labs wants to be the Cisco of "the 3d Internet" they really need to do everything they can to make the protocols easier to implement... including giving away their implementation under a maximally liberal license.

My comment was that the GPL has the drawbacks leading to this issue being created (which does knock it out from usefulness here) and you mentioned potentially using a draft license (which I assume is a new one) the problem with custom licenses being that their compatibility with other licenses is a bit of an unknown, the interactions between say BSD/LGPL or CDDL/GPL are fairly well documented and lawyers understand them.

Is there any ETA on when this potential dual licensing could occur? Even a rough time frame would be good in deciding whether to wait for this, or start adding UV mapping and things to Meshmeriser instead.

http://www.realityprime.com/articles/volumes-of-reading

I quote this clip from his blog post ....................

"Clicking through Adam's blog, I then found this page, in which the other people working on a more open version of Second Life lament the terms of use for LLVolume.cpp, which I coincidentally wrote back in 2001. It's open source lately, but apparently not open enough for their needs.

Now, LLVolume is interesting because it's the code that creates all 3D objects (excluding avatars and terrain). Philip wanted spheres, cones, cubes, torii, etc.. to be his virtual legos, simple and small. They originally expected to write some code for each kind of prim. I felt it was much simpler to write a common block code to create all primitives at all levels of detail, including the newer flex prims that they added after I left. And indeed, it only took about two weeks and 200 lines of code to alpha-test all the prims they wanted. [The only one that's unique, in fact, is the sculpty-prim, which is basically a texture-lookup (height map) deformation on a sphere, and I'd argue that this should be a surface feature of all prims, just as bump-mapping would be.]

The problem these open source devs found was that LLVolume is not well documented and/or is strange to people used to traditional geometry in OpenGL. So I'll make this offer: if Adam or his folks need more information on the core LLVolume concepts, I'll pitch in. I'd be happy to write a "How Second Life Primitives Really Work" post sometime, if there's sufficient interest, and it's clearly open source at this point. The main issue is making all of the images to go along with the discussion. But I can swing it in the next month or two, I think. Just let me know.

I do have one big caution though: the thrust of this open sim work seems to be to promote SL as an Open Standard. I certainly hope SL prims don't become standard in their current form. Even the original code I wrote back in 2001 could do much more than spheres and cubes, and was mainly limited by the SL protcol considerations.

If anything is going to be standardized, I'd much rather see the broader language of procedural geometry become more widely used, rather than SL's very shallow cross-section of that field.

The benefit would be that complex objects could be represented in a very concise form, and the goals Adam and others have regarding "fingerprinting" and preserving author-credit would become much, much easier to realize. That's a much longer discussion, but one I hope to take to the streets in the coming months."

I AGREE.