DRMAA Java binding implementations : are there license constraints?
Dear DRMAA community, In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc ) I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2. As you probably know, Eclipse has rather strict open-source licensing and IP rules. The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license. I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site. Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license? many thanks for the standardization work, Erwin De Ley (Triquetrum project co-lead)
Hi Erwin, DRMAA-WG, the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right? My $0.02, Andre. On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote:
Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around. 127 little bugs in the code...
Hi Erwin, Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software. For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link: https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
Many thanks Alan, Andre, for the fast response. So to completely clear, the following would be ok for OGF & DRMAA WG : - I (re)create the DRMAA v1 and v2 Java interfaces, in the org.ggf.drmaa package etc, as defined in the OGF documents - I add an explicit attribution to the OGF specification documents on which the interfaces are based - I add an Eclipse license header and my copyright for the code, both for interfaces in org.ggf.drmaa and for implementations in my own namespaces FYI, the result would be promoted in the Eclipse Science WG, where Triquetrum is one of the science-related projects. It might be of interest for the DRMAA and Eclipse Science WGs to reach out to each other? many thanks once again, erwin. Op 28/06/2016 om 02:16 schreef Sill, Alan:
Hi Erwin,
Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software.
For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link:
https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
Dear Erwin, first, thanks for pushing the DRMAA specification by providing implementations.
So to completely clear, the following would be ok for OGF & DRMAA WG : - I (re)create the DRMAA v1 and v2 Java interfaces, in the org.ggf.drmaa package etc, as defined in the OGF documents
Officially, there are no OGF standards defining a DRMAA Java language binding. However, there is a Java API definition that is used by most people as starting point: https://redmine.ogf.org/documents/11 Reading that document is nearly as good as reading the GridEngine DRMAAv1 Java API definition in source code. Given that situation, you cannot be compliant to a DRMAAv1/v2 Java language API. You can only be compliant to the related root specs, which are official standards with a GFD-* number. If you are interested, we could change that situation and make the results of your work an official OGF standard. I don’t know if anybody still needs a DRMAAv1 Java binding, but for DRMAAv2, it is definitely in our interest.
- I add an explicit attribution to the OGF specification documents on which the interfaces are based
In your case, that would be the DRMAAv1 root spec and and the DRMAAv2 root spec.
- I add an Eclipse license header and my copyright for the code, both for interfaces in org.ggf.drmaa and for implementations in my own namespaces
That would be fine. There is only an OGF copyright on the API definition itself, not on the code you derive from that written text. And we have no such standard anyway, as explained above. In short: The code is yours, you are free to do what you want. The best way to be compliant (at the moment) is to compare your work with what is written in the C bindings.
FYI, the result would be promoted in the Eclipse Science WG, where Triquetrum is one of the science-related projects. It might be of interest for the DRMAA and Eclipse Science WGs to reach out to each other?
Definitely. Thanks again for your efforts! Best regards, Peter.
many thanks once again, erwin.
Op 28/06/2016 om 02:16 schreef Sill, Alan:
Hi Erwin,
Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software.
For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link:
https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
Yes, exactly. I agree also that a document or documents describing the Java bindings would be in the best interest of all. Alan
On Jun 28, 2016, at 4:09 AM, Peter Tröger <peter@troeger.eu> wrote:
Dear Erwin,
first, thanks for pushing the DRMAA specification by providing implementations.
So to completely clear, the following would be ok for OGF & DRMAA WG : - I (re)create the DRMAA v1 and v2 Java interfaces, in the org.ggf.drmaa package etc, as defined in the OGF documents
Officially, there are no OGF standards defining a DRMAA Java language binding. However, there is a Java API definition that is used by most people as starting point:
https://redmine.ogf.org/documents/11
Reading that document is nearly as good as reading the GridEngine DRMAAv1 Java API definition in source code.
Given that situation, you cannot be compliant to a DRMAAv1/v2 Java language API. You can only be compliant to the related root specs, which are official standards with a GFD-* number.
If you are interested, we could change that situation and make the results of your work an official OGF standard. I don’t know if anybody still needs a DRMAAv1 Java binding, but for DRMAAv2, it is definitely in our interest.
- I add an explicit attribution to the OGF specification documents on which the interfaces are based
In your case, that would be the DRMAAv1 root spec and and the DRMAAv2 root spec.
- I add an Eclipse license header and my copyright for the code, both for interfaces in org.ggf.drmaa and for implementations in my own namespaces
That would be fine. There is only an OGF copyright on the API definition itself, not on the code you derive from that written text. And we have no such standard anyway, as explained above.
In short: The code is yours, you are free to do what you want.
The best way to be compliant (at the moment) is to compare your work with what is written in the C bindings.
FYI, the result would be promoted in the Eclipse Science WG, where Triquetrum is one of the science-related projects. It might be of interest for the DRMAA and Eclipse Science WGs to reach out to each other?
Definitely.
Thanks again for your efforts!
Best regards, Peter.
many thanks once again, erwin.
Op 28/06/2016 om 02:16 schreef Sill, Alan:
Hi Erwin,
Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software.
For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link:
https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
Yes, this sounds like a viable approach to me. I would like to someone from the core DRMAA group to confirm that this is consistent with the approaches for other DRMMA implementations. Peter? Best regards, Andre. On Tue, Jun 28, 2016 at 11:19 AM, Sill, Alan <alan.sill@ttu.edu> wrote:
Yes, exactly. I agree also that a document or documents describing the Java bindings would be in the best interest of all.
Alan
On Jun 28, 2016, at 4:09 AM, Peter Tröger <peter@troeger.eu> wrote:
Dear Erwin,
first, thanks for pushing the DRMAA specification by providing implementations.
So to completely clear, the following would be ok for OGF & DRMAA WG : - I (re)create the DRMAA v1 and v2 Java interfaces, in the org.ggf.drmaa package etc, as defined in the OGF documents
Officially, there are no OGF standards defining a DRMAA Java language binding. However, there is a Java API definition that is used by most people as starting point:
https://redmine.ogf.org/documents/11
Reading that document is nearly as good as reading the GridEngine DRMAAv1 Java API definition in source code.
Given that situation, you cannot be compliant to a DRMAAv1/v2 Java language API. You can only be compliant to the related root specs, which are official standards with a GFD-* number.
If you are interested, we could change that situation and make the results of your work an official OGF standard. I don’t know if anybody still needs a DRMAAv1 Java binding, but for DRMAAv2, it is definitely in our interest.
- I add an explicit attribution to the OGF specification documents on which the interfaces are based
In your case, that would be the DRMAAv1 root spec and and the DRMAAv2 root spec.
- I add an Eclipse license header and my copyright for the code, both for interfaces in org.ggf.drmaa and for implementations in my own namespaces
That would be fine. There is only an OGF copyright on the API definition itself, not on the code you derive from that written text. And we have no such standard anyway, as explained above.
In short: The code is yours, you are free to do what you want.
The best way to be compliant (at the moment) is to compare your work with what is written in the C bindings.
FYI, the result would be promoted in the Eclipse Science WG, where Triquetrum is one of the science-related projects. It might be of interest for the DRMAA and Eclipse Science WGs to reach out to each other?
Definitely.
Thanks again for your efforts!
Best regards, Peter.
many thanks once again, erwin.
Op 28/06/2016 om 02:16 schreef Sill, Alan:
Hi Erwin,
Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software.
For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link:
https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: Dear DRMAA community,
In the past I have bundled the DRMAA v1 Java binding API and the implementation for SGE as OSGi bundles, in the context of a pilot for the DAWN project (http://www.dawnsci.org/). ( For those interested, you can find the sources at https://github.com/DawnScience/dawn-hpc )
I would now like to migrate that work (+ a SLURM Java implementation we're finalizing) in an official eclipse project, Triquetrum (https://projects.eclipse.org/projects/technology.triquetrum). In the future my goal would be to do the same for the DRMAA v2.
As you probably know, Eclipse has rather strict open-source licensing and IP rules.
The API implementation I used before came with Son of Grid Engine, and still has the SISSL license headers, for which I am certain they will not be accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own org.ggf.drmaa sources with their own copyright and an Apache license.
I couldn't find any concrete info/requirements about licensing of the DRMAA Java APIs in your documents or on your site.
Do you have specific rules? Or can I just write&provide the API code myself and deliver that with an EPL license?
many thanks for the standardization work,
Erwin De Ley (Triquetrum project co-lead)
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around. 127 little bugs in the code...
Yes, this sounds like a viable approach to me. I would like to someone from the core DRMAA group to confirm that this is consistent with the approaches for other DRMMA implementations. Peter?
Sorry, I don’t get the question. Here is an attempt to answer it anyway: DRMAAv1 implementations are widely available for different non-C languages (Python, Java, Perl, C++, C#, Ruby). A non-C DRMAAv2 implementation is also available, in this case for Go: http://gridengine.eu/programming-apis Most of these projects rely on a working, standard-compliant DRMAA C library from the cluster framework: https://www.drmaa.org/implementations.php This is why the C binding was always the crucial thing to standardize. For the abstractions above that, we always gave the freedom to developers to find the right C->*whatever* mapping. Of course, it would be good to back-port all such efforts into OGF language binding specs again. In reality, it happened only once: http://www.ogf.org/documents/GFD.143.pdf People coding non-C abstractions of DRMAA want to solve a problem. They can’t effort to wait for OGF to publish the according spec. It was anyway never a problem, because: - The DRMAA semantics are already given by the C spec / C implementation, so the expected behavior on higher levels is clear. - The API is defined by people knowing their language really well. The don’t need us for defining the right mapping. - Implementations for the same non-C language (mainly Java) always copied the API definitions from each other. This implicitly ensured application portability. Best regards, Peter.
Best regards, Andre.
On Tue, Jun 28, 2016 at 11:19 AM, Sill, Alan <alan.sill@ttu.edu> wrote:
Yes, exactly. I agree also that a document or documents describing the Java bindings would be in the best interest of all.
Alan
On Jun 28, 2016, at 4:09 AM, Peter Tröger <peter@troeger.eu> wrote:
Dear Erwin,
first, thanks for pushing the DRMAA specification by providing implementations.
So to completely clear, the following would be ok for OGF & DRMAA WG : - I (re)create the DRMAA v1 and v2 Java interfaces, in the org.ggf.drmaa package etc, as defined in the OGF documents
Officially, there are no OGF standards defining a DRMAA Java language binding. However, there is a Java API definition that is used by most people as starting point:
https://redmine.ogf.org/documents/11
Reading that document is nearly as good as reading the GridEngine DRMAAv1 Java API definition in source code.
Given that situation, you cannot be compliant to a DRMAAv1/v2 Java language API. You can only be compliant to the related root specs, which are official standards with a GFD-* number.
If you are interested, we could change that situation and make the results of your work an official OGF standard. I don’t know if anybody still needs a DRMAAv1 Java binding, but for DRMAAv2, it is definitely in our interest.
- I add an explicit attribution to the OGF specification documents on which the interfaces are based
In your case, that would be the DRMAAv1 root spec and and the DRMAAv2 root spec.
- I add an Eclipse license header and my copyright for the code, both for interfaces in org.ggf.drmaa and for implementations in my own namespaces
That would be fine. There is only an OGF copyright on the API definition itself, not on the code you derive from that written text. And we have no such standard anyway, as explained above.
In short: The code is yours, you are free to do what you want.
The best way to be compliant (at the moment) is to compare your work with what is written in the C bindings.
FYI, the result would be promoted in the Eclipse Science WG, where Triquetrum is one of the science-related projects. It might be of interest for the DRMAA and Eclipse Science WGs to reach out to each other?
Definitely.
Thanks again for your efforts!
Best regards, Peter.
many thanks once again, erwin.
Op 28/06/2016 om 02:16 schreef Sill, Alan:
Hi Erwin,
Andre is right. OGF IP rules - which are designed to promote reuse and derivative works according to their terms - apply only to the OGF documents themselves. There are many examples of open source as well as commercial implementations of these specifications. It is up to the author or authors of those implementations to set license conditions for their software, which of course cannot apply to the OGF document or documents that serve as the basis for such software.
For further information, please consult the links to the open public process for creation of OGF documents given online at OGF.org/documents or directly at the following link:
https://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
Alan
On Jun 27, 2016, at 6:33 PM, Andre Merzky <andre@merzky.net> wrote:
Hi Erwin, DRMAA-WG,
the discussion if APIs are copyrightable or not has, I presume, serious implications for the work of most of us. Specifically in the context of APIs specified in the OGF context, I would suggest to follow the no-copyright stance. Mind, that holds for the API *specification*, not the code which *implements* the specified semantics! But if I understand your inquiry correctly, this is what you are asking about, and the implementation will be new code from you and/or your project, right?
My $0.02, Andre.
> On Mon, Jun 27, 2016 at 12:38 PM, erwindl0 <erwindl0@gmail.com> wrote: > Dear DRMAA community, > > In the past I have bundled the DRMAA v1 Java binding API and the > implementation for SGE as OSGi bundles, in the context of a pilot for the > DAWN project (http://www.dawnsci.org/). ( For those interested, you can find > the sources at https://github.com/DawnScience/dawn-hpc ) > > I would now like to migrate that work (+ a SLURM Java implementation we're > finalizing) in an official eclipse project, Triquetrum > (https://projects.eclipse.org/projects/technology.triquetrum). In the future > my goal would be to do the same for the DRMAA v2. > > As you probably know, Eclipse has rather strict open-source licensing and IP > rules. > > The API implementation I used before came with Son of Grid Engine, and still > has the SISSL license headers, for which I am certain they will not be > accepted by the Eclipse Foundation. I noticed that e.g. Gridway has its own > org.ggf.drmaa sources with their own copyright and an Apache license. > > I couldn't find any concrete info/requirements about licensing of the DRMAA > Java APIs in your documents or on your site. > > Do you have specific rules? Or can I just write&provide the API code myself > and deliver that with an EPL license? > > many thanks for the standardization work, > > Erwin De Ley > (Triquetrum project co-lead) > > -- > drmaa-wg mailing list > drmaa-wg@ogf.org > https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code... -- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org https://www.ogf.org/mailman/listinfo/drmaa-wg
-- 99 little bugs in the code. 99 little bugs in the code. Take one down, patch it around.
127 little bugs in the code...
participants (4)
-
Andre Merzky -
erwindl0 -
Peter Tröger -
Sill, Alan