Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31409 > unrolled thread

Is it legal to backport code from JDK8 to JDK6?

Back to article view | Back to comp.lang.java.programmer

Contents

  Is it legal to backport code from JDK8 to JDK6? Haddock <ffm2002@web.de> - 2015-03-30 04:37 -0700
    Re: Is it legal to backport code from JDK8 to JDK6? Jeff Higgins <jeff@invalid.invalid> - 2015-03-30 10:04 -0400
    Re: Is it legal to backport code from JDK8 to JDK6? Jan Burse <janburse@fastmail.fm> - 2015-03-30 18:43 +0200
    Re: Is it legal to backport code from JDK8 to JDK6? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-03-30 14:06 -0400
      Re: Is it legal to backport code from JDK8 to JDK6? Jan Burse <janburse@fastmail.fm> - 2015-03-30 20:37 +0200
      Re: Is it legal to backport code from JDK8 to JDK6? Fredrik Jonson <fredrik@jonson.org> - 2015-03-31 15:58 +0000
    Re: Is it legal to backport code from JDK8 to JDK6? Sebastian <news@seyweiler.dyndns.org> - 2015-03-30 20:47 +0200
      Re: Is it legal to backport code from JDK8 to JDK6? Fredrik Jonson <fredrik@jonson.org> - 2015-03-31 16:20 +0000
        Re: Is it legal to backport code from JDK8 to JDK6? Sebastian <news@seyweiler.dyndns.org> - 2015-03-31 23:02 +0200
    Re: Is it legal to backport code from JDK8 to JDK6? Haddock <ffm2002@web.de> - 2015-04-01 11:33 -0700

#31409 — Is it legal to backport code from JDK8 to JDK6?

Hello,

JDK8 has some new class LinkedTransferQueue which has much better performance than LinkedBlockingQueue. For various reasons I can't change to JDK8. So I would like to backport the JDK8 LinkedTransferQueue to JDK6. My question is whether there could be any legal problem with that or whether that is fine. I'm working on some open source application. So all code would be open and therefore the mater could become an issue.

Thanks, Haddock

[toc] | [next] | [standalone]

#31411

On 03/30/2015 07:37 AM, Haddock wrote:
> Hello,
>
> JDK8 has some new class LinkedTransferQueue which has much better performance than LinkedBlockingQueue. For various reasons I can't change to JDK8. So I would like to backport the JDK8 LinkedTransferQueue to JDK6. My question is whether there could be any legal problem with that or whether that is fine. I'm working on some open source application. So all code would be open and therefore the mater could become an issue.
>
Here, in comp.lang.java.programmer,
you might expect some technical discussion of such a backport.

If I were a lawyer reading this post and considering a response,
I'd be asking my lawyer about the ramifications of participating
in legal discussions on Usenet.

<http://www.cobar.org/index.cfm/ID/0/subID/4820/May-an-attorney-ethically-participate-in-real-time-%22chat%22-forums,-list-server-discussions-and-Usenet/>

[toc] | [prev] | [next] | [standalone]

#31412

As long as you don't polute the java.* or javax.*
path you can produce whatever libraries you want.

http://stackoverflow.com/questions/17763834/is-it-javax-illegalreserved-package-name-or-not

Haddock schrieb:
> Hello,
>
> JDK8 has some new class LinkedTransferQueue which has much better performance than LinkedBlockingQueue. For various reasons I can't change to JDK8. So I would like to backport the JDK8 LinkedTransferQueue to JDK6. My question is whether there could be any legal problem with that or whether that is fine. I'm working on some open source application. So all code would be open and therefore the mater could become an issue.
>
> Thanks, Haddock
>

[toc] | [prev] | [next] | [standalone]

#31413

On 3/30/2015 7:37 AM, Haddock wrote:
>
> JDK8 has some new class LinkedTransferQueue which has much better performance than LinkedBlockingQueue. For various reasons I can't change to JDK8. So I would like to backport the JDK8 LinkedTransferQueue to JDK6. My question is whether there could be any legal problem with that or whether that is fine. I'm working on some open source application. So all code would be open and therefore the mater could become an issue.

     "Go not to Usenet for legal advice, for it will say both `Yes'
and `No' -- and be wrong both ways."  (Apologies to JRRT)

     The source file, too, says both `Yes' and `No'.  Right at the
top it says

     ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

... which sounds pretty restrictive.  But a little further down it says

     Written by Doug Lea with assistance from members of JCP JSR-166
     Expert Group and released to the public domain, as explained at
     http://creativecommons.org/publicdomain/zero/1.0/

... which suggests you can do whatever you like.  The link is to a
"human-readable summary" of a detailed legal document; for myself,
the summary seems not to clarify the case much.  It says that the
persons releasing the work to the public domain disclaim all their
rights in it, but that persons other than the releasers, if there
are any, retain all their rights, if they have any.

     So: The source file both claims and disclaims proprietary rights,
and the Creative Commons page doesn't seem to resolve the matter.
However, I (never having practiced law, nor attended law school, nor
even taken the LSAT) am confident you'll have no trouble.  I'm so
confident I'd bet your life on it.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#31415

Eric Sosman schrieb:
>      Written by Doug Lea with assistance from members of JCP JSR-166
>      Expert Group and released to the public domain, as explained at
> http://creativecommons.org/publicdomain/zero/1.0/

I assume what Doug Lea and collegues hacked wasn't
invented just now, has some prior art. So I guess
if somebody hacks a compatibility library out of
the java.* and javax.* path, nothing will
happen.

