1

If I was to release a utility that does byte-code manipulation on core Java classes (sun.*), should I worry about licensing issues?

To provide a bit more context: In order to have an automated regression test suite running, we needed to inject our own MockSystem.currentMillis() implementation to wherever the original java.lang.System.currentMillis() was called.

As I think this small utility will be useful for many developers, I am now wondering if there are any licensing issues involved when my (going-to-be) MIT licensed code manipulates code licensed otherwise.

Chandra Sekhar
  • 16,256
  • 10
  • 67
  • 90
suls
  • 208
  • 1
  • 5
  • Have you considered this: http://stackoverflow.com/questions/2001671/override-java-system-currenttimemillis – David Grant Oct 01 '12 at 07:58
  • Yes, we have. In fact, there is work planned to exactly do this - but as always, this requires time and the bytecode manipulation lib gives us a solid ground for the time being. – suls Oct 01 '12 at 08:01
  • 1
    You'd probably be better off asking a lawyer. – NullUserException Oct 01 '12 at 08:01
  • 4
    I'm voting to close this question as off-topic because it is about licensing or legal issues, not programming or software development. [See here](http://meta.stackoverflow.com/questions/274963/questions-about-licensing/274964#274964) for details, and the [help] for more. – JasonMArcher Jun 12 '15 at 02:38

3 Answers3

2

I am not a lawyer, but in general where licensing terms of third party code comes into affect is when you are shipping that third party code.

So if you use your utility and then ship the code modified by your utility, then there could well be issues...

But if you just ship your code, and somebody uses your code on their machine (for running their tests) and does not ship the code modified by your utility, then the licensing concern s are lowered.

The users of your utility need to ensure that they are complying with the license of your utility (MIT is basically a "here is the code, do what you want, but don't blame me if it blows up in your face" license, so they should be OK using your utility) and ensure that they comply with the license of the code they are running your utility on.

Of course if they tell nobody that they are breaking the 3rd party license, and nobody knows that they are, the risk to themselves is low... but they will have to answer to a higher power (if there is one) for being a bad person who did not comply with the license!

Stephen Connolly
  • 13,872
  • 6
  • 41
  • 63
2

There should be no problems. If there were legal problems with byte-code manipulation, then we'd have heard about it.

NullUserException wrote:

You'd probably be better off asking a lawyer.

If you want an answer that has a solid legal basis, that is true. But I don't think it is necessary in this case. A simple reading of the license should be sufficient; http://www.oracle.com/technetwork/java/javase/terms/license/index.html. And I can see nothing in there that prevents you from writing or releasing byte-code manipulation tools.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

I got this from the java license. Read it as you like.

F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun", “oracle” or similar convention as specified by Oracle in any naming convention designation.

mindiga
  • 9
  • 1
  • It would be great if you could provide a link to this – Keith Smiley Jul 20 '13 at 01:37
  • [This](http://www.oracle.com/technetwork/java/javase/terms/license/index.html) is the license. But it only applies to "Java Software" "in binary form that you selected for download, install or use". So, it forbids us from replacing or modifying the `System.class` binary file from the JRE distribution, but does not forbid the runtime image of the `System` class from being replaced/modified in memory during the execution of some Java code inside a running JVM instance. – Rogério Mar 14 '17 at 18:59