I voted +1, but I personally think the vote is kind of irrelevant.....
FACT: The stuff in the incubator repo are Apache releases. They had the 3
binding +1 votes from the incubator IPMC members. They are releases.
FACT: The stuff in the incubator repo is all Apache Licensed artifacts.
FACT: Nowhere in the Apache License is there a requirement that the user has
to read and accept the Incubator disclaimer prior to use.
Given the above:
If RedHat decided to put incubator artifacts in their repository without a
click through "this is incubator code" disclaimer, we'd have no legal reason
to say no. The Apache License allows them to do so.
If Debian decided to put incubator artifacts in their repository without a
click through "this is incubator code" disclaimer, we'd have no legal reason
to say no. The Apache License allows them to do so.
If the CPAN maintainers decided to put incubator perl modules into their
repository without a click through "this is incubator code" disclaimer, we'd
have no legal reason to say no. The Apache License allows them to do so.
If repo maintainer XXXXX decided to put incubator perl modules into their
repository without a click through "this is incubator code" disclaimer, we'd
have no legal reason to say no. The Apache License allows them to do so.
If Ivy/Builder/Ant/etc.... decided to create their own repository and wanted
the incubator artifacts in it, we'd have no legal reason to say no. The
Apache License allows them to do so.
Thus:
If the central maven repository maintainers (Maven PMC) decide to put
incubator artifacts into their repository without a click through "this is
incubator code" disclaimer, we'd have no legal reason to say no. The Apache
License allows them to do so.
Thus, to me, the vote is kind of pointless. Jukka (or other maven users)
should just ask the Maven folks to start syncing the m2-incubator-repo dir
off of people.apache.org. If the Maven PMC thinks that's in the best
interest of THEIR community and users, they should go ahead and do it
(obviously working with infrastructure to work out logistics to reduce load
and such). The license that applies to all the artifacts in that repo
certainly allows it.
Thus, this vote really is about reducing the burden on the Maven PMC and on
infrastructure. There is an auto-sync dir already setup. Should we use it
or should they be separate which would require new syncs setup which would
result in more processes/connections on people.apache.org, extra bandwidth
used for those extra rsyncs, etc....
If the incubator wants to go off to the board and legal and ask for a
new "Apache Incubator License" that would require the click through, fine.
But until then, lets actually follow the license that is currently being
used.
Anyway, thats my 2 cents worth. (caveat: it may not be worth 2 cents to you)
:-)
Dan
On Tuesday 16 September 2008 6:49:04 pm Matthieu Riou wrote:
> On Tue, Sep 16, 2008 at 2:10 PM, William A. Rowe, Jr.
>
> <[EMAIL PROTECTED]>wrote:
> > Justin Erenkrantz wrote:
> >> On Mon, Sep 15, 2008 at 11:13 AM, Emmanuel Lecharny
> >> <[EMAIL PROTECTED]>
> >>
> >> wrote:
> >>> Craig L Russell wrote:
> >>>> -1
> >>>>
> >>>> I believe that allowing incubating releases to be treated as full
> >>>> Apache releases diminishes the Apache brand and makes incubation
> >>>> disclaimers moot.
> >>>>
> >>>> With Maven, it is too easy to depend on a release with transitive
> >>>> dependencies on incubating releases without even knowing it. When the
> >>>> incubating release subsequently is abandoned, blame will be cast
> >>>> widely, including Apache itself.
> >>>>
> >>>> Considering that dependencies on incubating releases can be resolved
> >>>> by explicitly adding an incubating Maven repository into your
> >>>> settings, I don't
> >>>> think that wide, mirrored, distribution is warranted.
> >>>>
> >>>> Craig
> >>>
> >>> -1 too, for the same reasons.
> >>
> >> -1. Craig pointed out my objections as well. -- justin
> >
> > Just so everyone understands this in context, the objection above is moot
> > because...
> >
> > ...maven is a package deployment mechanism
>
> Beg your pardon? I know that the homepage casts a wide net ("Maven is a
> software project management and comprehension tool.") but in my book Maven
> is used to build stuff (which happens to be almost exclusively Java). I
> don't know of anybody who goes to actual users and tell them "here you go,
> unzip that stuff there, set your JAVA_HOME and your MAVEN_HOME properly,
> execute 'mvn install' and once all test cases pass you're golden".
>
> Maven is a build tool. Users don't build, developers do. And developers
> should know about licenses and disclaimers.
>
> Cheers,
> Matthieu
>
> > ...developers who determine what to bundle into their package don't spend
> > a whole lot of time explaining to users that something within their
> > package is 'incubating' code, or 'patched/forked' code, or virgin
> > original code
> >
> > ...the developer who deploys an app is either going to explain it
> > contains an incubating artifact to their users, or they won't
> >
> > ...no matter if the developer bundles an incubating jar, or calls it up
> > out of maven...
> >
> > The user has ***exactly*** the same experience.
> >
> > Presenting a user with a dialog "Package FOO requires the BAR.jar, an
> > Apache Incubating Bar Project artifact, which[1] carries 'the'[2]
> > disclaimer" will leave them utterly befuddled and is entirely worthless
> > information in the context that they install package FOO (nevermind that
> > the "actual" disclaimer appears to be non-existent in our release
> > documentation).
> >
> > We permit GPL, commercial, virtual anything to be deposited into Maven
> > if I understand correctly. WTF not incubation artifacts, in that light?
> >
> > Bill
> >
> > [1] alternately... "is a tasty beverage container"
> > [2]
> > http://incubator.apache.org/guides/releasemanagement.html#notes-disclaime
> >r
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
