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


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

Oracle Java license question

Started bySebastian <news@seyweiler.dyndns.org>
First post2015-01-26 15:48 +0100
Last post2015-01-28 18:46 +0100
Articles 8 — 6 participants

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


Contents

  Oracle Java license question Sebastian <news@seyweiler.dyndns.org> - 2015-01-26 15:48 +0100
    Re: Oracle Java license question Jerry Stuckle <jstucklex@attglobal.net> - 2015-01-26 10:11 -0500
    Re: Oracle Java license question Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-01-26 10:46 -0500
      Re: Oracle Java license question Sebastian <news@seyweiler.dyndns.org> - 2015-01-27 18:15 +0100
        Re: Oracle Java license question Martin Gregorie <martin@address-in-sig.invalid> - 2015-01-27 23:19 +0000
          Re: Oracle Java license question Nigel Wade <nmw@ion.le.ac.uk> - 2015-01-28 14:51 +0000
            Re: Oracle Java license question Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-01-28 11:28 -0600
            Re: Oracle Java license question Sebastian <news@seyweiler.dyndns.org> - 2015-01-28 18:46 +0100

#30909 — Oracle Java license question

FromSebastian <news@seyweiler.dyndns.org>
Date2015-01-26 15:48 +0100
SubjectOracle Java license question
Message-ID<ma5k47$aq0$1@news.albasani.net>
I find license agrrements in English legal terms hard to understand. 
Does anyone know: Am I allowed to take the source code of a Java class 
included in Oracle JDK 8 SE, copy it to a new class, modify that new 
class, and distribute the .class-file with a closed-source commercial 
product? If so, under what conditions?

-- Sebastian

[toc] | [next] | [standalone]


#30910

FromJerry Stuckle <jstucklex@attglobal.net>
Date2015-01-26 10:11 -0500
Message-ID<ma5ld8$gvi$1@dont-email.me>
In reply to#30909
On 1/26/2015 9:48 AM, Sebastian wrote:
> I find license agrrements in English legal terms hard to understand.
> Does anyone know: Am I allowed to take the source code of a Java class
> included in Oracle JDK 8 SE, copy it to a new class, modify that new
> class, and distribute the .class-file with a closed-source commercial
> product? If so, under what conditions?
> 
> -- Sebastian

If you want a legal opinion, I highly suggest you contact an attorney.
Any legal advice you get on the Internet is suspect, at the very least.
 An attorney you hire is bound by law and ethics to give you the best
advice he/she can.  Internet users are not.

This is especially true if you're looking at a commercial product.

My two best friends are my attorney and my accountant.  Both have saved
me a lot of money over the years.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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


#30913

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2015-01-26 10:46 -0500
Message-ID<ma5ngj$q41$1@dont-email.me>
In reply to#30909
On 1/26/2015 9:48 AM, Sebastian wrote:
> I find license agrrements in English legal terms hard to understand.
> Does anyone know: Am I allowed to take the source code of a Java class
> included in Oracle JDK 8 SE, copy it to a new class, modify that new
> class, and distribute the .class-file with a closed-source commercial
> product? If so, under what conditions?

	"I. SOURCE CODE. Software may contain source code that, unless
	expressly licensed for other purposes, is provided solely for
	reference purposes pursuant to the terms of this Agreement.
	Source code may not be redistributed unless expressly provided
	for in this Agreement."

... so I think the question would hinge on the extent and nature of your
modifications.  If you start with a thousand-line .java file, keep five
lines and replace the rest with your own work, you're probably fine.
But if the modifications are small and/or trivial, you're very likely
in trouble.  See Jerry Stuckle's response.

     However, I'd suggest taking a step back: *Why* do you think this
would be a desirable thing to do, if allowed?  Can you explain why the
usual O-O ways of doing things (extension, composition) do not suffice
in your case?  Why is the inherently risky "re-use by copy'n'paste" an
attractive proposition?  What problem are you trying to solve?

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

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


#30939

FromSebastian <news@seyweiler.dyndns.org>
Date2015-01-27 18:15 +0100
Message-ID<ma8h2r$uid$1@news.albasani.net>
In reply to#30913
Am 26.01.2015 16:46, schrieb Eric Sosman:
> On 1/26/2015 9:48 AM, Sebastian wrote:
>> I find license agrrements in English legal terms hard to understand.
>> Does anyone know: Am I allowed to take the source code of a Java class
>> included in Oracle JDK 8 SE, copy it to a new class, modify that new
>> class, and distribute the .class-file with a closed-source commercial
>> product? If so, under what conditions?
>
>      "I. SOURCE CODE. Software may contain source code that, unless
>      expressly licensed for other purposes, is provided solely for
>      reference purposes pursuant to the terms of this Agreement.
>      Source code may not be redistributed unless expressly provided
>      for in this Agreement."
>
> ... so I think the question would hinge on the extent and nature of your
> modifications.  If you start with a thousand-line .java file, keep five
> lines and replace the rest with your own work, you're probably fine.
> But if the modifications are small and/or trivial, you're very likely
> in trouble.  See Jerry Stuckle's response.
>
>      However, I'd suggest taking a step back: *Why* do you think this
> would be a desirable thing to do, if allowed?  Can you explain why the
> usual O-O ways of doing things (extension, composition) do not suffice
> in your case?  Why is the inherently risky "re-use by copy'n'paste" an
> attractive proposition?  What problem are you trying to solve?
>
I would like to replace (not overload) all methods in a certain class 
that have an int in their signature with analogous methods that have a 
long, where some of those methods delegate to a private instance of a 
nested class. No chance with O-O ways, I guess.

