Bug 832853

Spec URL: http://fedorapeople.org/~brouhaha/java3d/java3d.spec
SRPM URL: http://fedorapeople.org/~brouhaha/java3d/java3d-1.5.2-2.fc17.src.rpm

Updated to fix problem building with OpenJDK7.
Dropped bundled vecmath in favor of existing Fedora package.

Created attachment 602385 [details]
Suggested changes to java3d.spec

I have successfully rebuilt the java3d src.rpm for my personal RHEL6 repo (on a SL6 machine), but I had to make following changes (see attachment in Comment 2):

java3d uses JNI, but the 1.5.2-2 rpm is missing libj3dcore-ogl.so. As a consequence I have also changed the installation directory for the .jar and .so files to %{_jnidir}/%{name}.

2 additional BuildRequries are necessary: ant-nodeps, and mesa-libGLw-devel.

Applications using java3d may have to add %{_jnidir}/java3d to the LD_LIBRARY_PATH variable before calling java in their wrapper script.

Spec URL: http://fedorapeople.org/~brouhaha/java3d/java3d.spec
SRPM URL: http://fedorapeople.org/~brouhaha/java3d/java3d-1.5.2-3.fc16.src.rpm

Has most of the changes suggested by Joachim Katzer (thanks!).  Did not add cleaning or defattr as they are declared obsolete in packaging guidelines.

they are a licence issue into the com/sun/j3d/internal dir. I'll set the legal flag to make a check if this file can be considered as a BSD like licence.

Those files are non-free because of this clause:

 * You acknowledge that this software is not designed, licensed or
 * intended for use in the design, construction, operation or
 * maintenance of any nuclear facility.

In the past, Sun was willing to drop that clause on a case by case basis (and way back in 1998, they promised they were getting rid of it entirely...), but now Sun is Oracle, and we have gotten very inconsistent help on licensing issues from Oracle.

In addition, Oracle misleadingly lists that clause as part of the standard Berkeley license here:
http://developers.sun.com/license/berkeley_license.html

You might try to reach out to the Java3d upstream to point out the issue, they may have better luck resolving this issue.

Whoops. That last comment was me. :)

If the license issue cannot be resolved with Oracle in a timely manner, you might want to have this package included in a repository which accept non-free license, such as RPM Fusion. This implies the other software that depend on java3D will need to go there too.

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

there is someone want use this package for some nuclear facility?
Spec URL: http://gil.fedorapeople.org/java3d.spec
SRPM URL: http://gil.fedorapeople.org/java3d-1.5.2-1.fc16.src.rpm

The problem with the "nuclear facility" clause is it makes the license non-free, and thus voids the possibility to have the package in Fedora.

Has anyone filled a bug upstream to try and resolve the license issue ? If yes, what the ticket number, I can't find it.

Eric, Gil, would you be willing to take this package to RPM Fusion ? It can still be brought back to Fedora if the license issue is resolved someday.

hi Xavier,
I understand the problem but I do not need to have a package that is used only in RPM Fusion. for me it is necessary to import http://www.unidata.ucar.edu/software/netcdf-java/ and its deps (http://www.ssec.wisc.edu/~billh/visad.html)
regards

p.s.
i know the difference between fedora and debian about the problems related to licensing. but in the debian package exists ...
http://anonscm.debian.org/viewvc/pkg-java/trunk/java3d/debian/copyright

Indeed, if Java3D goes to RPM Fusion, everything depending on it goes to RPM Fusion too. They could be moved back to Fedora once Java3D moves back to Fedora too (providing there are no other issue with them for Fedora, of course). I think it's better to have the packages in RPM Fusion rather than not having them at all, but you might have a different opinion :-)

Imho, the first step on the way to try and resolve this issue is to file a bug upstream. That's why I first checked upstream bugtracker, then commented in this ticket after failing to find a corresponding bug.

I'm a bit surprised this package is in Debian, as the license should probably be considered non-free for Debian too.

I've been maintaining a continuation of Java3d and in the medium term have almost
removed all the dependency on the com.sun.internal code with the objectionable license terms.

With that dependency removed, Java3d could be packaged without java3d-utils which has the nuclear facilty clause on an otherwise 2-clause BSD license.

Java3d itself is GPLv2 w/ classpath exception.

https://github.com/hharrison/vecmath
https://github.com/hharrison/java3d-core
https://github.com/hharrison/java3d-utils

Note, my fork has removed all of the native backends and relies entirely on the jogl2 project for OpenGL access.  Please let me know if people want me to check back here when the internal stuff has been removed.

Cheers,

Harvey Harrison

Please do so, and thank you for undertaking this cleanup effort.

Thanks Harvey!  I'm definitely interested in packaging a version of Java3D with the licensing problem resolved.  I'll look at the code at your links.

My primary interest in packaging Java3D was to support some 3D-printing related applications, and I think using jogl2 as the back end should be perfectly fine for that.

Updating status, I've removed the Java3d core dependency from j3dutils for all but one class which I'm still working one.  The class in question is com.sun.j3d.internal.Distance which is a collection of static math functions ported from the 'Wild Magic' library according to the file header.  Once this is removed, Java3d and vecmath should be OK to go into fedora.

