Re: [Freeglut-developer] As an eerie silence descends ...

[Steve B. <sjb...@ai...>]

Mike A. Harris wrote:
> On Sat, 19 Jul 2003, Steve Baker wrote:
> 
> 
>>>As long as freeglut is under an OSI approved license, and _not_ 
>>>"GPL", it will likely be included in any Linux distributions 
>>>without problems.
>>
>>Right - but that way we have to win over a dozen or more distro
>>groups/companies - and the users are thrown into chaos and confusion
>>as some distro's continue to ship GLUT, others freeglut and yet others
>>ship neither.
> 
> 
> Well, I can't speak for other distributions, but I can speak for 
> Red Hat Linux at least.  As long as freeglut has an OSI approved 
> license, and it is not GPL, assuming it replaces glut well, I 
> would ship it in Red Hat Linux as the official replacement for 
> GLUT.  I prefer to remove the "GLUT" packages entirely, however 
> that decision is not yet made, but is very likely.

RedHat does tend to be a little more adventurous when it comes
to releasing new stuff than the other distro's (which is not
without problems in itself) - but it's not enough for it to
simply exist in the RedHat distro and not in the others.  Some
of the others are quite slow in picking up new releases of stuff.

It helps to note that the GLUT license (such as it is) is
extremely vague on certain key points - and some distro's
really shouldn't be shipping it because it's really not
OpenSource in the conventional meaning of the term - even
though it comes with source code.  It's more akin to
Microsoft's idea of a "Look but don't touch" source code
license.

> So MIT/BSD/LGPL is fine for all purposes to replace GLUT.  
> However if the license were GPL, then freeglut would not 
> completely replace GLUT, and we'd be in a bind.  I'd either ship 
> both freeglut and glut, or neither, or just keep the broken glut 
> that doesn't work with Nvidia's drivers - which would suck.

I hadn't heard about a "broken glut that doesn't work with nVidia's
drivers"...please elaborate?

> Another thing you should be aware of, is that in addition to 
> the license of software included in XFree86 needing to be MIT or 
> similar, generally things are not added unless something that is 
> part of the XFree86 build procedure _requires_ it.

Really?  I didn't know that.  That's a bind because I doubt that
anything in Xfree86 does need GLUT.

 > That is the
> case for the majority of things included in XFree86, but there 
> are some exceptions of course.  Being included in Mesa might be 
> enough to get it into XFree86 though.

Well, Mesa's demo package DOES require GLUT - but that demo package
might not ship with Xfree86 either?

Does anyone know whether that's the case?

>>GLUT would be obsolete at a stroke - and would completely vanish
>>in a couple of years.
> 
> I'd say GLUT is obsolete (for all intents and purposes) 6 months 
> after we ship our next distro.

:-)

That's a very RedHat-centric view of the world.  I'm not sure it's
true.

>>Until that happens, it will be hard for application programmers
>>to take advantage of the whizzy new features we add.
> 
> Simple solution to that, is to get more software out there
> unconditionally relying upon freeglut features not present in
> glut.   ;o)

Oohhh!  Naughty!

It takes a brave application programmer to do that.  Making your
code rely on what is still a pretty obscure library that's not
shipped with ANY distro's can be the kiss of death to that
application.

I'm a significant user of GLUT/freeglut - but even as nominal
owner of the freeglut project, I won't use any of it's special
features until it's in a vast majority of distro's.

>>The Xfree86 team will ONLY accept Xfree licensed packages. No
>>other license - no matter how "compatible" - will be acceptable
>>to them.
> 
> There is BSD licensed stuff in XFree86 sources.  There are other 
> exceptions as well, such as the Luxi and Marthudo fonts, which 
> have restrictions.

Really!!   Their published submissions policy says otherwise (or
at least it did last time I checked).

They certainly don't like LGPL - that's the whole reason Mesa
had to add Xfree licensing.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----