k, so I researched a bit - when you mentioned mipmap.c, I immediately thought of Mesa, but I found ftp://oss.sgi.com/projects/ogl-sample/download/ to contain SGI’s reference OGL/GLU/GLUT/GLW/GLFONT implementation, which afaik, has a compatible license.
Okay, I’ll look at the open GL sample. Maybe the SGI code also doesn’t have the bugs in the quad functions.
I think I already downloaded the source, but chose Mesa without considering the license…
But what if the GLU port is distributed seperately from LWJGL, does lgpl still not allow it?
(damn, I almost finished porting mipmap.c which is not as straighforward as the other functions :’()
It would still be a hassle now that GLU will be entirely replaced and not just the more exotic functions like quadrics. I’d personally like to see the code in LWJGL itself.
- elias
yeah, I’m with elias on this one too. LGPL and BSD don’t really match, and I’d prefer something like GLU to be closely tied to LWJGL.
If you decide this way, we can add you as an developer and you can work directly off cvs.
If Erik’s hand-ported this code to Java, in other words, written it himself using Mesa and other sources as a reference, then I believe he’s entitled to give it whatever license he wants because it’s his work. The quadrics stuff is certainly unique.
Cas 
Somewhat true, problem is that when you look at some GPL/LGPL code you could potentially have problems arguing that the code itself is not copied, since some methods might be very similar.
Basing an implementation on some other less restrictive license will not carry any problems, and you won’t have to argue at all ('cept perhaps copyright).
Basically, I avoid L/GPL like the plague when I do non GPL code, simply because of it’s (quote microsoft) “viral nature”.
[quote]yeah, I’m with elias on this one too. LGPL and BSD don’t really match, and I’d prefer something like GLU to be closely tied to LWJGL.
If you decide this way, we can add you as an developer and you can work directly off cvs.
[/quote]
I will use the SGI sample as reference and start over (should be not too much work I suppose), so that my code can closely tied to LWJGL while avoiding problems.
The Mesa code is not very good anyway (quadrics are buggy, various functions are incomplete and untested, development on Mesa GLU stopped).
I’d like to follow code conventions in LWJGL as well, so you guys might want to take a look before checking it in CVS. We also might want to discuss package names and such (org.lwjgl.glu ?).
Most of the functions will be pretty much GLU compatible, I’m thinking about writing GLU compatible wrappers for the quadrics stuff. Which I would personally never use, but might be handy anyway if you want to use them in the ugly old fashioned GLU way. What do you think?
Erik
Oh my god, mipmap.c in SGI’s glu is 274kb as opposed to Mesa’s 20kb! :’(
- erikd bravely started rewriting anyway… *
EDIT: * …thinking every developer using ‘goto’ should be shot >:( *
[quote]Oh my god, mipmap.c in SGI’s glu is 274kb as opposed to Mesa’s 20kb!
[/quote]
!!!
Well, then - hang on a bit I’ll verify license issues with #gnu, they might be better informed. Stay tuned…
hmm, so it was late, everybody was sleeping - I wil ltry again tomorrow to get a more thorough answer
[quote][00:23:28] <marco_g> IIRC rewrite (as in translating to another language) doesn’t mean anything for copyright law.
[00:23:56] ooops, I didn’t go to sleep. ok, but in any event, I don’t think the linking method could matter. what matters is if you actually use the LGPL code (for example if you invent a C->Java translator and run Mesa through, you obviously couldn’t claim the copyright to it)
[00:26:48] If I translate a book from english to swedish, I probably still won’t be allowed to sell that without the original authors consent. with a computer program, you can’t just translate each line to another, so it all depends on how tightly you follow the original I guess. If you’re just sensible and don’t do anything stupid I doubt the Mesa people will give you any troubles, they’re good guys. Perhaps you should just ask them if they’d allow a Java trans
[00:26:49] lation to be BSDish no matter, in that case you wouldn’t have to worry at all.
[/quote]
curiously, they answered copyright questions, when all I wanted to get answered were license issues - oh well
Ok, so I talked with some people and seached a lot - basically, lgpl is bad in conjunction with LWJGL.
1 - Using the import statement(!) against a LGPL library is enough to invoke it.
2 - If making import statements is enough to “infect” surely rewriting something once LGPL would be even worse.
Some info:
http://article.gmane.org/gmane.comp.jakarta.poi.devel/5900
Oh, and the guys in #gnu @ freenode.net are not particularly friendly regarding license issues:
[quote][17:55:25] * mortal changes topic to ‘GNU: It’s all about software freedom || Consult your lawyer in questions related to licensing of Free Software’
[/quote]
I don’t really know where to go from here, GLU would be nice - but at the price of a 200 kb mipmap file - thats a bit daunting!
I’ll see if I can find another “free” implementation which is more simple.
Hi Matzon
Thanks for doing the research 
I was afraid of this. In the meantime, I will just do some research using the sources I have now so I can do a proper rewrite without violating licenses. As I see it, using some techniques to write my own code is ok. The SGI code is very complicated because they cover all cases while maybe it’s not necessary for LWJGL (being targeted to games and all). I mean, I don’t think we have to support all pixel formats and optimize for openGL version 1.0 do we?
Erik
Well, basically I’d just start out with the most simple cases, and then progress slowly from there - no need in optimizing each and every case, and doing all methods in fell swoop. I’m in no hurry
You can safely assume GL 1.1 and an RGB pixel format, because that’s the minimum LWJGL runs on. So yes, there’s probably a lot to carve away.
- elias
Can I also safely assume type GL_UNSIGNED_BYTE or is anyone frequently using other types? (I only had to use this type so far).
FYI, I got mesa’s mipmap function working for GL_UNSIGNED byte types, using point sample scaling. It doesn’t look very good because of the simple scaling algo, but I can use what I have now to rewrite it using some of Mesa’s techniques. That would be okay, right?
EDIT: rewrote scaling, so everything now looks silky smooth :-*
And do we really need gluBuild1DMipmaps? I couldn’t think of one possible use for it in games…
It’s about as useful as a chocolate glutSolidTeapot. Ditch it.
[quote]It’s about as useful as a chocolate glutSolidTeapot. Ditch it.
[/quote]
;D
That’s what I thought.
The current status is that I replaced the glu functions with new ones ported from SGI, except for:
- mipmaps are now just partially ported. I rewrote scaling and it looks now much better than the original mesa code. I also fixed 1 or 2 bugs in the mesa code here. I also did some refactoring in the code so there’s just very little mesa code left. Is this sufficient to call it our own code, you reckon?
- quads are also still partially from mesa. I looked in the SGI code and it’s very similar (it’s really almost the same). Since I refactored it to make it OO code, you think it’s still violating the LGPL license? I mean how many ways are there to draw a sphere, really…
Now I just have the tesselation code and the nurbs code left. Which is lots of code to port. Anyone using that?
Erik
I already ported the tesselation stuff from the SGI sample implementation some time ago. It’s integrated into jogl…
Well, I was about to use the tesselation stuff… but I just found that it isn’t there… oh well :-/
Once again it’s time to reinvent the wheel… or switch to C/C++ or JOGL…
Crap :l
Typical how java developers often claim they are switching to C++ or C# whenever there’s a little set back … :-/