If anyone has a look at that file and feels it is OK to move it over the Java3d core, I'd appreciate any advice, my current plans are to remove its use entirely from core, but it is a larger task.

Because Java3d is now a java-only project and no longer ships any native code, I imagine the fedora packages will need pruning.  How do I find the packager for JOGL2 in Fedora-land to coordinate a suitably modern version of jogl2 for Java3d's use?  I am involved in JOGL2 upstream, but not fedora as yet.

Harvey

hi
see https://admin.fedoraproject.org/pkgdb/acls/name/jogl2
after login, ask to become co-maintainer
regards

(In reply to Harvey Harrison from comment #17)
> Updating status, I've removed the Java3d core dependency from j3dutils for
> all but one class which I'm still working one.  The class in question is
> com.sun.j3d.internal.Distance which is a collection of static math functions
> ported from the 'Wild Magic' library according to the file header.  Once
> this is removed, Java3d and vecmath should be OK to go into fedora.

Vecmath is already in Fedora.

And the work I did on packaging upstream Java3d, and more recently on Harvey's fork, has been based on using the existing Fedora vecmath package.

FWIW, I put in a bit of time this weekend and now have it down to only two
functions remaining in Java3d-utils that are used from Java3d-core, once those
are removed/reimplemented, Java3d should be ready to go in, it appears that a new enough Jogl2 is already packaged in fedora, so Java3d should be pretty simple to package now.

Harvey

Looking at the remaining functions, it turns out the code in question was a java port of some c++ code that was under a much more permissive license, I'm just going to go back to the original c++ and re-port these two functions myself.

Original c++:

http://www.geometrictools.com/

Covered by the Boost license:

http://www.boost.org/LICENSE_1_0.txt

I believe the boost license is an acceptable Fedora license, and is GPL compatible, whom do I ask to make sure that is OK?

(In reply to Harvey Harrison from comment #22)
> I believe the boost license is an acceptable Fedora license, and is GPL
> compatible, whom do I ask to make sure that is OK?

https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing

Status here?

I found a few more two-way dependencies between Java3dutils and java3d, and have only two left.  One is easy and one is a bit more difficult.

Easy - transparency sort comparator cache and interface
Harder - Font3D uses a geometryinfo class that unless I can find an alternative, would have to be reimplemented.


WRT getting required dependencies into fedora:

- my vecmath fork has been packaged as vecmath 1.6.0 as of last week in rawhide
- in contact with the JOGL2 fedora packager, he will update to the 2.0.2 release soon

Could we get another update on the status, please?  Thanks for all the work you've put into this, Harvey.

Sure, at this point I'm down to a single dependency, the Font3D class which uses tesselation code from the j3dutils package.  I don't have huge amounts of time these days to spend on Javs3d, so work is sporadic to say the least.

JOGL2 does ship tesselation utils that may provide suitable functionality that could be adapted, but I'm not even looking at that until a regression with offscreen canvases gets fixed.

I'm very willing to point people in the right direction if they want to help out, otherwise the status is essentially unchanged for now. The one other option is to get Oracle to relicense that file as plain BSD and then ship it, or to find the original BSD code that it was based on and import that version (I have not been able to find it unfortunately)

Harvey

(In reply to Xavier Bachelot from comment #13)
> I'm a bit surprised this package is in Debian, as the license should
> probably be considered non-free for Debian too.

Debian considers this clause as a "warranty disclaimer" and not as a license restriction: https://lists.debian.org/debian-legal/2012/09/msg00034.html
(just for completeness, I know that Fedora has different rules+obligations when it comes to legal terms).

FWIW, even Sun/Oracle agrees that the "nuclear clause" makes that license non-free, as do the lawyers who've reviewed it in the past.

In the not-too-distant past, Sun and Oracle were willing to relicense works containing the "nuclear clause" to omit that clause. It might be worth filing a bug with the relevant upstream to request relicensing there.

jerboaa's scratch build of java-1.8.0-openjdk?#d28765c33d068af9ff432a92443b93beeef88a22 for git://pkgs.fedoraproject.org/java-1.8.0-openjdk?#d28765c33d068af9ff432a92443b93beeef88a22 and rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=12181621

Are there any news about licensing?

On a cursory look, it does not seem like there is any real active upstream for Java3d. I might be mistaken though.

(In reply to Harvey Harrison from comment #27)

Harvey, any updates here?

I have pulled in the changes that separate Java3d from java3d-utils. I have tagged a version 1.6.2 in each of the projects vecmath, j3dcore and j3dutils.

This should resolve the licensing issue with java3d as it no longer requires any of the code from j3dutils with the problematic statements.

The tags, or master branchs here can be used to package:

https://github.com/hharrison/vecmath
https://github.com/hharrison/java3d-core
https://github.com/hharrison/java3d-utils

Please advise if you run into any issues packaging, but at this point it should be ready to go now.

Oh, nice. Not sure if Eric still plans to package this. Even if not, somebody will sooner or later because there's still software out there that depends on java3d.

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.