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

[Mukund Sivaraman <muks banu com>]

On Mon, Jan 11, 2010 at 02:55:00PM -0500, Arc Riley wrote:
> On Mon, Jan 11, 2010 at 7:32 AM, Mukund Sivaraman <muks banu com> wrote:
> 
> > We cannot combine code that has a similar license to the BSD license
> > (non-copyleft), with LGPL licensed (copyleft) code.
> >
> > You can link in between these, such as a program linking to a library,
> > but not form a single binary object from it, such as a .so containing
> > both LGPL and BSD licensed code.
> >
> > I'm not a lawyer. This is our interpretation of these licenses, and
> > what we'll stick with.
> >
> 
> You are incorrect in your understanding of copyright law.
> 
> Copyright law has no concept of "linking", all that matters is what is
> considered a single copyrighted work.  The LGPL specifically allows
> "linking", and defines the parameters for this, but that is permission in
> how LGPL covered work can be used in other works and in no way impedes your
> ability to include BSD licensed work in an LGPL licensed work.  This is done
> on a regular basis in the free software community.
> 
> If you do not believe or understand this, please consult the fine folk at
> the Software Freedom Law Center ( http://www.softwarefreedom.org/) who will
> further clarify this for you.

If including BSD licensed code in LGPL code is fine as you and Ralf
say, then I stand corrected.  The license change is not the reason why
we are removing the wrappers.  So let's end this license-related
discussion here.


> GLEW is broken *now*.  It has apparently been fixed in it's development
> tree, which will not be available to us for 6-12 months after their next
> release due to the various distribution release cycles.  Our next release is
> due in 38 days, and as such, GLEW is completely unavailable to us.
> gtkglglext.h is ready and works now, it's been widely packaged and
> distributed, and that is what we are using.

Similarly, the changes we are making to gtkglext will not be available
in end-user distros for several months too.  Until then, the current
API remains as-is.

You keep saying GLEW is broken. Can you elaborate on the problems you
are facing with it apart from the .pc file and a missing configure
script, which makes gtkglext more appealing?

The gtkglext ext wrappers API is poor, when compared to GLee/GLEW. 
Even if we were to suddenly change our minds, we'd still not keep the
wrapper API as-is in the next major release, which means that your
program would still break.

> We do not like dependency bloat nor does the Gnome project.  Gnome has far
> too many dependencies as it is and there is an active, collective push to
> keep this number from expanding any further.  Removing vital functionality
> from a library, which on whole only adds a few K to the compiled .so (vs a
> few hundred K in a separate .so), because another library outside the Gnome
> project provides it's functionality is not acceptable.

Our API changes are for a new major release of gtkglext (2.0.x). This
release contains several incompatible API changes with the 1.2
branch.

However badly you want it in gtkglext, you must understand that it
doesn't belong there, and that there are superior alternatives
available.

		Mukund