[DISCUSS] Brining clirr to the ASF?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Brining clirr to the ASF?

Benedikt Ritter-4
Hi,

as Jochen has pointed out, Clirr seems to be unmaintained. However we build
a good part of our release strategy upon clirr. So I wonder whether we
should foster bringing clirr to the ASF (for example by going through
incubation). We're probably not the only ASF project using Clirr.

Benedikt
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

garydgregory
On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter <[hidden email]>
wrote:

> Hi,
>
> as Jochen has pointed out, Clirr seems to be unmaintained. However we build
> a good part of our release strategy upon clirr. So I wonder whether we
> should foster bringing clirr to the ASF (for example by going through
> incubation). We're probably not the only ASF project using Clirr.
>

+1. Can we bring in code that's under GNU Lesser General Public and make it
ASL 2?

Could fit under a new Commons Build or Clirr component since it is a
"common" build requirement.

Gary


> Benedikt
>



--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

Benedikt Ritter-4
Gary Gregory <[hidden email]> schrieb am Di., 14. Juni 2016 um
08:23 Uhr:

> On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter <[hidden email]>
> wrote:
>
> > Hi,
> >
> > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> > a good part of our release strategy upon clirr. So I wonder whether we
> > should foster bringing clirr to the ASF (for example by going through
> > incubation). We're probably not the only ASF project using Clirr.
> >
>
> +1. Can we bring in code that's under GNU Lesser General Public and make it
> ASL 2?
>

That would be a task for incubation


>
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.
>

Given the size of Clirr (base library + build tool plugins), I'd rather try
to instantiate a new TLP by going through incubation.


>
> Gary
>
>
> > Benedikt
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

jochen-2
In reply to this post by garydgregory
On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory <[hidden email]> wrote:

>> as Jochen has pointed out, Clirr seems to be unmaintained. However we build
>> a good part of our release strategy upon clirr. So I wonder whether we
>> should foster bringing clirr to the ASF (for example by going through
>> incubation). We're probably not the only ASF project using Clirr.
>>
>
> +1. Can we bring in code that's under GNU Lesser General Public and make it
> ASL 2?
>
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.

As Clirr is internally based on BCEL, I'd rather see us build a new
tool on top of ASM, which is very well maintained. Besides, that would
solve the license problem.

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

Benedikt Ritter-4
Jochen Wiedmann <[hidden email]> schrieb am Di., 14. Juni 2016
um 08:40 Uhr:

> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory <[hidden email]>
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release strategy upon clirr. So I wonder whether we
> >> should foster bringing clirr to the ASF (for example by going through
> >> incubation). We're probably not the only ASF project using Clirr.
> >>
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> > ASL 2?
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
>
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.
>

Sounds like a massive endeavor. Are you sure we could build that in a
reasonable amount of time?


>
> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

jochen-2
On Tue, Jun 14, 2016 at 8:50 AM, Benedikt Ritter <[hidden email]> wrote:
> Jochen Wiedmann <[hidden email]> schrieb am Di., 14. Juni 2016

>> As Clirr is internally based on BCEL, I'd rather see us build a new
>> tool on top of ASM, which is very well maintained. Besides, that would
>> solve the license problem.
>>
>
> Sounds like a massive endeavor. Are you sure we could build that in a
> reasonable amount of time?

No. But I am quite certain, that we could maintain that, rather than
having digged a new grave for the same corpse.

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

Uwe Barthel
In reply to this post by jochen-2
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.

Sounds like a existing idea. I'm interested in to contribute.

-- barthel



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

James Carman
In reply to this post by jochen-2
+1 to Jochen's idea and I'd love to contribute to that effort!

On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann <[hidden email]>
wrote:

> On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory <[hidden email]>
> wrote:
>
> >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> >> a good part of our release strategy upon clirr. So I wonder whether we
> >> should foster bringing clirr to the ASF (for example by going through
> >> incubation). We're probably not the only ASF project using Clirr.
> >>
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> > ASL 2?
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
>
> As Clirr is internally based on BCEL, I'd rather see us build a new
> tool on top of ASM, which is very well maintained. Besides, that would
> solve the license problem.
>
> Jochen
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

Paul King-2
For any Gradle users, C├ędric put together a little Gradle plugin based
around the japicmp library which we use in Groovy, see here:

https://github.com/apache/groovy/blob/master/gradle/binarycompatibility.gradle

Cheers, Paul.

On Tue, Jun 14, 2016 at 9:56 PM, James Carman <[hidden email]>
wrote:

