Re: [GtkGLExt] API changes for the next major gtkglext release (glext)

[Mukund Sivaraman <muks banu com>]

On Mon, Jan 11, 2010 at 02:51:06PM +0100, Ralf Corsepius wrote:
> On 01/11/2010 01:32 PM, Mukund Sivaraman wrote:
> >On Mon, Jan 11, 2010 at 01:36:47AM -0500, Arc Riley wrote:
> >>There is no license issue.  GLEW is under the BSD, at worse you include the
> >>BSD boilerplate in the header and copy/modify their headers.  It's fully
> >>compatible with both v2 and v3 of the LGPL.
> >
> >We cannot combine code that has a similar license to the BSD license
> >(non-copyleft), with LGPL licensed (copyleft) code.
> 
> Most BSD licenses are compatible with the [L]GPL, i.e. such kind of
> code could be relicensed using the [L]GPL as an "umbrella license".
> 
> Whether we could do so would require careful examination of these
> BSD licensed pieces of code, because some BSD licenses are
> considered non-free (Cf. http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses).

I'm not a lawyer. This is my interpretation of the license as it
applies to the generated wrappers that we distribute under the LGPL. 
The generated wrappers are not a verbatim copy of the published ext
headers, but a derived work.  I am not sure if we can simply take
something under a BSD-like license and re-distribute it under LGPL. 

OTOH, the Khronos headers don't have any advertising clause, but the
license terms have changed in the past and I don't know if the current
license is guaranteed to stay.  There are also some non-Khronos
extensions and patches to the Khronos headers, which are not clearly
licensed.

> >>More importantly, GLEW and gtkglext overlap in more ways than glext.h.
> >>There's enough dependency bloat in the Gnome community, not to mention
> >>redundant functionality taking up valuable memory and causing cache misses
> >>that hurt performance.  GLEW is barely enough to constitute a full library
> >>in any event.  That's one less dependency to worry about.
> >
> >gtkglext is a simple way to get an OpenGL context for a GTK+ widget. It
> >is not an OpenGL convenience library.  It is not intended to:
> >
> >  o Provide a scenegraph
> >  o Do input handling, window management, etc.
> >  o Draw geometric shapes
> >  o Provide convenience wrappers for GL/GLX/etc.
> 
> Agreed. I am also not excited about this proposal.

Yes regardless of the licensing issues, we don't want this in gtkglext. 
There are many people[1] who are prefectly happy with GLEW and GLee. 
If there are issues, these can be fixed and patches can be sent to
their maintainers.

1. http://www.gamedev.net/community/forums/topic.asp?topic_id=424183

		Mukund