And here I was thinking it'd be a quick job to knock up a minimal SASL implementation for 1.4...
Will probably write some sort of wrapper mechanism to choose default 1.5sasl or homebrew 1.4 and sidestep the licencing issue altogether. Hopefully getting mina to talk to this won't be too awkward. Thanks for the advice too. It was quite clarifying to learn about the sun jars under maven, the licences they are under, and how geronimo handled the jms api. Rupert On 2/8/07, Cliff Schmidt <[EMAIL PROTECTED]> wrote:
On 2/8/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > On Thursday 08 February 2007 05:07, Rupert Smith wrote: > > So what to do? Shall I just write a copy of the API from scratch and put it > > under javax.security.sasl in much the same way that geronimo have with the > > JMS API? > > You can go this route, but only if you plan on getting the TCK for JSR28 and > making it pass. The javax.* stuff needs to pass the TCK before it's > releasable. Geronimo goes through a lot of work to validate everything in > geronimo specs before they are released. That is only true if the only available license to get what you need requires you to pass the TCK. However, I recommend that you ask Geir Magnusson (ASF VP for JCP issues, who can be found on the [EMAIL PROTECTED] list) what he recommends. I have strong opinions about Sun's use of copyright law to protect simple interfaces and the misperception that one is bound to some TCK provision that no one has agreed to, but for consistency and diplomacy reasons, I think the handling of this should go through Geir. I will say that, if you just need to use the API to allow *compatibility with an existing implementation*, as opposed to *substitution for an implementation*, there really should be no concerns about copying an interface for that purpose. Cliff > > Or, do I need to write some sort of wrapper API and factory to > > choose between Sun SASL on 1.5 and homebrew SASL on 1.4? > > That's probably the easiest/quickest way to go. Alternatively, just check if > SASL is not available and just point the user at the URL to download it from. > > Dan > > > > > > On 2/8/07, Cliff Schmidt <[EMAIL PROTECTED]> wrote: > > > On 2/7/07, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > > > On Wednesday 07 February 2007 10:26, Rupert Smith wrote: > > > > > I've noticed that recently a lot of Sun API jars have become > > > > > available > > > > > > on > > > > > > > > the Maven repository (Look under http://www.ibiblio.org/maven2/javax/ > > > > > > ). > > > > > > > > This includes the JMS 1.1 API, for which we are currently using the > > > > > > one > > > > > > > > found under org.apache.geronimo.specs. > > > > > > > > Actually, the jar isn't there. Just a pom that if you use it, it says > > > > download it from..... > > > > > > > > > Sun jars under maven have always > > > > > been a bit of a problem because for licencing reasons they couldn't > > > > > be included in the repository. Now it seems that many of them are, > > > > > > presumably > > > > > > > > because of Java itself becoming open sourced? > > > > > > > > I'd like to clear this up a bit.... > > > > > > > > Many of the older Sun jars are appearing in the maven repository > > > > because > > > > > > Sun > > > > > > > itself is having them put there. (Actually, they've setup their own > > > > > > maven > > > > > > > repository as well: https://maven-repository.dev.java.net/repository/ > > > > > > ) The > > > > > > > license on them still doesn't change. The license would prevent > > > > anyone other than Sun from putting them there, but since Sun put it > > > > there, > > > > > > that's > > > > > > > OK. > > > > > > > > For the newer CDDL based code, those can be submitted by anyone so > > > > those > > > > > > are > > > > > > > appearing as well. > > > > > > > > The issue is the older non-cddl based jars (most are BCL) (JMS jar > > > > falls > > > > > > into > > > > > > > this category). Those need to be submitted by Sun. However, BCL > > > > code cannot be shipped with an Apache project anyway. Thus, if > > > > they're > > > > > > uploaded > > > > > > > to maven or not doesn't change the fact that qpid cannot ship it. > > > > > > > > > If it is acceptable, I'd like to submit a request to get this JSR28 > > > > > > jar > > > > > > > > added to the maven repository too, and to use it. > > > > > > > > IANAL, but getting it submitted to the maven repository should be fine > > > > > > (I > > > > > > > think). You would still need legal/Cliff to make sure it's ok to > > > > ship > > > > > > with > > > > > > > the distributions. It's not on the list of accepted licenses: > > > > > > > > http://people.apache.org/~cliffs/3party.html#criteriaandcategories > > > > > > One of the criteria to allow incorporating a third-party component > > > into an ASF distribution is that the license meet the Open Source > > > Definition. The SCSL does not meet the OSD. You might want to check > > > with Sun and make sure they aren't planning on relicensing it under > > > the CDDL. > > > > > > Cliff > > -- > J. Daniel Kulp > Principal Engineer > IONA > P: 781-902-8727 C: 508-380-7194 > [EMAIL PROTECTED] >