I'll take it to a lawyer. Perhaps this is a legitimate example of using 
source code for reference purposes.

-- Sebastian

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


#30940

FromMartin Gregorie <martin@address-in-sig.invalid>
Date2015-01-27 23:19 +0000
Message-ID<ma96ei$ef5$2@dont-email.me>
In reply to#30939
On Tue, 27 Jan 2015 18:15:07 +0100, Sebastian wrote:

> I would like to replace (not overload) all methods in a certain class
> that have an int in their signature with analogous methods that have a
> long, where some of those methods delegate to a private instance of a
> nested class. No chance with O-O ways, I guess.
>
If you use the documentation to write your own version *without looking 
at the source* you should be fine. Have at it: the Wine people have been 
doing this for years. MS mightn't like it, but they can't stop it as long 
as the coder hasn't seen any of their source.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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


#30943

FromNigel Wade <nmw@ion.le.ac.uk>
Date2015-01-28 14:51 +0000
Message-ID<cisbb9F5rphU1@mid.individual.net>
In reply to#30940
On 27/01/15 23:19, Martin Gregorie wrote:
> On Tue, 27 Jan 2015 18:15:07 +0100, Sebastian wrote:
>
>> I would like to replace (not overload) all methods in a certain class
>> that have an int in their signature with analogous methods that have a
>> long, where some of those methods delegate to a private instance of a
>> nested class. No chance with O-O ways, I guess.
>>
> If you use the documentation to write your own version *without looking
> at the source* you should be fine. Have at it: the Wine people have been
> doing this for years. MS mightn't like it, but they can't stop it as long
> as the coder hasn't seen any of their source.
>
>

Isn't that pretty much the crux of the Oracle vs. Google case re. Android? Oracle claim that the API itself is 
copyright, and that by developing code which provides an alternative implementation of that API Google violated the 
copyright on the API. The Federal Circuit Court of Appeals upheld Oracle's claim in 2013.

Go there at your peril. You may get away with it. But than again you may not. Can you afford the risk?


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


#30944

FromJoshua Cranmer 🐧 <Pidgeot18@verizon.invalid>
Date2015-01-28 11:28 -0600
Message-ID<mab675$cqo$1@dont-email.me>
In reply to#30943
On 1/28/2015 8:51 AM, Nigel Wade wrote:
> Isn't that pretty much the crux of the Oracle vs. Google case re.
> Android? Oracle claim that the API itself is copyright, and that by
> developing code which provides an alternative implementation of that API
> Google violated the copyright on the API. The Federal Circuit Court of
> Appeals upheld Oracle's claim in 2013.

Said case is currently pending before the US Supreme Court as a petition 
for certiorari. From what I recall of the laws, interoperability is 
notionally a permissible use (even the DMCA permits reverse engineering 
of programs for interoperability), although the culture post-DMCA is so 
far tilted to the copyright owners that such protections are nothing 
more than words.

Just because a circuit court upholds a decision does not make it 
precedent (cf. State Street), especially if the Supreme Court decides to 
weigh in.

Reading the petitions, Oracle claims that the method, er, prototypes of 
Java were copyrightable because (roughly speaking) they're "creative" 
and "large" (if I read one more "over 7,000 lines" in this petition, I 
want to punch their lawyer)--effectively claiming they're not an API but 
actually regular code instead. Reading the amici, it strongly looks like 
that almost everyone agrees (including groups nominally pro-copyright) 
that the Federal Circuit Court was idiotic and wrong for saying APIs 
were copyrightable. One amicus even argued that certiorari shouldn't be 
granted because (paraphrasing) it's bloody obvious that the Federal 
Circuit Court made a simple mistake in fact of law, and that's no reason 
to grant certiorari.

Side note: if you want to have a laugh, go read some legal briefs. I 
liked the example one gave that this case is like a screw manufacturer 
(named Delphi) declaring their screws to be "sculptures" to prevent 
competitors from copying them.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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


#30945

FromSebastian <news@seyweiler.dyndns.org>
Date2015-01-28 18:46 +0100
Message-ID<mab798$4p8$1@news.albasani.net>
In reply to#30943
Am 28.01.2015 15:51, schrieb Nigel Wade:
> On 27/01/15 23:19, Martin Gregorie wrote:
>> On Tue, 27 Jan 2015 18:15:07 +0100, Sebastian wrote:
>>
>>> I would like to replace (not overload) all methods in a certain class
>>> that have an int in their signature with analogous methods that have a
>>> long, where some of those methods delegate to a private instance of a
>>> nested class. No chance with O-O ways, I guess.
>>>
>> If you use the documentation to write your own version *without looking
>> at the source* you should be fine. Have at it: the Wine people have been
>> doing this for years. MS mightn't like it, but they can't stop it as long
>> as the coder hasn't seen any of their source.
>>
>>
>
> Isn't that pretty much the crux of the Oracle vs. Google case re.
> Android? Oracle claim that the API itself is copyright, and that by
> developing code which provides an alternative implementation of that API
> Google violated the copyright on the API. The Federal Circuit Court of
> Appeals upheld Oracle's claim in 2013.
>
> Go there at your peril. You may get away with it. But than again you may
> not. Can you afford the risk?
>

I think my case woould be a bit different, as 1) the API is small and 2) 
I need a (slightly) different API, not a different implementation. A 
layman at law can only speculate, I gather.

-- Sebastian

[toc] | [prev] | [standalone]


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


csiph-web