SoC recongizes all the opensource licenses listed by the OSI: http://code.google.com/soc/mentorfaq.html#licenses May be Ed can talk to the project's mentor?? Reinvesting the wheel just because of incompatible licenses is just a bit too much!!! Rayson On 6/7/06, Andreas Haas <Andreas.Haas@sun.com> wrote:
Dear Ed,
while I agree on a technical level with you, I must say license questions must be taken little bit more serious:
Releasing SISSL licensed code derivatives under Apache License for sure is not allowed. The source components you refer below were released under SISSL
http://gridengine.sunsource.net/project/gridengine/Gridengine_SISSL_license....
and there is a viable proceeding for contributing enhancements such as yours, if required. Thus, for the time being, please let us assume any change required for Xgrid DRMAA simply would be contributed back to Grid Engine open source project.
My point is: Doing it this way possibly appears somewhat cumbersome, but the Google SoC requirements can't disallow it. Just imagine you would work on a project that requires (amongst other things) some Linux kernel module be modified: I believe it is needless to say those changes would not become available under Apache license, but under GNU public license.
With regards to your question about the C-binding-detour: A C binding for Xgrid as by-product certainly were very welcome as it would get Perl, Python and Ruby bindings nearly for free. Wouldn't also the extend of changes required to com.sun.grid.drmaa be minimal for similar reasons?
Best regards, Andreas
Sun Microsystems GmbH | ++49 +941 3075-131 Dr.-Leo-Ritter-Str. 7 | N1 Grid Engine D-93049 Regensburg/Germany | System Engineering Group Lead
On Sun, 4 Jun 2006, Ed Baskerville wrote:
Thanks for the pointer!
I *was* planning on reusing the org.ggf.drmaa classes--no reason not to.
Reading that entry, it looks like I could mostly reuse the com.sun.grid.drmaa classes (put into a package named, for the time being, com.edbaskerville.xgrid_drmaa), and the JNI wrapper to the C binding, resulting in something like this:
(((Objective-C/Cocoa implementation) wrapped in C binding) wrapped in standard JNI)
versus the planned
((Objective-C/Cocoa implementation) wrapped in new JNI)
The latter is more compact; the former probably a much quicker route to a working system, probably with not much overhead. Sounds like the former is probably a better way to go; I'll look through the code to see for sure.
That said, are there any licensing issues with using modified Sun open source code? Google requires that I release my code under the Apache License--any reason why this would be a problem?
--Ed
On Jun 4, 2006, at 4:23 AM, Rayson Ho wrote:
Just finished reading it... A question on "Java DRMAA Implementation: wrap the Cocoa implementation in Java...."
Are you planning to write a Java binding from scratch??
I remember Dan put together this a while ago:
Porting the DRMAA Java Language Binding: http://blogs.sun.com/roller/page/templedf? entry=porting_the_drmaa_java_language
Rayson
On 6/4/06, Ed Baskerville <lists@edbaskerville.com> wrote:
Hi all,
As I believe Andreas forwarded to this list, I'm doing an Xgrid implementation of DRMAA as part of a Google Summer of Code project. I've written up a brief overview of the system on my blog:
http://code.edbaskerville.com/2006/06/04/xgriddrmaa-overview/
Take a look, and let me know if you have any suggestions. I plan to start implementing it this week; the Subversion repository will be available for anyone to browse online or check out.
--Ed