qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: SASL - Sun Community Source Licence for JSR28
Date Thu, 08 Feb 2007 15:32:46 GMT
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.   

> 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 <cliffschmidt@gmail.com> wrote:
> > On 2/7/07, Daniel Kulp <daniel.kulp@iona.com> 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
daniel.kulp@iona.com

Mime
View raw message