Except that the use of this library is clumsy,
since the java.* and javax.* path restriction
don't make it really a backward compatibility
library, so that the same client code can be used with
the old JDK and the new JDK.

Maybe if the client code uses some factory
pattern, the use of the library is less clumsy.
But still, it will be a mess. So best is replace
the bootloader with the java.* restriction as well.
He He. I guess I need to phone my lawyer now.

Bye

P.S.: Or on the other hand, convince your shop
not to use old JDK anymore and use the new
JDK, probably cheapest solution.

P.P.S.: Patching the bootloader seems to be possible:
Replacing and Patching Core Java Classes
http://media.techtarget.com/tss/static/articles/content/CovertJava/Sams-CovertJava-15.pdf

[toc] | [prev] | [next] | [standalone]

#31427

In <mfc38r$al3$1@dont-email.me> Eric Sosman wrote:
>  On 3/30/2015 7:37 AM, Haddock wrote:
> >
> > JDK8 has some new class LinkedTransferQueue [...] I would like to backport
> > [it] to JDK6. My question is whether there could be any legal problem with
> > that [?]
> 
> [...] So: The source file both claims and disclaims proprietary rights, and
> the Creative Commons page doesn't seem to resolve the matter.  However, I
> (never having practiced law, nor attended law school, nor even taken the
> LSAT) am confident you'll have no trouble.

Haddock, I'm curious, which open source project are you working on?

Many open source software organizations have dedicated mailing lists with
volunteers that are specialized on licensing questions.  While you wont get
proper legal advice by lawyers there either, they are more intimate with
what's involved. You could try asking on those lists.

https://lists.debian.org/debian-legal/
https://www.apache.org/foundation/mailinglists.html#foundation-legal

Eric, I found what I believe is the corresponding source code file in the
openjdk8 mercurial repository. And there I could not see any extra
"Oracle proprietary" licensing header. Only the default GPL plus Classpath
exception. That at least avoids the contradictory "oracle proprietary" vs
GPL aspect of the source code file in the Oracle JDK.

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9e9f5713b26d/src/share/classes/java/util/concurrent/LinkedTransferQueue.java
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9e9f5713b26d/LICENSE

By the way, Haddoc, why not check "java.version" and use LinkedTransferQueue
on the runtimes where that is available and the less performant LinkedQueue
on the older platforms? That way you can avoid any legal conundrums and optimize
for non-legacy platforms.

-- 
Fredrik Jonson

[toc] | [prev] | [next] | [standalone]

#31416

Am 30.03.2015 13:37, schrieb Haddock:
> Hello,
>
> JDK8 has some new class LinkedTransferQueue which has much better performance than LinkedBlockingQueue. For various reasons I can't change to JDK8. So I would like to backport the JDK8 LinkedTransferQueue to JDK6. My question is whether there could be any legal problem with that or whether that is fine. I'm working on some open source application. So all code would be open and therefore the mater could become an issue.
>
> Thanks, Haddock
>
I posed a similar question towards the end of January, under the heading 
"Oracle Java license question". It did in fact relate to a 
java.util.concurrent class with the same ambiguous header. I couldn't 
get definite legal advice on it, and was happy to not need to tweak that 
class after all.

However, I am developing proprietary closed source software and you 
aren't. So if you're not talking Oracle JDK, but OpenJDK, and wanted to 
contribute a LinkedTranferQueue backport to the OpenJDK JDK 6 Project 
(http://openjdk.java.net/projects/jdk6/), based on OpenJDK 8, I wouldn't 
see anything against that. The OpenJDK people will probably be able to 
advise you.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#31428

In <mfc5nj$a87$1@news.albasani.net> Sebastian wrote:

>  I posed a similar question towards the end of January, under the heading 
>  "Oracle Java license question". [...]
>
>  However, I am developing proprietary closed source software and you 
>  aren't.

You are aware that Openjdk is licensed, not under a strict GPL licence, but
under the GPL + Classpath exception? That makes quite the difference.

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9e9f5713b26d/LICENSE#l326
https://en.wikipedia.org/wiki/GPL_linking_exception

Hence, it doesn't make much difference if you distribute Openjdk code in a
closed source, non-GPL, or open source product. The GPL + CE doesn't taint
the linked code like a purely GPL licensed source code does.

-- 
Fredrik Jonson

[toc] | [prev] | [next] | [standalone]

#31430

Am 31.03.2015 18:20, schrieb Fredrik Jonson:
> In <mfc5nj$a87$1@news.albasani.net> Sebastian wrote:
>
>>   I posed a similar question towards the end of January, under the heading
>>   "Oracle Java license question". [...]
>>
>>   However, I am developing proprietary closed source software and you
>>   aren't.
>
> You are aware that Openjdk is licensed, not under a strict GPL licence, but
> under the GPL + Classpath exception? That makes quite the difference.
>
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9e9f5713b26d/LICENSE#l326
> https://en.wikipedia.org/wiki/GPL_linking_exception
>
> Hence, it doesn't make much difference if you distribute Openjdk code in a
> closed source, non-GPL, or open source product. The GPL + CE doesn't taint
> the linked code like a purely GPL licensed source code does.
>
Thanks for that clarification! -- Sebastian

[toc] | [prev] | [next] | [standalone]

#31436

Thanks for all the replies. That was very useful :-)

> Haddock, I'm curious, which open source project are you working on? 

It's just my own little wanna-be Grand Central Dispatch thing and it is very simple. I call it open source, because it's on my Github account. But it is just a little spare time thing.

Cheers, Haddock

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web