SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Slackware will not be allowed to keep shipping JRE and JDK the way it used to (re-packaging the official binaries). But there are two alternatives to that: either Slackware will ship OpenJDK instead (compiled from source) or it will ship only a jre.SlackBuild and jdk.SlackBuild script which enables you, the Slackware user, to package and install the official Java binaries painlessly.
SlackBuild then please by all means.
I do however find this clause of the Oracle license interesting in this matter:
3. RESTRICTIONS. Software is copyrighted. Title to Software and all associated intellectual property rights is retained by Oracle and/or its licensors. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. You acknowledge that the Software is developed for general use in a variety of information management applications; it is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use the Software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Oracle or its licensors is granted under this Agreement. Additional restrictions for developers and/or publishers licenses are set forth in the Supplemental License Terms.
Read the entire license for usage several times. There is NOTHING in the license regarding redistribution that I could find regarding redistribution or repackaging that Slackware or any Linux, Windows, or MAC doesn't already abide by.
C. LICENSE TO DISTRIBUTE SOFTWARE. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including, but not limited to the Java Technology Restrictions of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that: (a) is a complete, unmodified reproduction of this Agreement; or (b) protects Oracle's interests consistent with the terms contained in this Agreement and that includes the notice set forth in Section G, and (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software.
...which bring me back to the original post I made. As long as the complete package is provided with the licenses and documentation originally provided, it's legal, and Oracle seems to be wanting to play nice with it's licensing.
I understand the need to do a SlackBuild, but because the license is clear cut. As long as the original software is intact for it's purpose and includes all documentation articles, it doesn't make a difference if you use a .sh, .rpm, .deb, or .txz to apply it to your redistribution.
Honestly, no offense but I smell some serious bullsh*t in regards to wanting to abandon the Oracle implementation of JDK for the open source derivative, and a premature jumping of the gun by Debian and others wanting to entice Fear, Unrest, and Decent (FUD).
I wouldn't be adverse to dropping Oracle Java from Slackware if Oracle get any weirder.
You should not trust proprietary software. You never know when are the vendors going to take weird decisions and change their licensing conditions without a warning. If you base your Java computing on Oracle's JRE, you might discover that Oracle decides to start charging a fee, changes distribution terms and makes your life impossible. Use free (as in speech) software and this will be less a problem for you!!
I might swap to OpenJDK to see how it works with Minecraft and a client I use for Freechess.org.
Minecraft is said to work flawlessly, with just a 25% slowdown in load times and a slightly lower frame rate.
The only app I use Java for right now is a thermodynamic cycles calculation program that works fine on OpenJDK too, so if Oracle's implementation is dropped, I won't see any difference. Corporative users, however, will prefer to use Oracle's stuff as it is more reliable.
As long as the complete package is provided with the licenses and documentation originally provided, it's legal, and Oracle seems to be wanting to play nice with it's licensing.
Yes, you can provide Java with your software provided you abide by the terms and conditions of Java binary code license.
Can I distribute Java Development Kit (JDK) along with Java Runtime Environment (JRE) on the same CD-Rom?
Yes, provided that you abide by the terms and conditions of the JDK's binary code license.
Can we provide Java on a CD to ensure that people who do not have internet can install it directly from the CD?
You may make Java available to users within your organization on a CD. And you may distribute Java bundled with your application to users outside of your organization. You may not distribute Java alone on a CD.
However, it seems to me that when they refer to "my software", they are refering to software produced by me and that needs Java to work.
"Programs" means Java technology applets and applications intended to run on the Java Platform, Standard Edition platform on Java-enabled General Purpose Desktop Computers and Servers.
Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs
In other words:
-- Slackware.inc cannot put the JRE package in the mirror.
-- Slackware.inc cannot distribute the package in the optic media.
Workaround: Make a dummy Java based application (i.e: an app that prints "Hello, Oracle sucks") and include it with the package. This way, your JRE distribution would be classified as "bundled with your Program".
Why this workaround does not work: because distribution terms allows you to distribute Java Runtime Environment to run YOUR programs, so you would only be allowed to run the dummy app and nothing else...
This is a damned headache. This is why I encourage everybody who does not care about running an implementation or another to use the free alternative.
Last edited by BlackRider; 08-29-2011 at 03:45 PM.
I didn't know that there was drama with ION3, but the example that came to my mind was XFree86.
ION3's developer released his window manager under a non-free license that enforced distributors to always provide the latest version (or to pop-up warn the user if the version was not the latest) and banned any modification or patch that was not requested by each user. Of course, long term support distributions did not like the idea of upgrading the package every week or having to warn the user with pop-ups because their package was two weeks old, all because the developer had licensed the software under this funny terms.
ION3's license was simply retarded. Basically a prime example of a license that just can not work under any regards.
I forgot exactly what all the drama between X.Org and Xfree86 was all about, but I think it was how the developers were given access to the CVS or something and too many patches required by vendors, and lack of progress as a whole from restrictive licensing (if anyone can validate this as what happened).
Ugh, how did Ion3 became relevant to java escapes me. In defense of the Ion3 developer, the way Debian treated his software was more retarted than the modified version of the LGPL he came up with, in order to protect himself and his sanity .
The ION3 and XFree86 incidents were only referenced as to why they happened and how the same is happening with Java. However the Java situation only has surfaced because OpenJDK has now been fronted by Oracle as it's open source derrivative of it main product and they are launching a new license with version 7 and everyone is in a panic because they think they can't use a system built package.
But if you read the new license especially the parts about redistribution and such, all they ask is the documentation and license files as well as the whole of the package remain intact for the redistribution. There is nothing specifically mentioned about the method or means of the redistribution, only things regarding package integrity.
I do however find this clause of the Oracle license interesting in this matter:
That little section is for countries like Australia where we have reverse engineering laws covering software products that become non-supported by the vendor.
Essentially if you produce a software product that does XYZ and then you stop selling it and cease providing updates for it then once it becomes difficult or impossible to get the product to run then it becomes legal to reverse engineer the software in order to modify it so it runs as originally intended, despite any license restriction that may exist.
This wont apply to the java case as :-
1) The old java still works
2) They have directed users to a new product that does the same thing
BTW most distributions have been defaulting to OpenJDK as their Java implemention for a while now. But most/all have Oracle's one available as well.
It is really a shame that Oracle have gone down this route and hence forced distros to abandon them because the Sun/Oracle Java implementation is better performance wise and in terms of having less bugs. However it is not so much better that they will be able to force users to jump through hoops and download manually, whilst still retaining market share. Most users will simply stick with the implementation provided by their distro.
In all honesty, for my own part I'll probably stick with the Oracle implementation for a while because 1. Minecrack plays more smoothly and 2. It works much better in my browser (and I'm forced to use Java by one of my banks).
Last edited by ruario; 08-30-2011 at 06:56 AM.
Reason: removed redundant word
I'm probably about the only person here that regularly references the (IBM) Principles of Ops. But Fortran ???. Erk - Assembler; nothing else.
O.K., nowadays also a bit of C for the zLinux kernel side of things.