www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: MyFaces: copyright question re javadoc and JSR specs
Date Tue, 22 Nov 2005 15:27:02 GMT
I don't know about JSF but for many of the specifications the JavaDoc is
an essential part of the specification itself (as in it helps define the
function). By rolling your own you may introduce subtle differences in
the documentation that lead to additional confusion for users.

I would suggest linking back to the specification and/or Sun's JavaDoc
with a note in the source explaining why.

--
Jeremy

Geir Magnusson Jr. wrote:
> 
> 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
>>
> 


---------------------------------------------------------------------
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