Closed Bug 419491 Opened 16 years ago Closed 16 years ago

Rhino downloads and packages proprietary Sun files as part of its build process

Categories

(Rhino Graveyard :: Core, defect)

Product:
Rhino Graveyard
Component:
Core
Version:
head
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mkaply, Unassigned)

References

(
URL
)

Details

Rhino currently downloads and packages four Sun files as part of its build process:

AbstractCellEditor.java
JTreeTable.java
TreeTableModel.java
TreeTableModelAdapter.java

This invalidates the Rhino licensing.

Apparently these files are used for some debugger UI or something?

There should be an option to build a Rhino package that doesn't include these proprietary files.
If these files aren't vital for Rhino proper, the easiest fix is indeed to make their inclusion require a specific build option. In the long term, it would be good to get these files, if they are still needed, relicensed under something compatible with Rhino. Sun may well be happy to do that, given their current stance on free Java.

But for that, I'd need a clear statement from a Rhino lead saying that the files are still used and useful, and that they'd like me to investigate that possibility.

Gerv
It is my understanding these are required for the debugger GUI. Their inclusion in the project predates my involvement, so I'm not 100% clear about their status. I know that we aren't hosting the source files, but that our build process is pulling them from Sun's website automatically for compilation. It might be the case that we aren't allowed to redistribute their sources (which we don't), but we can redistribute the binary compiled classfiles.

It would indeed be preferred to get an explicit permission from Sun, so we're in the clear. Especially since lacking it, we'd need to either separate the debugger GUI into a different package, or distribute it in source code only and have people who need it run the build task for it themselves.  
I definitely think you should split out the debugger UI. There are many use cases for Rhino that do not include the debugger UI.

Also, My bet is that the redistribution of binary files separate from the original distribution is not allowed either.

I'd like to know if there was ever an agreement with Sun to do this.
(In reply to comment #2)
Attila:
I think that the GuI and build code that pulls those sources should be excluded from the default js.jar .
and only a manual build option (with a detailed readme) should allow inluding those bits.
what do you think?
would you are for a patch?
(In reply to comment #4)

As I said, these files were first included before I got involved with the project, so I don't know if we have some sort of a separate agreement/permission from Sun. I've notified Norris; he'll hopefully have some additional information from him soon.
The odd part is that these are just code samples from an article:

http://java.sun.com/products/jfc/tsc/articles/treetable2/ 

But the code is marked proprietary/confidential.

Unfortunately neither of the two people involved in writing the article work for Sun anymore.
I'll let you guys work on a technical fix; I've sent an email to Sun to ask them if they would be kind enough to solve the problem from the legal end.

Gerv

Thanks: is there anything I could help with?
I've refactored the build so we no longer ship binaries built from those files.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Norris: that's great, thanks :-) Would it be possible to push a Rhino point release, perhaps just with that change, so the latest stable code we are distributing doesn't have this problem?

Gerv
Norris:
Thanks! yes, that would be great to push a point release!
You need to log in before you can comment on or make changes to this bug.