classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sun tainting and Javadoc comments.


From: Mark Wielaard
Subject: Re: Sun tainting and Javadoc comments.
Date: Sun, 27 Jun 2004 15:45:30 +0200

Hi,

On Sat, 2004-06-26 at 22:44, James Damour (Suvarov454) wrote:
> As some of you may know, I suffer the painful stigma of having been 
> tainted by reading the Sun Java source code.  As such, I thought that my 
> only way of contributing to FLOSS Java would be as an application 
> developer (i.e. compile and run my Java apps under FLOSS VM's, and feed 
> back bug reports).

May I first say that having free application writers who submit bug
reports is really, really appreciated. I had lots of fun with MegaMek
(even though it doesn't satisfactory run with the free runtimes yet).

> I may be able to fill in missing Javadoc comments in source files.
> 
> However, none of us are certain enough about the licensing involved with 
> all of this, so we decided to check with the FSF, hence this missal to 
> you august Classpath hackers.  We'd like an official review of the 
> issues to determine if a person who has been tainted can write Javadoc 
> comments in source code.  Does is matter how tainted the person is (i.e. 
> I've read the contents of src.jar, but I've never agreed to the SCSL)? 

When working on code for GNU Classpath you should never refer in any way
to any proprietary implementation, or actually care very much about what
any other implementation does (except for what has been published in
public resources such as books about the subject or publicly accessible
web pages describing ways to make our implementation more compatible). 

This is both so you/we are not accused of direct copying, but also since
a lot of the methods/classes are so narrowly defined that a clever
implementation will most likely look a lot like any other implementation
because people expect them to be compatible. In such a case we want each
contributor to be able to clearly say that is certainly not because they
looked or copied any other code (because they never saw it!).

This is not just for the GNU Classpath project, it is a general rule for
any official FSF GNU project (See Keeping Free Software Free):
http://www.gnu.org/prep/standards_2.html#SEC2

The FSF is pretty conservative in these matters. This is mainly just a
simple risk-analysis. If certain actions mean it is easier to keep a GNU
project out of any legal trouble then just do it. We want to make sure
that GNU Classpath is now and will always be Free Software that
developers can trust and feel free to use for whatever purpose.

When documenting the core libraries there is a larger freedom to express
yourself in a new, novel and unique way. When documenting any GNU
Classpath code it is always advisable to actually read how we
implementation things and then explain what it does on a higher level. 

But just like with writing code don't refer to any non-free
documentation about that class or method which you are documenting at
that time. (And if you do find free documentation about parts of the
class library that you want to bundle with GNU Classpath please ask me
or FSF legal for permission first.)

> "No" is, of course, a perfectly acceptable answer; we just thought that 
> we've come up with a clever way for us poor unclean pariahs to take a 
> more active role in supporting FLOSS Java.

Again, creating free software applications, testing with the free
libraries, compilers and runtimes, submitting bugs and writing test
cases for Mauve is all very much needed and appreciated.

You also may want to think about writing higher level documentation. We
are really in need of good high level overviews how to setup and develop
with the free tools. Just a little guide on how you develop and debug in
a non-traditional (but free!) environment with e.g. gcj and gdb would
help a lot of people. Or making an overview of what is really available,
tested and known to be working good enough in GNU Classpath to recommend
to people wanting to make sure their applications written in the java
programming language will now and in the future work with any free
development environment would be great. There are lots of books on what
is available and working with proprietary tools, but those are not that
helpful at the moment for Free Software developers.

All that said I will forward your request to FSF legal to see what they
say.

Cheers,

Mark

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]