Bug 832853 - Review Request: java3d - Java 3D
Review Request: java3d - Java 3D
Status: NEW
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
: 881586 (view as bug list)
Depends On:
Blocks: FE-Legal FE-JAVASIG
  Show dependency treegraph
 
Reported: 2012-06-17 21:34 EDT by Eric Smith
Modified: 2015-12-14 05:40 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Suggested changes to java3d.spec (2.44 KB, patch)
2012-08-05 16:46 EDT, Joachim Katzer
no flags Details | Diff

  None (edit)
Description Eric Smith 2012-06-17 21:34:19 EDT
Spec URL: http://fedorapeople.org/~brouhaha/java3d/java3d.spec
SRPM URL: http://fedorapeople.org/~brouhaha/java3d/java3d-1.5.2-1.fc16.src.rpm
Description:  
The Java 3D API provides a set of object-oriented interfaces that
support a simple, high-level programming model you can use to
build, render, and control the behavior of 3D objects and visual
environments. With the Java 3D API, you can incorporate high quality,
scalable, platform-independent 3D graphics into applications and vecmath
applets based on Java technology.

Fedora Account System Username: brouhaha

Note: I am attempting to package Java3D because it is needed by programs for 3D printing, such as ReplicatorG, which I also intend to package.  Most of the packaging work was already done by the JPackage Project; I have done a small amount of cleanup to meet updated Fedora packaging standards, to include an up-to-date script to extract the sources from the subversion repository, and to include an examples subpackage.
Comment 1 Eric Smith 2012-07-14 02:33:39 EDT
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.
Comment 2 Joachim Katzer 2012-08-05 16:46:16 EDT
Created attachment 602385 [details]
Suggested changes to java3d.spec
Comment 3 Joachim Katzer 2012-08-05 17:14:02 EDT
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.
Comment 4 Eric Smith 2012-08-05 17:35:01 EDT
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.
Comment 5 Lameire Alexis 2012-08-07 08:18:13 EDT
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.
Comment 6 Fedora End Of Life 2012-08-07 09:52:51 EDT
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.
Comment 7 Tom "spot" Callaway 2012-08-07 09:53:44 EDT
Whoops. That last comment was me. :)
Comment 8 Xavier Bachelot 2012-09-06 10:05:13 EDT
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.
Comment 9 Xavier Bachelot 2012-11-29 04:42:47 EST
*** Bug 881586 has been marked as a duplicate of this bug. ***
Comment 10 gil cattaneo 2012-11-29 08:54:39 EST
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
Comment 11 Xavier Bachelot 2013-01-23 06:14:00 EST
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.
Comment 12 gil cattaneo 2013-01-23 07:17:54 EST
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
Comment 13 Xavier Bachelot 2013-01-23 08:13:05 EST
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.
Comment 14 Harvey Harrison 2013-02-12 00:42:03 EST
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
Comment 15 Tom "spot" Callaway 2013-02-12 09:56:22 EST
Please do so, and thank you for undertaking this cleanup effort.
Comment 16 Eric Smith 2013-02-13 03:14:39 EST
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.
Comment 17 Harvey Harrison 2013-06-15 13:13:57 EDT
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
Comment 18 gil cattaneo 2013-06-15 14:29:11 EDT
hi
see https://admin.fedoraproject.org/pkgdb/acls/name/jogl2
after login, ask to become co-maintainer
regards
Comment 19 Susi Lehtola 2013-06-17 07:10:58 EDT
(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.
Comment 20 Eric Smith 2013-06-17 11:45:58 EDT
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.
Comment 21 Harvey Harrison 2013-06-17 13:56:14 EDT
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
Comment 22 Harvey Harrison 2013-06-18 10:01:36 EDT
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?
Comment 23 Susi Lehtola 2013-06-18 10:08:22 EDT
(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
Comment 24 Christopher Meng 2013-09-12 08:12:21 EDT
Status here?
Comment 25 Harvey Harrison 2013-09-12 12:14:11 EDT
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
Comment 26 Jerry James 2014-02-13 13:03:23 EST
Could we get another update on the status, please?  Thanks for all the work you've put into this, Harvey.
Comment 27 Harvey Harrison 2014-02-13 13:30:10 EST
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
Comment 28 Felix Schwarz 2015-03-09 06:10:55 EDT
(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).
Comment 29 Tom "spot" Callaway 2015-03-09 10:55:35 EDT
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.
Comment 30 Upstream Release Monitoring 2015-12-14 05:40:53 EST
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

Note You need to log in before you can comment on or make changes to this bug.