> +1 to Jochen's idea and I'd love to contribute to that effort!
>
> On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann <[hidden email]
> >
> wrote:
>
> > On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory <[hidden email]>
> > wrote:
> >
> > >> as Jochen has pointed out, Clirr seems to be unmaintained. However we
> > build
> > >> a good part of our release strategy upon clirr. So I wonder whether we
> > >> should foster bringing clirr to the ASF (for example by going through
> > >> incubation). We're probably not the only ASF project using Clirr.
> > >>
> > >
> > > +1. Can we bring in code that's under GNU Lesser General Public and
> make
> > it
> > > ASL 2?
> > >
> > > Could fit under a new Commons Build or Clirr component since it is a
> > > "common" build requirement.
> >
> > As Clirr is internally based on BCEL, I'd rather see us build a new
> > tool on top of ASM, which is very well maintained. Besides, that would
> > solve the license problem.
> >
> > Jochen
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

RE: [DISCUSS] Brining clirr to the ASF?

Dennis E. Hamilton
In reply to this post by garydgregory
[Chiming in lest those on the Commons PMC who know the answer don't and leave the LGPL question dangling.]

> -----Original Message-----
> From: Gary Gregory [mailto:[hidden email]]
> Sent: Monday, June 13, 2016 23:23
> To: Commons Developers List <[hidden email]>
> Subject: Re: [DISCUSS] Brining clirr to the ASF?
>
> On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter <[hidden email]>
> wrote:
>
> > Hi,
> >
> > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> build
> > a good part of our release strategy upon clirr. So I wonder whether we
> > should foster bringing clirr to the ASF (for example by going through
> > incubation). We're probably not the only ASF project using Clirr.
> >
>
> +1. Can we bring in code that's under GNU Lesser General Public and make
> it
> ASL 2?
[orcmid]

Short answer: No.

Does not the exception for build dependencies apply for clirr though, so long as it is not in releases and in the project repository?  

TL;DR Longer answer, to bring clirr into the project.  If those who hold copyright in the Clirr code agree to license it to the ASF under terms that empower the ASF to provide a different license, this would work.  It is not otherwise possible for parties who are not the original copyright holders or so-empowered licensees to alter the license on anything (and that applies to ASLv2-licensed works too).  Generally, one can't even get *into* incubation without a cure in hand before the subject code is imported for IP cleanup.  Please consult
<http://apache.org/legal/resolved.html>,
<http://incubator.apache.org/guides/mentor.html#initial-ip-clearance>,
and <http://www.apache.org/legal/src-headers.html> for related considerations.

And then there are the dependencies of clirr to pay attention to.

>
> Could fit under a new Commons Build or Clirr component since it is a
> "common" build requirement.
>
> Gary
>
>
> > Benedikt
> >
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Brining clirr to the ASF?

Benedikt Ritter-4
Thank you for the clarification, Dennis!

Dennis E. Hamilton <[hidden email]> schrieb am Di., 14. Juni 2016
um 19:57:

> [Chiming in lest those on the Commons PMC who know the answer don't and
> leave the LGPL question dangling.]
>
> > -----Original Message-----
> > From: Gary Gregory [mailto:[hidden email]]
> > Sent: Monday, June 13, 2016 23:23
> > To: Commons Developers List <[hidden email]>
> > Subject: Re: [DISCUSS] Brining clirr to the ASF?
> >
> > On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > as Jochen has pointed out, Clirr seems to be unmaintained. However we
> > build
> > > a good part of our release strategy upon clirr. So I wonder whether we
> > > should foster bringing clirr to the ASF (for example by going through
> > > incubation). We're probably not the only ASF project using Clirr.
> > >
> >
> > +1. Can we bring in code that's under GNU Lesser General Public and make
> > it
> > ASL 2?
> [orcmid]
>
> Short answer: No.
>
> Does not the exception for build dependencies apply for clirr though, so
> long as it is not in releases and in the project repository?
>
> TL;DR Longer answer, to bring clirr into the project.  If those who hold
> copyright in the Clirr code agree to license it to the ASF under terms that
> empower the ASF to provide a different license, this would work.  It is not
> otherwise possible for parties who are not the original copyright holders
> or so-empowered licensees to alter the license on anything (and that
> applies to ASLv2-licensed works too).  Generally, one can't even get *into*
> incubation without a cure in hand before the subject code is imported for
> IP cleanup.  Please consult
> <http://apache.org/legal/resolved.html>,
> <http://incubator.apache.org/guides/mentor.html#initial-ip-clearance>,
> and <http://www.apache.org/legal/src-headers.html> for related
> considerations.
>
> And then there are the dependencies of clirr to pay attention to.
>
> >
> > Could fit under a new Commons Build or Clirr component since it is a
> > "common" build requirement.
> >
> > Gary
> >
> >
> > > Benedikt
> > >
> >
> >
> >
> > --
> > E-Mail: [hidden email] | [hidden email]
> > Java Persistence with Hibernate, Second Edition
> > <http://www.manning.com/bauer3/>
> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> > Spring Batch in Action <http://www.manning.com/templier/>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>