deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Bryzak <sbry...@gmail.com>
Subject Re: IP discussion
Date Sun, 15 Jan 2012 13:28:09 GMT
We'd need to follow this up with Red Hat legal, to confirm what we need to
do.

On Sun, Jan 15, 2012 at 6:24 AM, Jason Porter <lightguard.jp@gmail.com>wrote:

> Would someone like myself or Shane work or do we need someone higher up in
> the organization or a lawyer to sign off on it?
>
> On Sat, Jan 14, 2012 at 13:13, Matt Benson <gudnabrsam@gmail.com> wrote:
>
> > On Sat, Jan 14, 2012 at 2:09 PM, Jason Porter <lightguard.jp@gmail.com>
> > wrote:
> > > Of course, I don't deal with legal matters, but would the simplest way
> > be to have a statement from someone representing Red Hat that code from
> > Seam 3 and Solder is permissible to use?
> >
> > That would be great.  Failing that, taking all contributions on the
> > merits of their individual authors' copyright ownership is fine too;
> > I'd just like for us to be more explicit about it.
> >
> > Thanks for your quick response (and sorry you had to read the original
> > message on a phone ;)  ),
> >
>
> It worked, no worries.
>
>
> > Matt
> >
> > >
> > > Sent from my iPhone
> > >
> > > On Jan 14, 2012, at 13:00, Matt Benson <gudnabrsam@gmail.com> wrote:
> > >
> > >> Hi all,
> > >>  Deltaspike is a bit unusual as podlings go:  its code is not a
> > >> "drop" from one single source (which would typically be accompanied by
> > >> a software grant), nor is its code grown entirely from nothing.  Part
> > >> of the incubation process requires the necessary precautions be taken
> > >> to ensure that the project's IP is not encumbered in any way.  I'm not
> > >> here to scold folks, but now that I step back and take in the
> > >> landscape, I am not fully comfortable with our process thus far wrt
> > >> absorbing code from the various points of ingress we all represent.
> > >> I'll go on:
> > >>
> > >>  Firstly, it's simply a fact that the CODI code is a non-issue:  it's
> > >> been grown under the auspices of an Apache TLP and there is no reason
> > >> to doubt that it remains as unencumbered now as ever.  I mention this
> > >> because it's not at all like I or anyone else is of the "old boys
> > >> club" mentality or any such nonsense; I'm just categorizing the
> > >> DeltaSpike codebase as it now stands.  Thus far, I am concerned by the
> > >> Solder-based code.  For example, the copyright notice at
> > >>
> >
> https://github.com/seam/solder/blob/develop/impl/src/main/java/org/jboss/solder/reflection/annotated/AnnotatedTypeBuilder.java
> > >> (this is pretty clearly the same code as currently lives in the
> > >> DeltaSpike repo) says "Copyright 2011, Red Hat, Inc. and/or its
> > >> affiliates, and individual contributors by the @authors tag".  The
> > >> @authors tag cites Stuart Douglas and Pete Muir, so I read the notice
> > >> as saying that copyright is shared between these individuals and Red
> > >> Hat for this particular file.  Fine; both Stuart and Pete have filed
> > >> their ICLAs and have received their accounts (I've not checked the
> > >> other files, but I assume they are similarly attributed).  However,
> > >> Jason actually committed the code.  This is not necessarily wrong; Red
> > >> Hat does have a corporate CLA on file with the ASF, and Jason is a Red
> > >> Hat employee.  IMO then the only thing missing is an unequivocal
> > >> statement on the parts of the Red Hat-employed DeltaSpike committers
> > >> that any of them (or, in this case, at least Jason) is authorized to
> > >> license whatever Solder, etc. code he sees fit, on Red Hat's behalf,
> > >> to Apache for inclusion in the DeltaSpike codebase.  Just because Red
> > >> Hat has filed the CCLA does not mean that every line of their code is
> > >> now up for grabs, and I see nothing to this explicit effect in the
> > >> incubation proposal, so that connection from point A to point B is
> > >> essential.  We must be able to show clear provenance for any code that
> > >> we bring in, regardless of the source, so again, please don't feel
> > >> "singled out."  The builder code is the first example I thought of,
> > >> and I'm pretty sure that nothing has, as yet, been added from source
> > >> other than CODI/Solder.  Now, if the Solder code is rather to be
> > >> contributed on the basis of the individual authors' copyrights, making
> > >> sure everything that has already been added is kosher will require a
> > >> little more work, but ultimately the situation is the same:  one of
> > >> the copyright holders needs to have been responsible for licensing the
> > >> code for ASF use, although it is fine by me if that authorization
> > >> comes in blanket form and I'm perfectly willing to take committers at
> > >> their word wrt to the Red Hat or any similar situation.  Finally, if
> > >> and when we do end up with any code being officially licensed from Red
> > >> Hat rather than from the individual authors (or if I've misinterpreted
> > >> the spirit of the Solder copyright notice), then Red Hat would also
> > >> need to be credited in the project's NOTICE file.
> > >>
> > >> Thanks in advance for addressing my concerns (or pointing out what
> > >> I've missed that proactively addressed them),
> > >> Matt
> >
>
>
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message