www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: MyFaces: copyright question re javadoc and JSR specs
Date Tue, 22 Nov 2005 12:34:12 GMT

On Nov 21, 2005, at 1:31 AM, Simon Kitching wrote:

> Hi All,
>
> I'd like opinions on a copyright issue for the Apache MyFaces project,
> which is an implementation of the Sun Java JSR127 specification for
> "JavaServer Faces", aka JSF.
>
> Currently none of the JSF API classes (interfaces/abstract classes) as
> implemented by the MyFaces project have any javadoc user documentation
> in them. I understand that this is due to Sun's copyright over the
> actual specification and their refusal to allow that text to appear in
> alternative implementations.

Right - you can't copy sun's copyrighted javadoc.  It's an issue  
that's been raised at the JCP EC level but it's been very difficult  
to make any progress.  It's not really clear why - the base fear  
seems to be that someone will create an alternative spec for a given  
technology that competes with Sun.  Not very rational, but I don't  
think other EC members feel strongly enough to really make an issue  
about it.

>
> This sucks very much, and clearly shows how little Sun understands  
> open
> source.

Indeed.

>
> However it sucks even more that the JSF classes distributed by MyFaces
> don't have any javadoc and users must continually reference the
> Sun-provided javadoc files from the Reference Implementation for the
> actual usage details.

You can do javadoc - you just can't copy Sun's.

>
> As *implementing* the spec is legal, I would expect that deriving
> javadoc from the code (rather than from the spec) would also be legal.
> Of course the result is going to be very similar as the code was  
> written
> by referencing the specification, and would thus be almost as  
> useful for
> MyFaces users as the original spec docs.

You are free to create javadoc for your implementation.  I personally  
wouldn't bother for java.* classes, but rather point back to the spec  
javadoc, but that's me.

>
> I've posted essentially this same query to the MyFaces list, and the
> feeling seems to be that they are happy to add javadoc to the MyFaces
> API classes where the submitter (eg me) has explicitly derived the  
> docs
> from the code rather than the spec.

That's fine - if you are writing original javadoc, you are free to  
add that to your implementation.


>
> Here's a proposed disclaimer that could be appended to the class  
> javadoc
> for each API class:
>
> /**
>   * ....docs derived from the code...
>   * <p>
>   * <i>Disclaimer</i><br>
>   * The official definition for the behaviour of this class is the JSF
>   * specification and for legal reasons the specification cannot be
>   * replicated here. Any javadoc present on this class therefore
>   * describes the current implementation rather than the officially
>   * required behaviour, though this class has been verified
>   * as complying with the specification (using the Sun TCK).
>   * <p>
>   * @author ....
>   * @version ...
>   */
>
>
> Opinions?
>

I think that's overkill, actually.  I think you could just also add a  
link to Sun's online version... does that work?

geir

>
> Regards,
>
>
> Simon
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only.  Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF.  See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not 
constitute legal advice, and do not necessarily reflect the opinions 
and policies of the ASF.  See <http://www.apache.org/licenses/> for 
official ASF policies and documents. 
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message