geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [JavaMail] re-engineering of JavaMail from specs?
Date Tue, 12 Aug 2003 23:53:21 GMT

On Tuesday, Aug 12, 2003, at 23:04 Europe/London, Danny Angus wrote:

> Alex,
> (BTW are you in Europe?)

Yes, in glorious Milton Keynes. Home of the concrete cows. No, I don't 
know why either ...

>> Yes, but the question I have is whether I can legally read Sun's API
>> and then write an implementation of it. I'm not going to touch the
>> source code, but there isn't any way of creating a JavaMail
>> implementation using the PDF Spec alone; it simply doesn't provide
>> enough code.
> Well if others have typed in interfaces from the javadocs and not been 
> "gone
> after" I'd suggest that reading the javadocs is OK.
> In addition it would be pretty much 100% impossible otherwise.
> Read the licence and pay attention to the no reverse engineering bits..
> At the end of the day if you're really worried someone can ask the 
> Board to
> get legal opinion.

The license for the JavaMail spec is at
(although this is for the 1.2 spec, presumably the same applies to the 
1.3 license)

It seems to suggest that the spec is available for clean-room 
reimplementations of the API, provided that you implement the classes 
required by the spec, that you don't add/remove 
classes/interfaces/methods to it, and that passes the tests provided by 

Obviously it says that it does not derive from any Sun source code or 
binary code, but that's something I'm being careful to avoid anyway.

It's a bit unclear as to what it means by 'specification' anyway; 
whether it's just the document or whether it's the document-and-APIs. 
I'd argue that if it's the former then it would be impossible to do so.

>> I was also working on it in stages; first, get the abstract
>> classes/interfaces together for the API,
> Don't forget that it's with JavaMail theres also concrete classes, 
> like the
> oft mentioned MimeMessage, which are part of the API too.
> Everything in javax.mail.* is part of the API.

Yes, I should have included the concrete ones as well.

>> But at a first cut, I was looking at JavaMail in itself, without any
>> extensions to that API.
> It'd be a hell of a lot of work, but if you do it properly I'm sure an 
> version of javaMail would be popular.

Somehow, I never go for the easy jobs ...

>> This is my problem; how can I implement the JavaMail API in a way that
>> is legally acceptable by the ASF? Is taking the signatures from the 
>> API
>> documentation legally the right way to go? Otherwise I don't see how
>> this would be possible.
> Yeah, agreed, I guess we ought to get some claification, have you read 
> the
> licence recently? does it give you any hints?

Read it above, think it's possible. But would like ASF legal advice on 
this. Also, I don't know how to get hold of the testing kits; is this 
something that Apache can do formally through Sun? And/or submit it for 
formal testing?

>> Obviously, I'm not using reverse engineering or using the source to do
>> the implementation; on the other hand, I'm also not bothering with
>> JavaDoc since I'm assuming that people know how to use it and it's 
>> just
>> the implementation that's required :-)
> Right, the trouble is that for a re-creation of javaMail to make any 
> sense
> it has to be a runtime replacement for javax.mail.*
> Therefore it has to duplicate every single class and method sig. 
> exactly.
> And you can't ever depend upon any classes in Sun's distribution 
> because
> that'd re-introduce precisely the licence dependance you are trying to
> avoid.

Presumably, public and protected are important; private and friendly 
are not?

>> I also belive that whilst they are documented, the com.sun
>> implementations do not form part of the API and therefore shouldn't be
>> cloned. I don't know if that's a right decision or not.
> Yes, the com.sun classes are the Reference Implementation (RI) of the
> interfaces and abstract classes which are intended to be implemented by
> implementations ;-) . the javax.mail ones are not. The scope of this 
> project
> (and to some extent of James) *is* the com.sun classes, javax.mail is 
> not in
> the scope of James and may not even be within the scope of this effort.

True, but until a set of javax.mail interfaces exist and can be 
used/redistributed, it's going to make the implementation a lot more 
difficult ;-)

Any legal thoughts on this?


View raw message