* Re: Attention GCJ devel team @ 2002-04-23 22:29 James Williams 2002-04-23 22:42 ` Bryce McKinlay 0 siblings, 1 reply; 8+ messages in thread From: James Williams @ 2002-04-23 22:29 UTC (permalink / raw) To: java Bryce McKinnley wrote: > Thanks Oskar. I believe we can conclude from this that it is ok to use > automated tools to generate templates for implementing classes from > Javadocs, provided that it is only the member names and signatures that > are being copied and not the documentation itself. > regards > Bryce. For myself I'm not convinced that generating the javadoc would violate any copyright for the following reasons. 1. deprecation is a part of the specification and deprecation is part of the javadoc, so how can the javadoc be excluded? 2. In the license that I agreed to Sun granted me a license for the specification (which includes all of the javadocs) and nowhere within the license does it state that I don't have the freedom to recreate the javadoc. The tool does give you the option to NOT generate the javadoc. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-23 22:29 Attention GCJ devel team James Williams @ 2002-04-23 22:42 ` Bryce McKinlay 0 siblings, 0 replies; 8+ messages in thread From: Bryce McKinlay @ 2002-04-23 22:42 UTC (permalink / raw) To: James Williams; +Cc: java James Williams wrote: >For myself I'm not convinced that generating the javadoc would violate any >copyright for the following reasons. > >1. deprecation is a part of the specification and deprecation is part of >the javadoc, so how can the javadoc be excluded? > The @deprecated tags (and, perhaps, the @since version tags) are a special case. They may be used buy the compiler, so you could argue that they must be reproduced in order to properly implement the API. Thus, I think it is ok to include those. >2. In the license that I agreed to Sun granted me a license for the >specification (which includes all of the javadocs) and nowhere within the >license does it state that I don't have the freedom to recreate the javadoc. > The documentation is Sun's copyrighted work. We use that documentation to produce an implementation of the Java API. However, like any book, we cannot simply copy the contents and pass it off as our own. regards Bryce. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <001e01c1e797$c91c2f30$c47831d2@computer>]
* Re: Attention GCJ devel team [not found] <001e01c1e797$c91c2f30$c47831d2@computer> @ 2002-04-21 22:22 ` Bryce McKinlay 2002-04-22 0:22 ` Nic Ferrier 2002-04-23 7:25 ` Oskar Liljeblad 0 siblings, 2 replies; 8+ messages in thread From: Bryce McKinlay @ 2002-04-21 22:22 UTC (permalink / raw) To: James Williams; +Cc: java, gcc James Williams wrote: >I am currently working on a tool that will generate class stubs complete >with javadoc from javadoc specifications. In your FAQ a person >mentioned that "Considering that new Java APIs come out every week, it's >going to be impossible to track everything." I believe the tool I am >developing may reduce this development challenge for you substantially. > From my perspective the value of this would be that when a new specification >came out, the api converter could be run providing a clean framework >complete with all the new and deprecated api's and then the intergrator >could copy the existing code from the current libgcj implementation into >the new framework. > This sounds like an interesting and useful tool. However, I don't know whether or not we can, from a legal perspective, generate code directly/automatically from Javadocs. I suspect we'd have to ask the FSF legal people whether or not this is safe. regards Bryce. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-21 22:22 ` Bryce McKinlay @ 2002-04-22 0:22 ` Nic Ferrier 2002-04-22 1:27 ` James Williams 2002-04-22 11:03 ` Raif S. Naffah 2002-04-23 7:25 ` Oskar Liljeblad 1 sibling, 2 replies; 8+ messages in thread From: Nic Ferrier @ 2002-04-22 0:22 UTC (permalink / raw) To: Bryce McKinlay; +Cc: James Williams, java, gcc Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes: > James Williams wrote: > > >I am currently working on a tool that will generate class stubs complete > >with javadoc from javadoc specifications. In your FAQ a person > >mentioned that "Considering that new Java APIs come out every week, it's > >going to be impossible to track everything." I believe the tool I am > >developing may reduce this development challenge for you substantially. > > > >From my perspective the value of this would be that when a new specification > >came out, the api converter could be run providing a clean framework > >complete with all the new and deprecated api's and then the intergrator > >could copy the existing code from the current libgcj implementation into > >the new framework. > > > > This sounds like an interesting and useful tool. However, I don't know > whether or not we can, from a legal perspective, generate code > directly/automatically from Javadocs. I suspect we'd have to ask the FSF > legal people whether or not this is safe. We had the same issue with ClasspathX and I think the result was that it's not legal (sun have (c) on the javadoc produced text). But I don't have any copy of an FSF mail so you may as well ask again. However, such a tool would still be useful, just as a monitoring tool. Nic ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-22 0:22 ` Nic Ferrier @ 2002-04-22 1:27 ` James Williams 2002-04-22 11:03 ` Raif S. Naffah 1 sibling, 0 replies; 8+ messages in thread From: James Williams @ 2002-04-22 1:27 UTC (permalink / raw) To: Bryce McKinlay, Nic Ferrier; +Cc: java, gcc Whether to generate the javadoc or not is an option that the user can set at the time of generation. The cool thing about generating the javadoc is that it updates whether or not the method,class etc is deprecated. This is why I'm having trouble with the whole "javadoc is copyrighted" issue because deprecation is part of the specification and part of the javadoc. Either way I will be forwarding the finished source to you guys for eval and if you find it useful then please feel free to use and contribute to it. Thanks for the reply James ----- Original Message ----- From: "Nic Ferrier" <nferrier@tapsellferrier.co.uk> To: "Bryce McKinlay" <bryce@waitaki.otago.ac.nz> Cc: "James Williams" <james_williams@optusnet.com.au>; <java@gcc.gnu.org>; <gcc@gcc.gnu.org> Sent: Monday, April 22, 2002 4:39 PM Subject: Re: Attention GCJ devel team > Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes: > > > James Williams wrote: > > > > >I am currently working on a tool that will generate class stubs complete > > >with javadoc from javadoc specifications. In your FAQ a person > > >mentioned that "Considering that new Java APIs come out every week, it's > > >going to be impossible to track everything." I believe the tool I am > > >developing may reduce this development challenge for you substantially. > > > > > >From my perspective the value of this would be that when a new specification > > >came out, the api converter could be run providing a clean framework > > >complete with all the new and deprecated api's and then the intergrator > > >could copy the existing code from the current libgcj implementation into > > >the new framework. > > > > > > > This sounds like an interesting and useful tool. However, I don't know > > whether or not we can, from a legal perspective, generate code > > directly/automatically from Javadocs. I suspect we'd have to ask the FSF > > legal people whether or not this is safe. > > We had the same issue with ClasspathX and I think the result was that > it's not legal (sun have (c) on the javadoc produced text). > > But I don't have any copy of an FSF mail so you may as well ask again. > > > However, such a tool would still be useful, just as a monitoring tool. > > > Nic > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-22 0:22 ` Nic Ferrier 2002-04-22 1:27 ` James Williams @ 2002-04-22 11:03 ` Raif S. Naffah 1 sibling, 0 replies; 8+ messages in thread From: Raif S. Naffah @ 2002-04-22 11:03 UTC (permalink / raw) To: Bryce McKinlay, Nic Ferrier; +Cc: James Williams, java, gcc did the original poster mean when saying "generate ... from javadoc specifications" a. generate the code from the _output_ of the JavaDoc tool, or b. generate the code from .java files (source code) adorned with JavaDoc tags? if it's the latter would that still be legally challenging? cheers; rsn ----- Original Message ----- From: "Nic Ferrier" <nferrier@tapsellferrier.co.uk> To: "Bryce McKinlay" <bryce@waitaki.otago.ac.nz> Cc: "James Williams" <james_williams@optusnet.com.au>; <java@gcc.gnu.org>; <gcc@gcc.gnu.org> Sent: Monday, April 22, 2002 4:39 PM Subject: Re: Attention GCJ devel team > Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes: > > > James Williams wrote: > > > > >I am currently working on a tool that will generate class stubs complete > > >with javadoc from javadoc specifications. In your FAQ a person > > >mentioned that "Considering that new Java APIs come out every week, it's > > >going to be impossible to track everything." I believe the tool I am > > >developing may reduce this development challenge for you substantially. > > > > > >From my perspective the value of this would be that when a new specification > > >came out, the api converter could be run providing a clean framework > > >complete with all the new and deprecated api's and then the intergrator > > >could copy the existing code from the current libgcj implementation into > > >the new framework. > > > > > > > This sounds like an interesting and useful tool. However, I don't know > > whether or not we can, from a legal perspective, generate code > > directly/automatically from Javadocs. I suspect we'd have to ask the FSF > > legal people whether or not this is safe. > > We had the same issue with ClasspathX and I think the result was that > it's not legal (sun have (c) on the javadoc produced text). > > But I don't have any copy of an FSF mail so you may as well ask again. > > > However, such a tool would still be useful, just as a monitoring tool. > > > Nic > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-21 22:22 ` Bryce McKinlay 2002-04-22 0:22 ` Nic Ferrier @ 2002-04-23 7:25 ` Oskar Liljeblad 2002-04-23 18:04 ` Bryce McKinlay 1 sibling, 1 reply; 8+ messages in thread From: Oskar Liljeblad @ 2002-04-23 7:25 UTC (permalink / raw) To: Bryce McKinlay; +Cc: James Williams, java, gcc On Monday, April 22, 2002 at 15:10, Bryce McKinlay wrote: > >I am currently working on a tool that will generate class stubs complete > >with javadoc from javadoc specifications. In your FAQ a person > >mentioned that "Considering that new Java APIs come out every week, it's > >going to be impossible to track everything." I believe the tool I am > >developing may reduce this development challenge for you substantially. > > > >From my perspective the value of this would be that when a new > >specification came out, the api converter could be run providing a clean > >framework complete with all the new and deprecated api's and then the > >intergrator could copy the existing code from the current libgcj > >implementation into the new framework. > > This sounds like an interesting and useful tool. However, I don't know > whether or not we can, from a legal perspective, generate code > directly/automatically from Javadocs. I suspect we'd have to ask the FSF > legal people whether or not this is safe. I wrote a program similar to what you describe some time ago. It is called DeDoc and can be downloaded from http://freshmeat.net/redir/dedoc/1802/url_tgz/dedoc-0.12.tar.gz. It reads HTML (generated by javadoc from java source files) and writes source files for each class encountered. I don't know if anyone actually uses/used it... The same question came up that time - is it legal to use code automaticly generated from Javadoc [in GPL programs]? I wrote RMS to ask about it, and he forwarded my email to Eben Moglen. I quote from the letters I received: Eben Moglen writes: The act of removing the entity definitions from the documentation and reusing them for reimplementation is the same whether an automated process is used or the copying is done by hand. So if the single question is whether running the DeDoc routine is legally more problematic than doing the work by hand, the answer is no. From the copyright point of view it makes no difference whether the data was compiled by a very automated or less automated process. The larger question is whether the copying that is taking place, no matter how, could conceivably be held infringing. Numerous factors enter into this, including what proportion of the HTML documents are being copied, whether the entity signatures could satisfactorily be characterized as functional rather than expressive, what proportion the signatures bear to the size of the finished work, and even what the identifier names are. Some measures of ordinary prudence should be taken. Where identifier names do not require to be externalized for compatibility with existing library linkages, they should be changed. Where other aspects of the signature are not similarly required, they too should be reconsidered. Before release we should review the code a little more closely to make sure that what could be reinvented rather than copied has been. Here's more from Eben Moglen: OL> The signatures information is the base for about 95% of the output of OL> DeDoc (counting bytes of code.) This may seem much, but know that OL> what DeDoc generates is not usable immediately. It still takes OL> heavy (re)engineering efforts to complete the library which DeDoc OL> provides the code-base for. Once the library is completed, the signatures OL> will probably be less than 2% of the finished work. Then we are not going to worry about the matter for now. The proportion of signature to other HTML input to DeDoc is also probably low, because of the text comprising the rest of the documentation. So our case against an infringement by copying claim is essentially a fair use defense: small amounts of copying from the original document, functional in character, representing a small proportion of our finished work. Under US copyright law this would be a sound position and I am comfortable that we could defend it. Let's be sure to check at the later stages of the project, to be sure that our assumptions turned out to be right. Oskar Liljeblad (oskar@osk.mine.nu) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Attention GCJ devel team 2002-04-23 7:25 ` Oskar Liljeblad @ 2002-04-23 18:04 ` Bryce McKinlay 0 siblings, 0 replies; 8+ messages in thread From: Bryce McKinlay @ 2002-04-23 18:04 UTC (permalink / raw) To: Oskar Liljeblad; +Cc: James Williams, java, gcc Oskar Liljeblad wrote: >I wrote a program similar to what you describe some time ago. It is called >DeDoc and can be downloaded from >http://freshmeat.net/redir/dedoc/1802/url_tgz/dedoc-0.12.tar.gz. >It reads HTML (generated by javadoc from java source files) and writes >source files for each class encountered. I don't know if anyone actually >uses/used it... > >The same question came up that time - is it legal to use code automaticly >generated from Javadoc [in GPL programs]? I wrote RMS to ask about it, >and he forwarded my email to Eben Moglen. I quote from the letters I >received: > Thanks Oskar. I believe we can conclude from this that it is ok to use automated tools to generate templates for implementing classes from Javadocs, provided that it is only the member names and signatures that are being copied and not the documentation itself. regards Bryce. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-04-24 5:29 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-23 22:29 Attention GCJ devel team James Williams 2002-04-23 22:42 ` Bryce McKinlay [not found] <001e01c1e797$c91c2f30$c47831d2@computer> 2002-04-21 22:22 ` Bryce McKinlay 2002-04-22 0:22 ` Nic Ferrier 2002-04-22 1:27 ` James Williams 2002-04-22 11:03 ` Raif S. Naffah 2002-04-23 7:25 ` Oskar Liljeblad 2002-04-23 18:04 ` Bryce McKinlay
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).