License
in [Java Help]
|
Prev: how to enlarger Java heap size?
Next: JTable: how to change properties of a component located in a cell
From: John Leonard on 19 Sep 2009 17:00 (replying to my own message - as a follow-up) If I use GPL'd code in a program, I must release the program under GPL license as well. Many (if not all) API samples provided by Sun carry some form of GPL license. If I use these API's, therefore, I must either: a) Release what I develop under the GPL or b) Devise my own means of accessing the API, which is probably hard to do. Sun provides these samples (I think) to make it easier to learn to program the API's. In order to promote Java development. Are they going to impose a condition that you can only use them if you publish under the GPL? I'm grateful to everyone who has responded to my question, even the preposterous responses. But, I believe that these notices are a mattress tag, i.e. a threatening legal notice seen by the public but, in fact, only intended for some. I don't know who the intended audience of these notices might be. Perhaps publishers who would include these files in a book or web site without proper attribution. But I don't believe that Sun is saying to the world, in effect, "If you want to program any of these technologies, and you use the sample code we provide in order to help you do it, then whatever you produce must also be licensed under the GPL." If they were, what effect would that have on Commercial development, for instance? John L
From: Peter Duniho on 19 Sep 2009 17:28 On Sat, 19 Sep 2009 14:00:29 -0700, John Leonard <john.leonard.2010(a)gmail.com> wrote: > [...] > But I don't believe that Sun is saying to the world, in effect, "If > you want to program any of these technologies, and you use the sample > code we provide in order to help you do it, then whatever you produce > must also be licensed under the GPL." > > If they were, what effect would that have on Commercial development, > for instance? Practically none. Commercial software can be and is easily be written without copying-and-pasting Sun's sample code. Note also that "whatever you produce" is far too broad without qualification (i.e. limiting it to code produces as a modification of the original code). The only thing required to be licensed under the GPL is code that is a work derivative of the original. At worst, you'd be required to release the code that is a modification of the original. The parts of your code unrelated to the original code are not included. The term "modification" is defined broadly, but not so broadly that every aspect of a software author would be included. Pete
From: Lew on 19 Sep 2009 18:14 John Leonard wrote: >> Many (if not all) API samples provided by Sun carry some form of GPL >> license. The license you cited at the top of the thread had dual licensing - CDDL and GPL with the classpath extension. It explicitly gives you the choice of using either license or continuing the dual license scheme with your modifications. >> If I use these API's, therefore, I must either: >> >> Release what I develop under the GPL or >> Devise my own means of accessing the API, which is probably hard to >> do. Or use the CDDL license. Peter Duniho wrote: > Why would it be hard to do? The sample code exists at least in part for > the specific purpose of illustrating how to use the API. You can take > advantage of the sample code without copying it verbatim. John Leonard wrote: >> Sun provides these samples (I think) to make it easier to learn to >> program the API's. In order to promote Java development. Are they >> going to impose a condition that you can only use them if you publish >> under the GPL? Not based on the license terms that you cited, no. Peter Duniho wrote: > It seems to me that if you copy-and-paste code Sun's applied that > license to, you're subject to the terms of the license. You don't have > to copy-and-paste the code in order to use it, nor in order to make use > of the API less hard (or even easy). John Leonard wrote: >> But, I believe that these notices are a mattress tag, i.e. a >> threatening legal notice seen by the public but, in fact, only >> intended for some. Peter Duniho wrote: > I don't understand the reference to "mattress tag". It's a common > misconception that one would be violating some law by removing the tag; > but the tags clearly state to whom the mattress tag does and does not > apply. The consumer is permitted to remove it, and the language on the > tag actually makes that clear. The only reason anyone thinks otherwise > is that they don't bother to read the whole thing. Therein lies the similarity. > This software license isn't "a threatening legal notice...only intended > for some". It applies to anyone who is using the software in the way > that the license describes is applicable. > > Other than both being legal notices, I fail to see the connection. They are both legal notices that apply to redistributors that naive consumers read and mistakenly think applies to them, causing them to overreact to the erroneously-perceived legal threat in both cases. -- Lew
From: Mike Schilling on 19 Sep 2009 19:18 Martin Gregorie wrote: > On Sat, 19 Sep 2009 12:18:07 -0700, Mike Schilling wrote: > >> John Leonard wrote: >> ? >>> >>> My background includes microcomputer app development going back to >>> the 80's. I have become accustomed to having access to freely >>> usable sample code from manufacturers and the like to get things >>> going when developing for a given platform. Has that changed? >> >> >> It has, and I can't tell you why. Sun is in the same position as >> those manufacturers: they all want you to use their products, and >> giving you some sample code as a starting point encourages that. >> Why they'd make you jump through legal hoops to do so escapes me. > > That doesn't apply to all Sun example code. For example, the code > samples in Appendix B of the JavaMail API Design Specification 1.4 > have no licensing agreements that I can find and the overall > document > licensing doesn't appear to affect study, use or modification of > this > code. Something my company wanted to use (I think it was a Swing example) had the same licensing nonsense attached to it. Again, it was simply an example of how to use an API, something of real value if you can use it as a starting point for your own application, and fairly useless if you can't.
From: Mike Schilling on 19 Sep 2009 19:27
Peter Duniho wrote: > On Sat, 19 Sep 2009 13:20:55 -0700, John B. Matthews > <nospam(a)nospam.invalid> wrote: > >> [...] >>> Modifying the library code itself excludes that exception, leaving >>> the rest of the license to apply in whole. >> >> I'm uncertain. The exception says, "If you modify this library, you >> may extend this exception to your version of the library, but you >> are not obligated to do so." > > But that doesn't mean that the exception applies to modifications of > the library. The exception exists to allow consumers of the library > to use the library without falling under the other requirements of > the license, if _all_ they are doing is linking to it. > > The above text simply means that if you do modify the library, while > you yourself aren't subject to the terms of the exception, you are > _permitted_ to provide the same exception to other consumers of your > modified version. That is, if _those_ consumers don't modify the > library itself, they may use the library via linking without > complying with the other aspects of the license. > > Note that you're not even _required_ to extend the exception to > consumers of your modified version. It's simply allowing you to do > so. > But in any case, the exception doesn't apply if you're modifying the > code. It's applicable only in the scenario where all you do is > link. > >> If I modify the library and extend the exception, I >> am obligated to disclose the modification, but I can still rely on >> the (extended) exception to link independent code that may remain >> proprietary. > > All true. But the OP doesn't appear to be asking about code > independent of the library covered under the license. It appears > that he is specifically concerned with reuse via compilation of code > in the library. I would say that constitutes a modification of the > code, and thus the exception for linking doesn't apply. > The idiotic part of this is that it isn't really a library in the usual sense. It's not code that has value because it provides some functionality; it's code that gives an example of how to use an API, and what it actually does in its unmodified state is (I presume) of no value to anyone. If I write an example for my customers of, for instance, how to write some WSDL using a custom binding we've invented, I don't expect them to read it, master it, and then create clean-room WSDL for their own services. I want them to cut and paste, because 1. That's simpler, so it puts them closer to using the product in a way that's worth money to them. 2. They're more likely to get it right the first time, which makes both them and us happier.. |