On Aug 2, 2013, at 12:30 PM, Paul Benedict wrote:
> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today
Thanks for the terms. I had used "apache license categories" and some other
variations.
I assume you mean this:
http://www.apache.org/legal/3party.html#criteriaandcategories
If so, is there an accepted version, other than this merely proposed
version?
Fred.
On Fri, Aug 2, 2013 at 7:39 PM, Steph
Google: Apache third party licenses
Should work on lucky... Or look at the head revision where I added the link.
There is a 3rd category: Category X... Eg GPL, which we are not allowed to
use
On Friday, 2 August 2013, Fred Cooke wrote:
> Are definitions of cat A and B and others listed anywher
Are definitions of cat A and B and others listed anywhere? I searched but
failed.
I assume Cat A = permissive and Cat B = copyleft? or?
On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Correct. And it would be subject to the same CTR and potential vet
Correct. And it would be subject to the same CTR and potential veto if Cat
A. If Cat B and being added to core then you'd have a mandatory vote by the
PMC where the majority *of the whole PMC* are required to approve.
The rational being, a Cat A licensed dependency can always be forked into
Maven
Is this really specific to PMC? Can't a regular developer like myself do
the same, i.e. setup a project elsewhere, then commit to
maven core?
--
Regards,
Igor
On 2013-08-02 8:29 PM, Paul Benedict wrote:
I've stated from the beginning of this thread that it's impossible to
prevent someone from
I've stated from the beginning of this thread that it's impossible to
prevent someone from developing outside of Apache. I stand by that still.
That can't be prevented and any attempt will fail since it's not practical.
If my words today aren't clear, I'll try again. My stance isn't about
halting
On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly
wrote:
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one..
We cannot stop somebody from developing something outside of Apache.
So I could go off and write a High Performance Logging API... now I could
be doing that because I want to foist that Logging API on Maven... or I
could be doing it as an experiment that, if successful, I may offer for
Maven to co
I don't understand the iron hand analogy. I was expressing the use of a
vote to allow or disallow critical development outside of Apache. The vote
would lead to a consensus, no?
On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> On 2 August 2013 16:32,
On 2 August 2013 16:32, Paul Benedict wrote:
> Furthermore, I'd like to see explicit procedural rules on Maven Core and
> forking. For example, if there's a critical component needing development
> for Core, and a PMC expresses that such development will be done outside of
> Apache and then used
Furthermore, I'd like to see explicit procedural rules on Maven Core and
forking. For example, if there's a critical component needing development
for Core, and a PMC expresses that such development will be done outside of
Apache and then used as a dependency, shouldn't there be a vote on that?
O
On 2 August 2013 16:08, Curtis Rueden wrote:
> Hi Stephen,
>
> > If anyone wants to look at the resulting Work In Progress document as
> > a whole:
> >
>
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup
> >
> > Thoughts?
>
> Big thumbs
On 2 August 2013 16:07, Brian Fox wrote:
> I think the bulk of this is pretty good. On the fork section, specifically:
>
> "
> As soon as changes in that
> fork are identified which should be brought back to the project those
> changes should be introduced into at least a branch hosted on the Apa
I think the bulk of this is pretty good. On the fork section, specifically:
"
As soon as changes in that
fork are identified which should be brought back to the project those
changes should be introduced into at least a branch hosted on the Apache Maven
source control in order to facilitate the ea
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=150959
16 matches
Mail list logo
