I'm currently looking at the Metro stack on my search for a nice SOAP web service stack that should be used in a closed source project, but i dont fully understand metros license terms that can be found here:
glassfish.java.net - license
So my questions are:
Can the Java Metro stack be used in closed source projects?
If yes - what am I allowed to do with the libraries if I want to keep my own code closed source?
Best regards
After some more research I found that the Netbeans framework is licensed with the same construct (GPLv2 and CDDL) and luckily the guys at Netbeans took the time to explain the how what and why a bit:
Netbeans license FAQ
Here is what they say about dual-licensing:
Dual-licensing is the practice of distributing identical software under two (or more) different sets of terms and conditions. When software is dual-licensed, recipients can choose which terms under which they want to obtain the software. The two usual motivations for dual-licensing are business models and license compatibility. [...]
Additional search for details about CDDL brought me to this site containing a nice summary:
why the dislike for cddl
Here is one of the parts relevant that is to my question:
CDDL is a file-based license. This means that if you make any changes to CDDL-licensed software, any existing files that you modify need to remain under CDDL, but any new files that you create can be under whatever license you want as long as that license isn't incompatible with CDDL.
Conclusion (note that I'm not a lawyer and this is no legal advice - just my personal interpretation based on the available information):
Metro seems to be useable for commercial closed source projects but changes to the existing source have to be made available under the same license as the original source.
So as long as one is just using the libraries the own source code can be kept completely closed source.
At least if CDDL is chosen.
Related
I want to use the Java Advanced Imaging library jars in a close-source commercial application. In Wikipedia (http://en.wikipedia.org/wiki/Java_Advanced_Imaging) it says the license is "Java Research License" and so the library cannot be used in commercial applications.
But in the txt files that go with the jars (see here: http://download.java.net/media/jai/builds/release/1_1_3/) "Java Research License" is not mentioned. Nor any other known to me license.
My question is: What is the JAI's license ? Can the JAI library be used in a commercial close-sourced application?
What is the JAI's license ?
The JAI license is in the LICENSE-jai.txt file.
Can the JAI library be used in a commercial close-sourced application?
The license says:
"1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid."
Assuming that your "commercial" application is going to be used for something other than "internal use only" ... as intended by the license, then the answer is No.
Disclaimer: IANAL. If you need professional legal advice, ask a lawyer. If you intend to ignore the clear intent of the JAI license, you need professional legal advice. Alternatively contact Oracle to discuss alternative licensing arrangements.
UPDATE
The LICENSE.TXT in the source code repository for the "jai-core" sub-project says this:
This software is licensed by Sun:
i) for research use under terms of the Java Research License (JRL) as
specified in the LICENSE-JRL.txt file and on the web at
"http://jai.dev.java.net/jrl.html"; or
ii) for commercial use under the terms of the Java Distribution License
(JDL) as specified in the LICENSE-JDL.txt file and on the web at
"http://jai.dev.java.net/jdl-jai.pdf".
The links are incorrect, but you can find the linked documents in the source repo; e.g.
https://java.net/projects/jai/sources/svn/content/trunk/www/jdl-jai.pdf?rev=1433
To view these files, you will need to create a "java.net" account.
I'll leave you (and your lawyer!) to read them, and figure out what it all means. You should NEVER rely on the "expertise" of random people on the internet to interpret legal things for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Where can I find the entire source code for JDK 1.5 to download? I am unable to find the exact link on the oracle site; the link provided only goes in circles.
The name Java can be applied to many different components that work together. It might mean the "Java Virtual Machine" to some, the "Java Language Specification" to others, "Java compilers" to many, and "Java language libraries" to quite a few.
If you want the source code to the Java virtual machine (JVM) for Java5, it is available; but, not under an open source license. The first "open source" copy of Java was released with "Java 6". If you want Java5 source code, you needed to sign up for a "Java Researcher License Agreement" which provided you access to the source code for the JVM for (at least Java5). Having the source code of the JVM is completely unnecessary in writing code for the Java5 environment.
If you want the source code for the Java Language Specification for Java5, it is a text document (typically published as a book or on-line set of web pages). While it might allow you to understand if a compiler should complain with an error under certain circumstances, again it is not necessary to write a program for the Java5 environment.
If you want the Java5 compiler, it can be downloaded in the oracle archives of old releases of the Java development toolkit. If you want write a program for Java5, downloading and using this offering is generally best-practice for developing Java5 programs. Alternatively you may configured a compatible compatible compiler (Java6 / Java7) to emit Java5 code.
If you want the Java5 language libraries, they are included with the Java5 development kit. The Java6 and Java7 development kit offerings provide language libraries that go to great efforts to be compatible with Java5 source code; however, newer libraries also include newer features and operations which a stock Java5 virtual machine will not be able to reference. Again, there are techniques to safely use a backwards-compatible version of Java (6/7); however, one doesn't need to apply any extra care if they base their development off a Java5 development kit. The "source code" for the language libraries was included in the source code for the JVM under the Java Research License Agreement, to the degree that SUN was allowed to include such source code.
While SUN has licensed a number of technologies from other companies in a manner where they can be freely distributed with Java5, SUN did not necessarily own all of the technologies in Java5 outright. As such, even under the Java Researcher License Agreement, some of the source code is not available (although the compiled libraries are). Open source projects (like OpenJDK) were quick to implement these missing "holes" with open-source libraries to get a fully functional open-source Java stack; but, that is Java6+ (not Java5).
Java 1.5 is not open source. Quoting Wikipedia:
On November 13, 2006, Sun released much of Java as free and open source software, (FOSS), under the terms of the GNU General Public License (GPL). On May 8, 2007, Sun finished the process, making all of Java's core code available under free software/open-source distribution terms, aside from a small portion of code to which Sun did not hold the copyright.
As far as I can remember it was possible to get the source code for research purposes (our university had access to the source code with a special agreement with Sun) but I don't think that it will be possible to get it from Oracle.
Before the open sourcing there were several free implementation of the JVM and of the core classes. Look at http://en.wikipedia.org/wiki/Free_Java_implementations for examples.
visit the
oracle archive
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I am using an LGPL library in my code. For my needs, I need to modify the code in the library.
How do I mark the jar file that it contains modified code? Some txt file in the jar? In that case, what do I write in the txt file?
I will include in the license agreement that we are distributing a modified version of the jar, but my question is about marking the jar itself.
The short answer: Avoid the issue
If you have fixed a bug, or added a feature why not submit it back to the original authors by way of a patch? If they accept it, the next version of the library will include your fixes and you won't need to worry about shipping a modified library! Sharing your changes/improvements to the library is the essence of the license, temporarily using a slightly modified version of the library while you are waiting for your submitted improvements is fairly common practice (see stuff about vendor branches). Becoming part of the development community means you are no longer shipping a 'modified' version of the library, but actively contributing your improvements to the original library for the common good.
The long answer: LGPL Version 3.0
From version 3.0 of the LGPL itself:
Conveying Modified Versions.
If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:
a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.
As long as you comply with the rest of the license text, you don't necessarily need to 'mark' the jar itself, with a text file or otherwise. For compilation reasons, you could follow the suggestion of extraneon and use a slightly different jar name. You could use a vendor branch or something to maintain the differences between your modifications and the original library. Here you are 'forking' the project, creating your own derivative work - the essence here is to share your changes and improvements to the source with the world.
The long answer: LGPL Version 2.1
From version 2.1 of the LGPL itself:
You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.
(For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.)
In essence you must say: Hey here is library 'foo', a modified version of library 'bar', here you can use my version of library 'foo' - it too is available under LGPL2.1. The prominent notices are also usually performed at the beginning of your modified source files in the LGPL license comment block. Again your are forking the library.
Give the jar a different name. The classes inside will have the same names, so code depending on it won't have a problem finding it (if the new jar is on the classpath).
It's of course always wise to document your changes by adding some info in the manifest file, and perhaps also a changelog file in the jar itself.
I have made a java project and want to deliver it to a client but I don't want to deliver it as a jar file as the client can see the source code easily by unpacking the jar file.
How can I pack my java project so client cannot look at the source code or cannot change the source code?
One more thing, Can I integrate a key functionality so that client can only access that software by first registering it with the key provided by me?
Second, can I integrate another functionality through which the software can run only on a single machine through that key?
Remember, the software should still have the cross-platform functionality and if it is not possible then how can I made it for Debian Linux as I have made it on Windows.
To your first point. Why not only jar up the class files? These are in byte code so the client will not be able to view the source.
As to providing a key. This can be done and there are libraries that allow this, but be careful as , to my knowledge at least, there has yet to be developed a DRM system that hasn't been cracked. and most users do not like software restricting what they can do. The same point applies to your third question.
Obfuscators
There are some simple things you can do to make it a bit difficult for a client to get hold of your source code and to enforce per-host (etcetera) licensing. For example, obfuscators make it harder to reverse engineer bytecode files, and license managers support a range of restrictions based on the "keys" that you generate and supply.
The problem is that none of these protect you against someone who is determined to subvert the restrictions are trying to impose. For example, no obfuscator can prevent someone figuring out where your code calls a license manager, and once they know that they can modify the code to subvert any license checking.
Short of locking down the entire execution platform (e.g. turning of the client's ability to run debuggers, read physical devices and so on), there is nothing you can do about this.
A more viable strategy is to include appropriate protections in the software license that you require the client to sign. And accept that there is a risk that you may need to take clients to court if they willfully violate the license agreement.
I'm searching for a free EDI to XML converter in Java.
I need to convert EDI 940 to xml and convert XML to EDI 945. The catch is that this will be used for a commercial project, I've found some projects on sourceforge but they are under GNU General Public License which if I read it correctly means I would need to pay to use it for a commercial project. Any links are appreciated. Thanks.
GPL allows you to sell copies of your appliaction but you have to give access to your source code and anyone that purchased a copy is free to give the software away for free. Depending on your business this might not really be a problem. Imho "closed source" for commercial projects is overrated, there are several examples of companies that do well with open source projects.
Another point is how you include the GPL software in your project. If you do not link to the software directly you also do not need to make your software GPL (at least this is my understanding; you would need to verify this properly once you know how to use the GPL software).
Maybe more problematic is if you have to use other libraries that are not GPL compatible, system libraries on the other hand are not really a problem (so called "system library exception").
More information on GPL is here.
If you distribute your application to users, then the GPL would require you also make available your source.