Re: Sun and the JCP 2.5
On Wed, 2 Apr 2003, Andrew C. Oliver wrote: Sam, I've gotten rather disappointed with your tactics of late. Folks - can we please try not to 'read into' each others words too much. I'd like to avoid a situations such as say someone posts some NDA'd spec Andrew - it is naught impossible to effectively sue someone for the use information which was made public, say on a list like [EMAIL PROTECTED] And even if one did - you'd have to show it was directly derived. On the same token; if you somehow accidentally receive something which has the banner 'Commercial in confidence' or some other indiciation it may be considered a trade secret by its owner or you could resonably know it was under an NDA - than you need to be just as careful as if you'd signed an NDA. The knife cuts in both directions. To 'label' things - we've instituted the jcp@ list; so that thigns are easy to separate. I think an open JCP list where no NDA material is permitted would be entirely appropriate. Would [EMAIL PROTECTED] not be exactly that sort of forum ? I.e. exactly the community where java related things which affect most, if not all, java projects are normally discussed. If you object to the ASF effectively having certain lists which are not as 'open' and 'public' as you'd like - that is an entirely other matter. And one you are encouraged to dicuss with community@ and [EMAIL PROTECTED] But personally I think that given that we are not a public institution - our interaction with others, such as SUN, in the real world, will always mean that in order to build trust and communicate effective, that certain things will be restricted to members@ or someother well identified body. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun and the JCP 2.5
On 3/04/2003 1:24 Roy T. Fielding wrote: Does anyone know why JBoss isn't being granted the scholarship? I read the Happiness is here today JCP 2.5 announcement (http://java.sun.com/features/2002/10/new_jcp.html) again and it says qualified achedemic, non-profit and opensource members. I am not sure about the announcement text, but I know that the agreement was for nonprofit or academic organizations, or for individuals working on behalf of a nonprofit. JBOSS is none of the above. http://jcp.org/aboutJava/communityprocess/announce/LetterofIntent.html Thanks for clarifying this. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
License compatibility
This question relates to some code in a commons sandbox component. I would have asked this question on licensing@, but I think that is a members-only list. Here's the hypothetical, but I'd like to get some official guidance from the PMC. Assume that there is a piece of C code covered by the Perl Artistic License: http://www.perl.com/pub/a/language/misc/Artistic.html that implements an algorithm like DoubleMetaphone. Now, imagine that a contributor submits a class that is a direct port of this code to Java. The port contains lines of code that are strikingly similar to the original, the class seems to be a verbatim copy of the original making exceptions for the differences between Java and C. Here's the CPAN module: http://search.cpan.org/author/MAURICE/Text-DoubleMetaphone-0.05/DoubleMetaph one.pm Here's the Codec class: http://jakarta.apache.org/commons/sandbox/codec/clover/org/apache/commons/co dec/language/DoubleMetaphone.html I discovered the deriviative nature of the work after the class had been added to the CVS repository, and subsequently had some discussions which led me to belive that the Perl Artistic was compatible with the Apache license. Section 3 of the PAL seems relevant, but I am not the individual to be making legal judgement calls on behalf of the ASF. Anybody? Please let me know if I need to remove this from CVS ASAP. PS As a parting shot, I think that porting C code directly to Java is simply a *bad idea*. The implementation in question has a method that is 800+ lines - regardless of the direction, this class needs to be refactored, reimplemented. If PAL is compatible, we'll start from this implementation as a baseline; if PAL is not compatible, we'll start from scratch. I'm neutral. /PS Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
