Yes, I think that it probably is technically alright to include third-party
code with that license as source code in our SVN, so i guess this isn't a
release blocker. But if feels quite odd to me have the entire Tuscany SDO
API code like this, why couldn't this be the same as our SCA APIs where
we've just coded them up ourselves using the Apache license? Or else have
OSOA release the code themselves? Or donate them to Apache?

  ...ant

On 4/12/07, kelvin goodson <[EMAIL PROTECTED]> wrote:

Re the api files' headers.  I have retraced my steps and found the
following

Treatment of Third-Party Works

   1. The term "third-party work" refers to a work not submitted
   directly to the ASF by the copyright owner or owner's agent.
   2. Do not modify or remove any copyright notices or licenses within
   third-party works.
   3. Do ensure that every third-party work includes its associated
   license, even if that requires adding a copy of the license from the
   third-party download site into the distribution.
   4. Do not add the standard Apache License header to the top of
   third-party source files.
   5. Minor modifications/additions to third-party source files should
   typically be licensed under the same terms as the rest of the rest of the
   third-party source for convenience.
   6. Major modifications/additions to third-party should be dealt with
   on a case-by-case basis by the PMC.


In this document http://www.apache.org/legal/src-headers.html

Cheers, Kelvin.
On 12/04/07, ant elder <[EMAIL PROTECTED]> wrote:
>
> More comments inline...
>
> On 4/12/07, kelvin goodson < [EMAIL PROTECTED]> wrote:
>
> <snip/>
>
> - The src distro has no LICENSE or NOTICE in top level directory (they
> > are there in sdo-api directory)
> >
> > this is the anomaly that I pointed  out in the last release cycle in
> > response to the requirement that each of the archives unpacks into a single
> > root folder -- any commonly named files required to be in the root folder
> > would overwrite one another,  hence their appearance in the next level
> > down.  We can not satisfy both requirements!  Hence for each archive I was
> > considering <common-root>/<specific-distro-root> to be the "root" folder
>
>
> Must all the archives unpack into a single root folder?
>
>
> - The sdo-api src files don't have an Apache License header and include
> > a non-ASF copyright - has this been discussed before, can we do this?
> > This was as it was in M2 and M1.  I followed the established pattern.
> > I beleive this to be correct.
>
>
> That we got away with it in M1 and M2 may have just been an oversight
> which is why I asked if  there had been any discussion about it. I don't
> remember any discussion. This doesn't seem correct to me, the sca-api files
> have the ASF header and not any OSOA copyright, why are the sdo-api's
> different? Didn't we develop all this code in Tuscany? The LICENSE in the
> sdo-api jar says its under ASL. I think these need to be fixed or at least a
> clear explanation found why its ok like this.
>
>
> - There are no SDO artifact jars to review, are the SDO jars going to be
> > installed to the Apache maven repository?
> > The jars are in the binary distribution in the lib folder
>
>
> I think they need to be separate so we can review the exact artifacts
> that will be deployed to the maven repository including all the pom and
> maven-metadata xml files along with the associated checksums and signatures.
>
>
>
> - Is there a reason the bin distro unzips to
> > tuscany-sdo-1.0-incubator-M3 whereas all the other distro's
> > (impl/samples/src) unzip to tuscany-sdo-1.0-incubator-M3/sdo?
> > the binary archive is the result of maven's default "best practice",
> > the other archives are so in order to meet the above referenced requirement
> > to unpack in to a common root directory.  I guess I could add a bin
> > directory to the binary distribution,  but I think for the most part people
> > will be downloading either the binary distro (perhaps with the samples) or
> > the source distros.  It would be odd to bury the binary distro deeper I
> > think,  but your suggestions are very welcome.
>
>
> As above, must all the archives unpack into a single root folder? I
> think some of the reviewers of other IPMC releases have said they actually
> prefer using separate folders.
>
> - I find all the distro's and contents a bit confusing - javadoc is
> > included in the bin, src and samples distros, samples are included in the
> > samples, src, and impl distro, what is the impl distro? i
> >
> > there's no javadoc in the src distros,  the javadoc in the samples
> > distros is for the samples,  the javadoc in the bin distro is for the API to
> > assist in programming.  This was how the discussion on archive organisation
> > resolved in M2.
>
>
> Ok yes, that must have been a problem with things unpacking into the
> same folder :) But still, javadoc is included in the bin and samples
> distros, the samples are included in the samples and impl distros, and there
> are two src distro's. Which isn't exactly straight forward. I guess none of
> this is a blocker for this release, but in SCA we've now moved the sca-api
> module under the sca folder, maybe the same should happen for SDO and then
> the next release could be:
>  - a single src distribution that includes src for everything
>  - a binary distro that includes the binary jar's, the dependency jars,
> the javadoc, and the samples
>  - the sdo api and impl jars deployed to the maven repo
>
>    ...ant
>


Reply via email to