Bug 229419

I guess I'll have to close this one as the sgi license isn't free software
according to the FSF:

    The "SGI Free Software License B", although its name says "free",
    is not a Free Software License.  It has three major problems.  1.
    It restricts its patent license to unmodified versions of the
    software.  2. It terminates if your use of the software infringes
    copyrights or patents which are not SGI's.  This is problematic
    because it gives SGI grounds to sue you even when you have done
    nothing to them.  3.  The license requires you to inform SGI of
    legal problems with the software.  This violates your privacy
    rights, and can conflict with professional confidentiality
    requirements, such as attorney-client privilege.

I'd like to reopen this review request.  Apparently the package doesn't actually
include code under the SGI license, it just includes the SGI license file for
some reason.  

glew is in debian, this is their summary of the copyright status:

http://packages.debian.org/changelogs/pool/main/g/glew/glew_1.3.4-5/copyright

According to Milan Ikits (glew's main developper) :

"Note that each file includes the corresponding licenses:

glew.h: SGI FSL + BSD
glxew.h: GLX + BSD
wglew.h: BSD
glew.c: BSD
auto/bin/*: GPL 2"

Found this thread on glew's mailing list :
https://sourceforge.net/mailarchive/forum.php?thread_id=31176341&forum_id=43720

So does this mean glew can or can't be included in fedora?  The debian package
is essentially unmodified from upstream and the debian maintainers seem to be
clear that the package itself doesn't include any SGI licensed code:

  Parts of the public interface are *generated* from components
  distributed by Silicon Graphics, Inc. available under the conditions
  quoted below.  None of these components are included in the source
  package and are available only thru CVS.

Note that I am packaging this as it is a dependency of enblend.  I have a patch
that removes glew support from enblend without any great loss of functionality,
so should I take this path instead?

Clearing fedora-review '-' flag as glew is in debian

Created attachment 155814 [details]
Patch to make Makefile use DESTDIR

Not a review, some points: 

Don't use %makeinstall, use patch attached above and make install 
DESTDIR=$RPM_BUILD_ROOT

New release 1.4.0 is out, update your package

License should be changed to "Assorted licenses, see
%{_docdir}/%{name}-%{version}/copyright_summary" and copyright_summary needs to
be created, using the debian copyright info as a starting point makes sense.

Maybe creating a -doc subpackage makes sense, the source tarball has a doc dir
with html documentation that can be installed.

(In reply to comment #7)
>> 
> Don't use %makeinstall, use patch attached above and make install 
> DESTDIR=$RPM_BUILD_ROOT

Thanks, I've included the patch

> New release 1.4.0 is out, update your package

Done.

> License should be changed to "Assorted licenses, see
> %{_docdir}/%{name}-%{version}/copyright_summary" and copyright_summary needs to
> be created, using the debian copyright info as a starting point makes sense.

Done, I've included the debian summary, though rpmlint complains about the
non-standard license text

> Maybe creating a -doc subpackage makes sense, the source tarball has a doc dir
> with html documentation that can be installed.

Makes sense, here it is rebuilt for fc6:

http://bugbear.blackfish.org.uk/~bruno/apt/fedora/linux/6/x86_64/SRPMS.panorama/glew-1.4.0-1.fc6.src.rpm
http://bugbear.blackfish.org.uk/~bruno/apt/SPECS/glew.spec
http://bugbear.blackfish.org.uk/~bruno/apt/SPECS/glew-1.4.0-makefile.patch
http://bugbear.blackfish.org.uk/~bruno/apt/SPECS/glew-copyright_summary

*** Bug 241847 has been marked as a duplicate of this bug. ***

Hi, here some comments:

- Provides: libglew-devel = %{version}-%{release}
Why do you need this ?

- CFLAGS="-Iinclude $RPM_OPT_FLAGS"
This will replace -Iinclude indeed - so you may need to have this in %prep (to
prevent CFLAGS replacement)
sed -i -e 's|$(POPT)|%{optflags}|' Makefile

- Prefers to uses this at %prep (if possible for the doc generated before make)
sed -i 's/\r//' README.txt doc/* 
But i wonder if this is still necessaray (at least for the README file)

- doc sub-package isn't really big, you may consider to merge it with the -devel
sub-package...Follow your thoughts about this...

- make should uses %{?_smp_mflags} (it seems to work)

- rpmlint glew on installed package show:
W: glew unused-direct-shlib-dependency /usr/lib64/libGLEW.so.1.4.0
/usr/lib64/libXmu.so.6
W: glew unused-direct-shlib-dependency /usr/lib64/libGLEW.so.1.4.0
/usr/lib64/libXi.so.6
W: glew unused-direct-shlib-dependency /usr/lib64/libGLEW.so.1.4.0
/usr/lib64/libGLU.so.1
W: glew unused-direct-shlib-dependency /usr/lib64/libGLEW.so.1.4.0
/usr/lib64/libXext.so.6
W: glew unused-direct-shlib-dependency /usr/lib64/libGLEW.so.1.4.0
/usr/lib64/libX11.so.6

You may need to have :
BuildRequires:  libXmu-devel libXi-devel mesa-libGLU-devel libXext-devel
 but it seems not to solve the issue (see libtool ?! )
You may report this upstream...

- Shouldn't we block FE-LEGAL for the sgi problem or is this clear enought for
you ? rpmlint complain about W: glew invalid-license Assorted licenses,

- cosmetic consideration 
rpmdev-newspec create a skeleton spec file that makes spec really looks better.
I would suggest to use this. Of course this is a minor problem...

(In reply to comment #10)
> 
> - Provides: libglew-devel = %{version}-%{release}
> Why do you need this ?

No good reason I can think of, gone.

> - CFLAGS="-Iinclude $RPM_OPT_FLAGS"
> This will replace -Iinclude indeed - so you may need to have this in %prep (to
> prevent CFLAGS replacement)
> sed -i -e 's|$(POPT)|%{optflags}|' Makefile

I can't remember how the CFLAGS got in there in the first place, your fix seems
to work, applied.

> - Prefer to use this at %prep (if possible for the doc generated before make)
> sed -i 's/\r//' README.txt doc/* 

Heh, I just advised the same to someone else in a different review.  It isn't
necessary anymore, gone.

> - doc sub-package isn't really big, you may consider to merge it with the -devel

I'm not sure what the criteria is for splitting or not.  As HTML documentation,
it really ought to require a web-browser..  Left as separate for now.

> - make should uses %{?_smp_mflags} (it seems to work)

Done.

> W: glew unused-direct-shlib-dependency

Don't know what to do about this, I added the extra BuildRequires anyway.

> - Shouldn't we block FE-LEGAL for the sgi problem or is this clear enought for
> you ?

It seems that if it is ok for debian then it ought to be ok for fedora.  I'll
block FE-LEGAL if it is necessary to bring it to attention?

> rpmlint complain about W: glew invalid-license Assorted licenses,

See previous comment, according to the debian document the license would be
something like "BSD + GPL"

Updated package:

http://bugbear.blackfish.org.uk/~bruno/apt/fedora/linux/7/x86_64/SRPMS.panorama/glew-1.4.0-2.fc7.src.rpm
http://bugbear.blackfish.org.uk/~bruno/apt/SPECS/glew.spec

GLEW is not ok for Fedora as is, this has been discussed with Tom "spot"
Callaway, who is the authority on this several times. So yes blocking FE-legal
would be a very good idea, except that the answer is no. GLEW is not acceptable.

But ... I got here, because Tibbs pointed to this review after I submitted glew
myself, see bug 251191 . The version of glew I submitted however has got several
encumbered parts removed / replaced, and has been approved legal wise by Spot.

Which brings us to the question how to move on from here, we could use this
version and merge in the necessary changes from mine, or start with my version,
either is fine by me.

About the GPL/BSD license questions, see the README I've added to my package,
the GPL only applies to the scripts used to autogenerate some of the code. The
code itself and thus the GLEW lib + headers is BSD.

ping Bruno!

My point of view is to review the Hans's version...
I will do some testing, to see if it works with the package i'm preparing that
BR glew-devel

[Sorry, I've been away at a conference]

Yes I'm happy for Hans to take this package, I'll mark it as a duplicate of
251191   if that is ok.

Thanks! Marking at as a dup is fine, but the current resolution of notabug also
is ok.