From: Oskar Liljeblad <oskar@osk.mine.nu>
To: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
Cc: James Williams <james_williams@optusnet.com.au>,
java@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: Attention GCJ devel team
Date: Tue, 23 Apr 2002 07:25:00 -0000 [thread overview]
Message-ID: <20020423124246.GA24351@oskar> (raw)
In-Reply-To: <3CC38926.90804@waitaki.otago.ac.nz>
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)
next prev parent reply other threads:[~2002-04-23 12:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
2002-04-23 18:04 ` Bryce McKinlay
2002-04-23 22:29 James Williams
2002-04-23 22:42 ` Bryce McKinlay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020423124246.GA24351@oskar \
--to=oskar@osk.mine.nu \
--cc=bryce@waitaki.otago.ac.nz \
--cc=gcc@gcc.gnu.org \
--cc=james_williams@optusnet.com.au \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).