Classpath licensing (Re: About the java.util.zip project)
I am copying this to the jazzlib and classpath MLs to get some other peoples' opinions on the Classpath license and how it should apply in a case like this. My name is Dongku, Kim. I am a Japanese developer. Hi My company makes commercial software. And, I work to make a module which makes a zip file from files by Java. So, I want to use your library. But I read the license at the homepage(http://jazzlib.sourceforge.net/). I think the license on your homepage means that I can use the library freely and I dont need to obey the GPL license No, the license says you MUST obey the GPL with one special exception ... if I use the library only by means of called the library to make a executable. If you combine jazzlib with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice. So you can use jazzlib in your program without changing the license of your commercial software. For sure, if you can give me an answer for some questions, I am very happy for it. 1) If I use your library without change(source code) to make a commercial ziputility, should I open my ziputility source code? The license says you must combine with independent modules. If you write a commercial zip utility I am not sure that this other code will be an independent module. 2) If I should open my source code, is there other method not to do this? For example, we can pay for the license. No, I doubt this is possible. 3) If I use your library without change(source code) to make a commercial ziputility, what I should do not to violate your license? I am not sure how to answer that, perhaps another developer can answer this question? -- John Leuner [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests, Documentation
Hi,
On Sat, 2003-11-22 at 18:21, Sascha Brawer wrote:
having read quite a bit of Classpath code, I'd like to express two wishes.
First, please write more test cases. [..]
Second, please write understandable documentation [...]
In other words, I think that we really need to improve the quality of our
code. Building a sound foundation for others is not the same as some fun
week-end hack.
Thanks for raising these issues. Between you and Dalibor policing the
code so thoroughly I feel less and less need to play the bad evil
maintainer :)
I agree with you completely. But I feel we are going in the right
direction. Although I admit that creating more tests and documentation
is a slow process. There are a couple of things we should do to make
this easier (and more fun!):
- More peer code-review. It is really good to see that people post their
patches to the mailing list so others can comment on it. We probably
need a new list for it (classpath-patches) and a good set of rules of
who and what kind of changes can be approved/denied or asked for
improvements. I personally find peer review discussions very valuable,
even though people often point out my mistaken assumptions.
- Always adding mauve tests for new code or patches. Mauve tests are
extremely simple to write and give you immediate feedback. The amount
of tests is also big enough to catch things you might not have thought
would be changed by your patch. But as you point out there are areas
with not very much or even no tests at all.
A few problems with mauve currently are:
- It is a pain to setup. We need to get rid of the auto* magic.
- It is a bit to fragile. A hanging test or no network can stop
everything. I have a simple shell/bash based wrapper to work around
that.
- There are still to many false positives.
- Mauve proper doesn't have a good XFAILs mechanism.
gcj does have something like that (although it doesn't detect when a
XFAIL turns into a XPASS).
All the above makes spotting regressions not easy (some of the
recent network/url/connection breakage should have been spotted much
earlier).
With a few local patches I currently get for Classpath+Kissme (x86):
182 of 10352 tests failed
This includes the patch for GregorianCalendar and merging in
URLConnection and gnu/java/net/protocol from libgcj. Some outstanding
java.awt.geom patches and the recent Hashtable fixes that are not yet
checked in.
I had to disabling some tests (see attached mauve-kissme file).
Most of the remaining failures are some char-encoding issues,
bugs related to relection, java.text.RuleBasedCollator (for which
I believe we still have a patch pending) and some
RoundRectangle2D.intersects failures. Plus a couple of smaller test
failures.
- Autobuild Classpath, VMs, Mauve and applications regularly.
Tom Tromey recently posted a list of free software projects that he
regularly compiles against gcj and for which he runs the tests-suites.
It would be good to create a classpath-testresults mailinglist and
post the from a couple of different architectures, compilers, VMs,
etc. Any volunteers to adapt Tom his scripts and to run this
regularly?
- Automatic documentation generation. When updates to documentation are
immediately visible people get much more satisfaction from writing it.
Current problems are that gjdoc has not had an official release so you
have to build from CVS. We need a way to add the correct copyright
notice and distribution terms to each page (note that since we also
have non-Classpath classes in CVS now in the external directory this
is a bit tricky to get correct. gjdoc (at least my setup) does not
handle all HTML entities correctly. See
https://savannah.gnu.org/bugs/?func=detailbugbug_id=4823group_id=85
And as far as I know it doesn't handle embedded images yet.
Arnaud is currently testing gjdoc and kaffe.
Although I hope we can fix/use gjdoc it would be nice to have a
volunteer to check out SinjDoc from the Flex project.
http://cscott.net/Projects/GJ/#sinjdoc
- Does it work with gcj/kaffe?
- Does it produce correct documentation for all of Classpath?
One additional documentation task would be to write a good book/article
on working with GNU Classpath and/or gcj/kaffe for free software
writers. This should be an overview of what is available now, how to
install it, writing hello world and more cookbook like examples with a
overview of the current packages available (when to use what for which
kind of task). Most of the articles/books about writing programs in the
java programming language and/or libraries are about proprietary systems
which make all kind of assumptions that are not appropriate when working
on a free system.
I want to do it all, but I am terribly slow :{
So volunteers for all of the above tasks are welcome!
I am currently concentrating on cleaning up Mauve and preparing the 0.07
snapshot for next week.
Cheers,
Mark
Re: Tests, Documentation
Hi, On Sun, 2003-11-23 at 13:42, Patrik Reali wrote: I completely agree and support your wishes! In fact, it would be nice if the whole classpath and its documentation (javadoc) would be rebuilt on a regular base and offered through the website. It has to be hosted on something different then www.gnu.org website for now. After the compromise a few months ago they are a bit more paranoid about allowing automatic uploads/updates of files on the server. There is a new system in place now to make releases of packages on ftp.gnu.org easier so I can ask again if we can get some sort of automatic upload of the generated HTML pages to www.gnu.org, but it would be nice if we already have something in place that works somewhere else. Would someone be willing to try to set that up? Could someone host the auto-generated documentation for now? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath licensing (Re: About the java.util.zip project)
Hi, On Sun, 2003-11-23 at 13:48, John Leuner wrote: I am copying this to the jazzlib and classpath MLs to get some other peoples' opinions on the Classpath license and how it should apply in a case like this. Best is to direct such questions to [EMAIL PROTECTED] The FSF is the official copyright holder of Classpath and sets the distribution terms. My company makes commercial software. And, I work to make a module which makes a zip file from files by Java. So, I want to use your library. But I read the license at the homepage(http://jazzlib.sourceforge.net/). I think the license on your homepage means that I can use the library freely and I dont need to obey the GPL license No, the license says you MUST obey the GPL with one special exception ... if I use the library only by means of called the library to make a executable. If you combine jazzlib with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice. So you can use jazzlib in your program without changing the license of your commercial software. I believe John his interpretation is correct, but see below. For sure, if you can give me an answer for some questions, I am very happy for it. 1) If I use your library without change(source code) to make a commercial ziputility, should I open my ziputility source code? The license says you must combine with independent modules. If you write a commercial zip utility I am not sure that this other code will be an independent module. Best is to write with a clear example of how you plan do this and what the distribution terms of the larger work are to [EMAIL PROTECTED] so they can give advise on what is and isn't considered an independent module. 2) If I should open my source code, is there other method not to do this? For example, we can pay for the license. No, I doubt this is possible. The FSF does sometimes make exceptions as long as the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally can be guaranteed. You should contact [EMAIL PROTECTED] if you think you can satisfy those goals, but compliance with the current GNU Classpath (jazzlib) distribution terms is problematic. 3) If I use your library without change(source code) to make a commercial ziputility, what I should do not to violate your license? I am not sure how to answer that, perhaps another developer can answer this question? The FSF has a GPL-compliance lab which offers consulting services for companies who are working to develop products that incorporate Free Software so that they can do so in ways that comply with the terms of the GPL and other Free Software licenses. If you are interested in this service, please write a separate message to [EMAIL PROTECTED]. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Tests, Documentation
Mark Would someone be willing to try to set that up? Mark Could someone host the auto-generated documentation for now? Last time I ran javadoc on classpath, I got tons and tons of errors. Do we still get that? I could set things up to post the pages to gcc.gnu.org nightly, just like we do for the classpath comparison. This could be expedited if somebody sent a simple script to generate the pages. Is gjdoc ready for this sort of work? Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Two methods for NumberFormat
Guilhem == Guilhem Lavaux [EMAIL PROTECTED] writes: Guilhem I am continuing the series of patches with that one, it adds two Guilhem methods to NumberFormat: getIntegerInstance() and Guilhem getIntegerInstance(Locale). They have to be implemented according to Guilhem Java 1.4. Guilhem + /** Guilhem + * This method returns an integer formatting and parsing class for the Guilhem + * default locale. This will be a concrete subclass of codeNumberFormat/code, Guilhem + * but the actual class returned is dependent on the locale. Guilhem + * Guilhem + * @return An instance of an integer number formatter for the default locale. Guilhem + */ I think the javadoc for the new methods should include @since 1.4. We do this in other places. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [PATCH] Field position attribute handling
Mark Wielaard wrote: Hi, On Wed, 2003-11-19 at 02:14, Dalibor Topic wrote: The documentation and code don't match up now. My Class Library book seems to indicate that it actually is instanceof, thought in most cases your code comparing the actual Class seems more correct. It's the recommended way of doing equals() if you want to avoid symmetry bugs. See PRAXIS 12 in Peter Haggar's Practical Java, or ยง5.1, p 119 in Java 2 performance and idion guide by craig lahrmann rhett guthrie, or Effective Java by Joshua Bloch. Using instanceof is a bad idea because it allows for symmetry bugs: I know. But that wasn't the point. If you change to code then you must also update the documentation. O.K., I just wans;t very sure about a non-ambigous wording. How about the attached patch? 2003-11-23 Dalibor Topic [EMAIL PROTECTED] * java/text/FieldPosition.java (equals): Fixed comment. The rest follows recommendations from Joshua Bloch on writing good hashCode methods. It would be nice if we had something about the right way (tm) of writing the standard clone(), toString(), hashCode() and equals() in the Hackers Guide. (hint...) I see. I'll try to come up with something based on what I've seen on the web and Bloch's book. If two objects are not equal, they should have different hashCodes. field_attribute is checked in the equality test, so it should play a role in hashCode calculation as well. Should yes, but not must. I was just wondering whether or not the field_attribute really matters since that field and field_id indicate the same property. Having cheap hashCode() methods is a good thing and IMHO field_attribute does not make the hashCode() more specific. But if you think otherwise then please do it as you have it now. True. I'll write some test code, and may post another patch that removes it based on what I find. cheers, dalibor topic Index: java/text/FieldPosition.java === RCS file: /cvsroot/classpath/classpath/java/text/FieldPosition.java,v retrieving revision 1.6 diff -u -r1.6 FieldPosition.java --- java/text/FieldPosition.java19 Nov 2003 17:41:21 - 1.6 +++ java/text/FieldPosition.java23 Nov 2003 20:34:53 - @@ -168,7 +168,7 @@ * p * ul * liThe specified object is not codenull/code. - * liThe specified object is an instance of codeFieldPosition/code. + * liThe specified object has the same class as this object. * liThe specified object has the same field identifier, field attribute * and beginning and ending index as this object. * /ul ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Mark Wielaard wrote: Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. I am not expert enough for a review ;) But here the results: http://gcc.gnu.org/ml/gcc-testresults/2003-11/msg00990.html CHeers, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
