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 ... http://www.askmk.com/placesofinterest/concretecows.html
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 http://java.sun.com/products/javamail/JavaMail-1_2-spec-license.html
(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 Sun.
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 ASFL
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?
Alex.
