Quantcast

Hudson Discussion Summary

classic Classic list List threaded Threaded
75 messages Options
1234
ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Hudson Discussion Summary

ted
All,

Sorry for the delay.  I have been in meetings (and not the good kind) since 7am today.  I was not able to get final approval to post the actual license text, but as promised (and requested) I am posting the summary and process docs anyway.  I do have the license in front of me so if people have specific questions I can try to answer them in email until I get the ok (hopefully in a day or so) to post the actual license.  


I am happy to answer any questions or clarify anything if it is unclear.  thx.

    -ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Christopher Orr
Hi Ted,

Thanks for the update.

On 25/01/2011 00:36, Ted Farrell wrote:
> http://hudson-ci.org/docs/process_summary.html
>
> I am happy to answer any questions or clarify anything if it is unclear.

The "Software Process Proposal" v0.4, section IV says:

"All committers to the Hudson plugins submitted to the common Hudson
repository also need to sign the OCA [Oracle Contributor Agreement].
(This is the same as it has always been. This is not a change)"


Could you please clarify a couple of points?

1. How is the "common Hudson repository" defined in this instance?
    Every commit under svn.java.net/svn/hudson~svn/?

2. I have never been aware that plugin developers must sign an agreement.
    The wiki currently says that "we encourage plugin contributors to
sign the contributor agreement".  i.e. it suggests that signing a
contributor agreement is not mandatory.
    http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code


Thanks,
Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Andrew Bayer
Historically, no, there has been no requirement of plugin authors signing the CLA, etc. If that's actually intentional, that is a significant change, yes.

A.

On Mon, Jan 24, 2011 at 4:02 PM, Christopher Orr <[hidden email]> wrote:
Hi Ted,

Thanks for the update.


On 25/01/2011 00:36, Ted Farrell wrote:
http://hudson-ci.org/docs/process_summary.html

I am happy to answer any questions or clarify anything if it is unclear.

The "Software Process Proposal" v0.4, section IV says:

"All committers to the Hudson plugins submitted to the common Hudson repository also need to sign the OCA [Oracle Contributor Agreement]. (This is the same as it has always been. This is not a change)"


Could you please clarify a couple of points?

1. How is the "common Hudson repository" defined in this instance?
  Every commit under svn.java.net/svn/hudson~svn/?

2. I have never been aware that plugin developers must sign an agreement.
  The wiki currently says that "we encourage plugin contributors to sign the contributor agreement".  i.e. it suggests that signing a contributor agreement is not mandatory.
  http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code


Thanks,
Chris

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Monty Taylor
In reply to this post by Christopher Orr
On 01/24/2011 04:02 PM, Christopher Orr wrote:

> Hi Ted,
>
> Thanks for the update.
>
> On 25/01/2011 00:36, Ted Farrell wrote:
>> http://hudson-ci.org/docs/process_summary.html
>>
>> I am happy to answer any questions or clarify anything if it is unclear.
>
> The "Software Process Proposal" v0.4, section IV says:
>
> "All committers to the Hudson plugins submitted to the common Hudson
> repository also need to sign the OCA [Oracle Contributor Agreement].
> (This is the same as it has always been. This is not a change)"
>
>
> Could you please clarify a couple of points?
>
> 1. How is the "common Hudson repository" defined in this instance?
>    Every commit under svn.java.net/svn/hudson~svn/?
>
> 2. I have never been aware that plugin developers must sign an agreement.
>    The wiki currently says that "we encourage plugin contributors to
> sign the contributor agreement".  i.e. it suggests that signing a
> contributor agreement is not mandatory.
>    http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code

I am a plugin contributor. I have not signed the OCA. Also, if such a
requirement came in to existence, I would not be very inclined to sign it.
ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

ted

OK, my bad.   One thing that came up in the talks was separating core
contributors from plugin contributors.  I could have had an error in
my notes w.r.t. who currently signed what.  I'll get the page
updated.  Thanks for catching that Monty.

I think one thing we should address is the licensing of the plugins.
Right now some of our customers are not comfortable using some of the
plugins (even internally) because of either unfriendly or unknown
licenses.  One of the improvements we talked about was having the
plugin contributors declaring the license when they checked it in.
This would let anyone who is consuming it know what they are getting.
Git has built-in support for this that could be used.

    -ted

On Jan 24, 4:11 pm, Monty Taylor <[hidden email]> wrote:

> On 01/24/2011 04:02 PM, Christopher Orr wrote:
>
>
>
>
>
>
>
>
>
> > Hi Ted,
>
> > Thanks for the update.
>
> > On 25/01/2011 00:36, Ted Farrell wrote:
> >>http://hudson-ci.org/docs/process_summary.html
>
> >> I am happy to answer any questions or clarify anything if it is unclear.
>
> > The "Software Process Proposal" v0.4, section IV says:
>
> > "All committers to the Hudson plugins submitted to the common Hudson
> > repository also need to sign the OCA [Oracle Contributor Agreement].
> > (This is the same as it has always been. This is not a change)"
>
> > Could you please clarify a couple of points?
>
> > 1. How is the "common Hudson repository" defined in this instance?
> >    Every commit under svn.java.net/svn/hudson~svn/?
>
> > 2. I have never been aware that plugin developers must sign an agreement.
> >    The wiki currently says that "we encourage plugin contributors to
> > sign the contributor agreement".  i.e. it suggests that signing a
> > contributor agreement is not mandatory.
> >    http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code
>
> I am a plugin contributor. I have not signed the OCA. Also, if such a
> requirement came in to existence, I would not be very inclined to sign it.
ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

ted

typo below.  Thanks to Christopher for catching this.

On Jan 24, 4:27 pm, ted <[hidden email]> wrote:

> OK, my bad.   One thing that came up in the talks was separating core
> contributors from plugin contributors.  I could have had an error in
> my notes w.r.t. who currently signed what.  I'll get the page
> updated.  Thanks for catching that Monty.
>
> I think one thing we should address is the licensing of the plugins.
> Right now some of our customers are not comfortable using some of the
> plugins (even internally) because of either unfriendly or unknown
> licenses.  One of the improvements we talked about was having the
> plugin contributors declaring the license when they checked it in.
> This would let anyone who is consuming it know what they are getting.
> Git has built-in support for this that could be used.
>
>     -ted
>
> On Jan 24, 4:11 pm, Monty Taylor <[hidden email]> wrote:
>
>
>
>
>
>
>
> > On 01/24/2011 04:02 PM, Christopher Orr wrote:
>
> > > Hi Ted,
>
> > > Thanks for the update.
>
> > > On 25/01/2011 00:36, Ted Farrell wrote:
> > >>http://hudson-ci.org/docs/process_summary.html
>
> > >> I am happy to answer any questions or clarify anything if it is unclear.
>
> > > The "Software Process Proposal" v0.4, section IV says:
>
> > > "All committers to the Hudson plugins submitted to the common Hudson
> > > repository also need to sign the OCA [Oracle Contributor Agreement].
> > > (This is the same as it has always been. This is not a change)"
>
> > > Could you please clarify a couple of points?
>
> > > 1. How is the "common Hudson repository" defined in this instance?
> > >    Every commit under svn.java.net/svn/hudson~svn/?
>
> > > 2. I have never been aware that plugin developers must sign an agreement.
> > >    The wiki currently says that "we encourage plugin contributors to
> > > sign the contributor agreement".  i.e. it suggests that signing a
> > > contributor agreement is not mandatory.
> > >    http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code
>
> > I am a plugin contributor. I have not signed the OCA. Also, if such a
> > requirement came in to existence, I would not be very inclined to sign it.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Monty Taylor
In reply to this post by ted
On 01/24/2011 04:27 PM, ted wrote:

>
> OK, my bad.   One thing that came up in the talks was separating core
> contributors from plugin contributors.  I could have had an error in
> my notes w.r.t. who currently signed what.  I'll get the page
> updated.  Thanks for catching that Monty.
>
> I think one thing we should address is the licensing of the plugins.
> Right now some of our customers are not comfortable using some of the
> plugins (even internally) because of either unfriendly or unknown
> licenses.  One of the improvements we talked about was having the
> plugin contributors declaring the license when they checked it in.
> This would let anyone who is consuming it know what they are getting.
> Git has built-in support for this that could be used.

I wholeheartedly agree with this one. I find the licensing of files in
the source tree very haphazard or unclear. In my world, a tree itself
needs a LICENSE file, and each source file should really have a license
header.

As usual, whatever folks here decide on - but we just spent a bazillion
hours cleaning up the license header situation in Drizzle because of
Debian packaging (turns out, Debian kindof cares about that sort of thing)


> On Jan 24, 4:11 pm, Monty Taylor <[hidden email]> wrote:
>> On 01/24/2011 04:02 PM, Christopher Orr wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> Hi Ted,
>>
>>> Thanks for the update.
>>
>>> On 25/01/2011 00:36, Ted Farrell wrote:
>>>> http://hudson-ci.org/docs/process_summary.html
>>
>>>> I am happy to answer any questions or clarify anything if it is unclear.
>>
>>> The "Software Process Proposal" v0.4, section IV says:
>>
>>> "All committers to the Hudson plugins submitted to the common Hudson
>>> repository also need to sign the OCA [Oracle Contributor Agreement].
>>> (This is the same as it has always been. This is not a change)"
>>
>>> Could you please clarify a couple of points?
>>
>>> 1. How is the "common Hudson repository" defined in this instance?
>>>    Every commit under svn.java.net/svn/hudson~svn/?
>>
>>> 2. I have never been aware that plugin developers must sign an agreement.
>>>    The wiki currently says that "we encourage plugin contributors to
>>> sign the contributor agreement".  i.e. it suggests that signing a
>>> contributor agreement is not mandatory.
>>>    http://wiki.hudson-ci.org/display/HUDSON/Copyright+on+source+code
>>
>> I am a plugin contributor. I have not signed the OCA. Also, if such a
>> requirement came in to existence, I would not be very inclined to sign it..
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Robert Collins
In reply to this post by ted
On Tue, Jan 25, 2011 at 12:36 PM, Ted Farrell <[hidden email]> wrote:

> All,
> Sorry for the delay.  I have been in meetings (and not the good kind) since
> 7am today.  I was not able to get final approval to post the actual license
> text, but as promised (and requested) I am posting the summary and process
> docs anyway.  I do have the license in front of me so if people have
> specific questions I can try to answer them in email until I get the ok
> (hopefully in a day or so) to post the actual license.
> http://hudson-ci.org/docs/process_summary.html
> I am happy to answer any questions or clarify anything if it is unclear.
>  thx.
>     -ted

I've a few small comments about the proposal itself, and then a
somewhat larger meta-discussion.

Possibly the most significant one: Ubuntu (which I contribute to in my
spare time (when it exists)) only supports things which can be built
from source; things that cannot be built from source get (at best)
second class status. A requirement that things not be called 'Hudson'
if they are not the byte-for-byte .war file from the hudson website
would result in one of a small set of things:
 - no Hudson for Ubuntu in the Ubuntu Software Centre
 - a package called 'nosduH' or some similar undiscoverable thing (see
for instance iceweasel (aka firefox)).
 - a package which is disabled by default, bug reports are not
accepted on, and users are generally told not to use.
It is a strong requirement for Ubuntu that things we ship we be able
to bugfix and support. If we ship a Hudson package in a long term
support release, we're committing to 5 years of support on it; that
means backports, security fixes and so on - we try, for our users,
very very very hard not to just dump new upstream releases in during
that 5 year period.

Secondly, while I value code review and QA a great deal, your proposal
appears to add a bunch of /mandatory/ overhead without explaining the
benefits the project will receive from it. Hudson's quality is very
high at the moment, measured by fitness for purpose; adding must-do
steps to the process of creating it must be justified by concrete
benefits that the volunteers creating it will buy into - otherwise the
bar for contributions is raised but the motivation to follow the
labelled process isn't.

Lastly, i too haven't signed the SCA, it was never requested, and IIRC
I have patches in core as well as the various bits in a few plugins -
including one plugin I started from scratch, and if anyone is signing
a CA for that, it would be Oracle, thank you very much.

Ted, I support Oracle wanting to be part of this community - Sun
merged with Oracle and you're stepping into some fairly big shoes
there :). However it would help me a great deal to know what you want
to achieve with the changes you're proposing.

You talk about licensing concerns with the technology components, but
I don't recall seeing any detail about what those concerns are.

On the trademark side, you say you want to ensure consistency and
reliability. Hudon has had great success without a trademark; having a
trademark is obviously not a sufficient condition, and the success so
far is a demonstration that its not a necessary condition. If you feel
that its a necessary condition, you are essentially saying that the
prior stewards of consistency and reliability cannot be trusted to
continue to do a good job. That makes me sad.

That said, its up to you if you want to get one. As a new custodian
though, the onus is on you to demonstrate good faith here: Oracle has
a history of competing pretty strongly, and I can well understand any
concerns that other Hudson vendors may feel. (For instance, Oracle's
selling of support to RHEL users is part of the stage here). Handing
the trademark to a non-vendor, neutral party whose only interest is in
the consistency and reliability that users get would be a great way to
both demonstrate good faith on the more functional issues, and achieve
your stated goals.

It may be that there is a crossing-the-chasm thing here - you may have
analyzed the market and concluded that without some more of the
trappings of off-the-shelf software, Hudson cannot really explode onto
the world stage - if thats the case, stand up and support this
argument! (Its one I would find plausible for many of the things
you're proposing: not saying its a sufficient argument though ;)).

Well, thats about it, I hope this raises some food for thought for you.

-Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Andrew Bayer
In reply to this post by ted
Hi Ted -

What I saw as the underlying problem in our talks earlier still stands - there's no guarantee of the independence of the Hudson project from Oracle. The naming rights policy you lay out doesn't say who determines what is a valid Hudson release in the first place. Who is the final arbiter of that? If, for instance, the Hudson developers make a technology decision Oracle opposes, does Oracle have the power to keep that change from being made/released? As a rule, I'm not comfortable with a de facto assurance that Oracle (or any other corporate entity in another context) would have veto power over a supposedly independent project. If Oracle retains that power, well, it's not an independent project. This is the reason I propose renaming - I don't think this project should be beholden to a corporate overlord, given the broad range of committers, users, use cases, extensions, commercial bundlings, etc.

A.

On Mon, Jan 24, 2011 at 6:52 PM, ted <[hidden email]> wrote:

Hi Jesse,  Thanks for the reply.  Answers/comments inline.

> I think the process document could be updated to mark some things as
> hard or soft; meaning that not every update should have to be backed
> up by a testcase, but it is generally considered a good practice, e.g.
> Mandating this is really going to cramp the existing development
> process and I expect it would be counter productive.

Sure.  I think the process doc is up for discussion.  Others actually
suggested that every checkin has a test case where possible so maybe
one of them can comment on that.

> I build Hudson from source using a Maven WAR overlay, it seems I would
> no longer be able to do this according to the proposal. It's a great
> way of customizing Hudson to be minimalistic to what is required for
> my deployment. It also provides a great way of deploying (using the
> cargo-maven-plugin). I think this section needs to be reworked, and I
> don't see why a TCK should be involved. What are your thoughts?

If you are not producing a product that you are going to market/sell
as "Hudson", then you can do whatever you want.  Are you offering your
version of Hudson publicly?  If you are, you could always get a
license specific to what you are doing, as long as what you are doing
doesn't make the plugins incompatible.  For your own internal
deployment, the naming license has zero effect on you.

> From the document: "As many of you have pointed out, there can be a
> fork at any time. If Oracle ever did anything that the community
> disagreed with, whether it was enforcing new rights on the Hudson
> name, or trying to muscle the community, the community could always
> fork at that point in time. That is one of the assurances against a
> corporation doing things like that."
>
> I think this paragraph is very telling, in that:
>
>    - Oracle has done quite a bit that the community has disagreed
> with: java.net botch, e.g.
>    - Oracle has enforced new rights on the Hudson name: no from-source
> Hudson deployments, e.g.

We aren't enforcing any new rights on the Hudson name.  As mentioned
above and in my post, the name doesn't affect users.  All this
proposal does is formalize the naming rights.  Even without applying
for the trademark, Oracle could claim some rights over the name
because of its history.  Rather than it all ending up in a court
somewhere, or someone getting surprised, the idea of this proposal was
to clarify what is needed *only* for companies wanting to use the name
Hudson in a public/commercial offering.  This does not affect users
using hudson internally.  I should also point out that Oracle owns
other trademarks (like Netbeans and Glassfish) that there is no naming
license for and there have been no issues.

>    - Oracle has muscled the community: forcing Winston P. to become
> svn admin, e.g.

Really?  I thought Winston was an svn admin before any of this started
and I remember it being a simple request Winston made KK adding him.
It might have taken more than one email, but I don't remember any
muscling.  Can you elaborate on that?

> I think this final point holds the most weight. Winston is a pretty
> good guy from what I can tell, and his contributions are widely
> appreciated. However, he's just one person .. all statistics presented
> show virtually no activity from Oracle and yet we're at this impasse
> because Oracle is attempting to muscle the community via Hudson TM
> issues.

Again, I am not sure what you mean by muscling the community.
Cloudbees asked us to formalize a naming license so they could know
exactly what our intentions are.  That is what we did.

> I don't dispute Oracle's ownership of it, however recently it
> may have been applied for (Sun botch!), but that's not a way to win
> over a community.. In my eyes, and probably in many others, Oracle
> owns Hudson in the same way that an out of state landlord owns my
> apartment--on a technicality.

That last analogy aside ;)  the goal of owning the trademark is to try
and provide stability and consistency to the name in the industry.
Are you saying that you disagree that everything calling itself Hudson
should support all the same plugins?  I guess I'm not clear as to what
you are objecting to, or what specifically you think we are doing to
muscle the community.  Can you elaborate?

thx.

   -ted

ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

ted
In reply to this post by Robert Collins

Hi Rob,

> Possibly the most significant one: Ubuntu (which I contribute to in my
> spare time (when it exists)) only supports things which can be built
> from source; things that cannot be built from source get (at best)
> second class status. A requirement that things not be called 'Hudson'
> if they are not the byte-for-byte .war file from the hudson website
> would result in one of a small set of things:
>  - no Hudson for Ubuntu in the Ubuntu Software Centre
>  - a package called 'nosduH' or some similar undiscoverable thing (see
> for instance iceweasel (aka firefox)).
>  - a package which is disabled by default, bug reports are not
> accepted on, and users are generally told not to use.
> It is a strong requirement for Ubuntu that things we ship we be able
> to bugfix and support. If we ship a Hudson package in a long term
> support release, we're committing to 5 years of support on it; that
> means backports, security fixes and so on - we try, for our users,
> very very very hard not to just dump new upstream releases in during
> that 5 year period.

It is an interesting use case and one that I think we could discuss as
a one-off.  This license was designed to be a general-purpose
license.  We can discuss variants that keep true to the goal
(compatible plugins and extensions) that deal with source.

> Secondly, while I value code review and QA a great deal, your proposal
> appears to add a bunch of /mandatory/ overhead without explaining the
> benefits the project will receive from it. Hudson's quality is very
> high at the moment, measured by fitness for purpose; adding must-do
> steps to the process of creating it must be justified by concrete
> benefits that the volunteers creating it will buy into - otherwise the
> bar for contributions is raised but the motivation to follow the
> labelled process isn't.

I tried to keep that post as short as possible, and since others were
involved in wanting some of these things maybe they can comment, but
the goal of the process is to add some visibility into how things get
built and ensure that as we grow the community and maintain the
quality.

> Lastly, i too haven't signed the SCA, it was never requested, and IIRC
> I have patches in core as well as the various bits in a few plugins -
> including one plugin I started from scratch, and if anyone is signing
> a CA for that, it would be Oracle, thank you very much.

If you checked into core, you should have signed the OCA/SCA.  This is
a good example of our bigger problem.  The process, information and
enforcement that usually goes along with an open source community is
missing with Hudson.  It is what scares off companies from
contributing and even using it internally in some cases.  Our goal is
to bring it closer in alignment with many other open source projects
you might find.  Our initial suggestion was to do something similar to
Eclipse, but that was rejected as too heavyweight, so we focused on
the points you see here in the process proposal.

> Ted, I support Oracle wanting to be part of this community - Sun
> merged with Oracle and you're stepping into some fairly big shoes
> there :). However it would help me a great deal to know what you want
> to achieve with the changes you're proposing.

See above answers.

> You talk about licensing concerns with the technology components, but
> I don't recall seeing any detail about what those concerns are.

The core today has over 10 different open source licenses associated
with it.  Many of which companies likes ours and some of our customers
won't touch (GPL, CDDL, etc.).  I don't want to get into an argument
about why certain licenses are better than others in the eyes of
lawyers, but ideally we tend to lean towards shipping Apache or MIT.
If we were ever to ship a free version of hudson to our customers
(which we want to do), we need the license issues resolved.

> On the trademark side, you say you want to ensure consistency and
> reliability. Hudon has had great success without a trademark; having a
> trademark is obviously not a sufficient condition, and the success so
> far is a demonstration that its not a necessary condition. If you feel
> that its a necessary condition, you are essentially saying that the
> prior stewards of consistency and reliability cannot be trusted to
> continue to do a good job. That makes me sad.

I think Hudson has a good adoption in smaller installations.  I think
if we can get it into more and more larger enterprises that a bigger
market will emerge around it.  I think we are at the tip of the
iceberg with market adoption.  The issues that we brought up came from
us talking to our partners and customers and hearing what they want/
need in order to standardize on and adopt Hudson.

> That said, its up to you if you want to get one. As a new custodian
> though, the onus is on you to demonstrate good faith here: Oracle has
> a history of competing pretty strongly, and I can well understand any
> concerns that other Hudson vendors may feel. (For instance, Oracle's
> selling of support to RHEL users is part of the stage here). Handing
> the trademark to a non-vendor, neutral party whose only interest is in
> the consistency and reliability that users get would be a great way to
> both demonstrate good faith on the more functional issues, and achieve
> your stated goals.

We own lots of trademarks and we don't have very many issues.  I
wasn't involved with the RHEL stuff so I can't comment on that.  As I
mentioned, my team doesn't sell stuff like Hudson and I am not sure
how owning the trademark would give us an advantage with support.

> It may be that there is a crossing-the-chasm thing here - you may have
> analyzed the market and concluded that without some more of the
> trappings of off-the-shelf software, Hudson cannot really explode onto
> the world stage - if thats the case, stand up and support this
> argument! (Its one I would find plausible for many of the things
> you're proposing: not saying its a sufficient argument though ;)).

That is indeed exactly my point.  I don't know if I would call it
"analyzed", but I have talked to a bunch of the users/partners.  I
have recently also asked them comment in these discussions as well.  I
hope some will, but many of them have told me they view these
"community bickering" cases as something they don't have time to get
into, and they just rely on us to support what we recommend to them.
My goal is to get them more involved in the community and to do that,
I believe we need some of the changes that we're talking about here.

> Well, thats about it, I hope this raises some food for thought for you.

It did.  Thanks.  I appreciate you taking the time to read the
proposal and bring up these points.

    -ted

ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

ted
In reply to this post by Andrew Bayer

Hi Andrew,

> What I saw as the underlying problem in our talks earlier still stands -
> there's no guarantee of the independence of the Hudson project from Oracle.
> The naming rights policy you lay out doesn't say who determines what is a
> valid Hudson release in the first place. Who is the final arbiter of that?
> If, for instance, the Hudson developers make a technology decision Oracle
> opposes, does Oracle have the power to keep that change from being
> made/released? As a rule, I'm not comfortable with a de facto assurance that
> Oracle (or any other corporate entity in another context) would have veto
> power over a supposedly independent project. If Oracle retains that power,
> well, it's not an independent project. This is the reason I propose renaming
> - I don't think this project should be beholden to a corporate overlord,
> given the broad range of committers, users, use cases, extensions,
> commercial bundlings, etc.

What about the other side of this argument.   You say that I can
muscle the community because I have the naming rights.  I would say
that am I currently being muscled into giving up the naming rights by
you guys threatening to fork.  That is the balance that exists with
open source.  The community always has the power of forking.  If I
give up the naming rights, then I have nothing left. What would stop
you and Cloudbees from going off in a direction that Oracle and the
rest of the community hated?

I appreciate that up until now a small group of you guys were the
core
of the community and decided on everything.  In the same way that
Oracle is being asked to be part of the community, that is also what
we are asking of you guys.  We just want an open community we can all
work together in as equals.

    -ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Monty Taylor
In reply to this post by ted
On 01/24/2011 07:20 PM, ted wrote:

>
> Hi Rob,
>
>> Possibly the most significant one: Ubuntu (which I contribute to in my
>> spare time (when it exists)) only supports things which can be built
>> from source; things that cannot be built from source get (at best)
>> second class status. A requirement that things not be called 'Hudson'
>> if they are not the byte-for-byte .war file from the hudson website
>> would result in one of a small set of things:
>>  - no Hudson for Ubuntu in the Ubuntu Software Centre
>>  - a package called 'nosduH' or some similar undiscoverable thing (see
>> for instance iceweasel (aka firefox)).
>>  - a package which is disabled by default, bug reports are not
>> accepted on, and users are generally told not to use.
>> It is a strong requirement for Ubuntu that things we ship we be able
>> to bugfix and support. If we ship a Hudson package in a long term
>> support release, we're committing to 5 years of support on it; that
>> means backports, security fixes and so on - we try, for our users,
>> very very very hard not to just dump new upstream releases in during
>> that 5 year period.
>
> It is an interesting use case and one that I think we could discuss as
> a one-off.  This license was designed to be a general-purpose
> license.  We can discuss variants that keep true to the goal
> (compatible plugins and extensions) that deal with source.

As a follow up on this one...

We've had in-depth discussions about getting Hudson in to Ubuntu at the
last two Ubuntu Developer Summits. At the moment, we're stuck on the
problem that it's almost impossible to build from source (given that
building from source in this context ALSO means making sure you have
built-from-source packages of all of the dependencies. In the case of
hudson, I believe this means we'd have to make around 100 new packages
for the dependent jars and their depends.

But, assuming we can solve that problem... we also tend to like to do
things in such a way that we could either add the package to Debian and
get it through the syncing process, or to at least be able to submit
things back up to them. Which brings me around to the reason I started
typing:

The Debian Free Software Guidelines do not allow licenses to only apply
to Debian. So as appreciated as the sentiment is (and I do mean that
honestly) a one-off approach probably won't work.

>> Secondly, while I value code review and QA a great deal, your proposal
>> appears to add a bunch of /mandatory/ overhead without explaining the
>> benefits the project will receive from it. Hudson's quality is very
>> high at the moment, measured by fitness for purpose; adding must-do
>> steps to the process of creating it must be justified by concrete
>> benefits that the volunteers creating it will buy into - otherwise the
>> bar for contributions is raised but the motivation to follow the
>> labelled process isn't.
>
> I tried to keep that post as short as possible, and since others were
> involved in wanting some of these things maybe they can comment, but
> the goal of the process is to add some visibility into how things get
> built and ensure that as we grow the community and maintain the
> quality.
>
>> Lastly, i too haven't signed the SCA, it was never requested, and IIRC
>> I have patches in core as well as the various bits in a few plugins -
>> including one plugin I started from scratch, and if anyone is signing
>> a CA for that, it would be Oracle, thank you very much.
>
> If you checked into core, you should have signed the OCA/SCA.  This is
> a good example of our bigger problem.  The process, information and
> enforcement that usually goes along with an open source community is
> missing with Hudson.

I'm going to disagree quite strongly with that. The process, information
and enforcement that usually goes along with a large corporate is
missing with Hudson. Hudson actually has a great set of process.

>  It is what scares off companies from
> contributing and even using it internally in some cases.  Our goal is
> to bring it closer in alignment with many other open source projects
> you might find.  Our initial suggestion was to do something similar to
> Eclipse, but that was rejected as too heavyweight, so we focused on
> the points you see here in the process proposal.

I think this is going to be one of these places where many of us could
stand in the room and disagree and not get any closer to understanding
each other. (in addition to running a couple of plugins, I also have
patches in the core)

I've written four different following paragraphs to the above, and none
of them seem to be useful. I will sum it up as succinctly as I can by
saying, that it's important to remember that whereas I understand why
_customers_ are important to Oracle and are a large part of Oracle's
definition of the word Community - they do not matter to me. I am not
opposed to Oracle (or CloudBees, for that matter) having customers...
but I do not care about them. I care about the project, not the
product... and I care about Hudson as an Open Source project - not as a
product that happens to be Open Source.

Do with that what you will.

>> Ted, I support Oracle wanting to be part of this community - Sun
>> merged with Oracle and you're stepping into some fairly big shoes
>> there :). However it would help me a great deal to know what you want
>> to achieve with the changes you're proposing.
>
> See above answers.
>
>> You talk about licensing concerns with the technology components, but
>> I don't recall seeing any detail about what those concerns are.
>
> The core today has over 10 different open source licenses associated
> with it.  Many of which companies likes ours and some of our customers
> won't touch (GPL, CDDL, etc.).  I don't want to get into an argument
> about why certain licenses are better than others in the eyes of
> lawyers, but ideally we tend to lean towards shipping Apache or MIT.
> If we were ever to ship a free version of hudson to our customers
> (which we want to do), we need the license issues resolved.
>
>> On the trademark side, you say you want to ensure consistency and
>> reliability. Hudon has had great success without a trademark; having a
>> trademark is obviously not a sufficient condition, and the success so
>> far is a demonstration that its not a necessary condition. If you feel
>> that its a necessary condition, you are essentially saying that the
>> prior stewards of consistency and reliability cannot be trusted to
>> continue to do a good job. That makes me sad.
>
> I think Hudson has a good adoption in smaller installations.  I think
> if we can get it into more and more larger enterprises that a bigger
> market will emerge around it.  I think we are at the tip of the
> iceberg with market adoption.  The issues that we brought up came from
> us talking to our partners and customers and hearing what they want/
> need in order to standardize on and adopt Hudson.

>> That said, its up to you if you want to get one. As a new custodian
>> though, the onus is on you to demonstrate good faith here: Oracle has
>> a history of competing pretty strongly, and I can well understand any
>> concerns that other Hudson vendors may feel. (For instance, Oracle's
>> selling of support to RHEL users is part of the stage here). Handing
>> the trademark to a non-vendor, neutral party whose only interest is in
>> the consistency and reliability that users get would be a great way to
>> both demonstrate good faith on the more functional issues, and achieve
>> your stated goals.
>
> We own lots of trademarks and we don't have very many issues.  I
> wasn't involved with the RHEL stuff so I can't comment on that.  As I
> mentioned, my team doesn't sell stuff like Hudson and I am not sure
> how owning the trademark would give us an advantage with support.
>
>> It may be that there is a crossing-the-chasm thing here - you may have
>> analyzed the market and concluded that without some more of the
>> trappings of off-the-shelf software, Hudson cannot really explode onto
>> the world stage - if thats the case, stand up and support this
>> argument! (Its one I would find plausible for many of the things
>> you're proposing: not saying its a sufficient argument though ;)).
>
> That is indeed exactly my point.  I don't know if I would call it
> "analyzed", but I have talked to a bunch of the users/partners.  I
> have recently also asked them comment in these discussions as well.  I
> hope some will, but many of them have told me they view these
> "community bickering" cases as something they don't have time to get
> into, and they just rely on us to support what we recommend to them.
> My goal is to get them more involved in the community and to do that,
> I believe we need some of the changes that we're talking about here.
>
>> Well, thats about it, I hope this raises some food for thought for you.
>
> It did.  Thanks.  I appreciate you taking the time to read the
> proposal and bring up these points.
>
>     -ted
>
>

ted
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

ted

Hey Monty,

> I think this is going to be one of these places where many of us could
> stand in the room and disagree and not get any closer to understanding
> each other. (in addition to running a couple of plugins, I also have
> patches in the core)

Fair enough.  I don't expect everyone to agree, but I am glad we have
a forum to respectfully voice our opinions and differences.  Just to
clarify, the requirement for anyone contributing to the core to sign
the SCA came from Sun.  It has always been there.  Oracle has similar
practices, but nothing new here.  Neither Sun nor Oracle enforced this
so it was never brought up as an issue.

> I've written four different following paragraphs to the above, and none
> of them seem to be useful. I will sum it up as succinctly as I can by
> saying, that it's important to remember that whereas I understand why
> _customers_ are important to Oracle and are a large part of Oracle's
> definition of the word Community - they do not matter to me. I am not
> opposed to Oracle (or CloudBees, for that matter) having customers...
> but I do not care about them. I care about the project, not the
> product... and I care about Hudson as an Open Source project - not as a
> product that happens to be Open Source.

I understand what you are saying about other people's customers in
general.  I guess the reason I care about my partners and customers in
the context of Hudson is that I see them as potential active members
of the community and I am in favor of growing the community and the
user base. I think a lot more people could benefit from Hudson and I
am trying to get to an environment where that is possible.

    -ted

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Kohsuke Kawaguchi
Administrator
In reply to this post by ted

I posted my take on this at
http://kohsuke.org/2011/01/24/on-oracle-proposal-about-hudson/

On 01/24/2011 03:36 PM, Ted Farrell wrote:

> All,
>
> Sorry for the delay.  I have been in meetings (and not the good kind) since
> 7am today.  I was not able to get final approval to post the actual license
> text, but as promised (and requested) I am posting the summary and process
> docs anyway.  I do have the license in front of me so if people have
> specific questions I can try to answer them in email until I get the ok
> (hopefully in a day or so) to post the actual license.
>
> http://hudson-ci.org/docs/process_summary.html
>
> I am happy to answer any questions or clarify anything if it is unclear.
>   thx.
>
>      -ted
>


--
Kohsuke Kawaguchi                          http://kohsuke.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Alan Harder-2
In reply to this post by ted

On 1/24/11 7:43 PM, ted wrote:
> If I give up the naming rights, then I have nothing left.

You would be able to voice your opinion and contribute code, etc. just like
the rest of the community.

> What would stop you and Cloudbees from going off in a direction that
> Oracle and the rest of the community hated?

Feedback from the community.  Governance board too.

> We just want an open community we can all
> work together in as equals.

Some more equal than others.

     - Alan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Richard Bywater
Hi there

Having read KK's blog post and the information from Ted, I guess I'm a
little confused and so just wanted to try and clarify the position.
(Note that currently I don't have any strong feelings either way and
I'm not up with license terms etc. so forgive me if I don't get things
quite right :) )

It appears from the blog post, the only contentious items appear to be
Oracle trademarking the Hudson name, and the fact that Oracle will
still be collecting CLAs for core.

If this is correct then I'm not sure about the reasons for the big
push to move away from Oracle. As has been stated (and has been
proposed), at any time if Oracle decided to start imposing conditions
on the usage of the name Hudson, then the community could fork at that
point and create a newly named version as long they didn't use the
name Hudson anymore. What would be the issue with leaving the status
quo for now and then forking later if circumstances dictate?

Also it appears in KK's blog, that CLAs would still be collected
albeit with a different master. I'm not 100% sure how this is then any
different to the current situation?

Maybe if someone could list what things KK/Andrew/etc. agree with
Oracle on and what things are still up in the air that would make it
easier to decide on which direction the community should head in?

My 2 cents...
Richard.

On Tue, Jan 25, 2011 at 7:23 PM, Alan Harder <[hidden email]> wrote:

>
> On 1/24/11 7:43 PM, ted wrote:
>>
>> If I give up the naming rights, then I have nothing left.
>
> You would be able to voice your opinion and contribute code, etc. just like
> the rest of the community.
>
>> What would stop you and Cloudbees from going off in a direction that
>> Oracle and the rest of the community hated?
>
> Feedback from the community.  Governance board too.
>
>> We just want an open community we can all
>> work together in as equals.
>
> Some more equal than others.
>
>    - Alan
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

vtintillier
The goal is that Oracle does not have more weight than any other member of the community. In KK proposal, name and CLAs are owned by an independent entity, that has no private interest in Hudson.

The three lines answer of Andrew just before summarize it all in my opinion. Oracle fears it will lose its importance in the community, and try to own the name to keep it, whereas they are very minor contributors to the project.


On Tue, Jan 25, 2011 at 8:47 AM, Richard Bywater <[hidden email]> wrote:
Hi there

Having read KK's blog post and the information from Ted, I guess I'm a
little confused and so just wanted to try and clarify the position.
(Note that currently I don't have any strong feelings either way and
I'm not up with license terms etc. so forgive me if I don't get things
quite right :) )

It appears from the blog post, the only contentious items appear to be
Oracle trademarking the Hudson name, and the fact that Oracle will
still be collecting CLAs for core.

If this is correct then I'm not sure about the reasons for the big
push to move away from Oracle. As has been stated (and has been
proposed), at any time if Oracle decided to start imposing conditions
on the usage of the name Hudson, then the community could fork at that
point and create a newly named version as long they didn't use the
name Hudson anymore. What would be the issue with leaving the status
quo for now and then forking later if circumstances dictate?

Also it appears in KK's blog, that CLAs would still be collected
albeit with a different master. I'm not 100% sure how this is then any
different to the current situation?

Maybe if someone could list what things KK/Andrew/etc. agree with
Oracle on and what things are still up in the air that would make it
easier to decide on which direction the community should head in?

My 2 cents...
Richard.

On Tue, Jan 25, 2011 at 7:23 PM, Alan Harder <[hidden email]> wrote:
>
> On 1/24/11 7:43 PM, ted wrote:
>>
>> If I give up the naming rights, then I have nothing left.
>
> You would be able to voice your opinion and contribute code, etc. just like
> the rest of the community.
>
>> What would stop you and Cloudbees from going off in a direction that
>> Oracle and the rest of the community hated?
>
> Feedback from the community.  Governance board too.
>
>> We just want an open community we can all
>> work together in as equals.
>
> Some more equal than others.
>
>    - Alan
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

Richard Bywater
So just read the CLA and as far as I can see there is nothing in there
that I can tell really says Oracle gains that much weight from
contributions given that the contributor and Oracle share copyright.

Also in Andrew's comments he seems to be worried about Oracle blocking
a release. Given that a release is a combination of commits, and the
commits can be made by any committer (i.e. you don't need Oracle's
permission to commit if you are a committer), then I'm not sure how
Oracle would block a release? Also as stated in the proposal summary,
the source code itself isn't affected by Oracle trying to own the
name, so I'm confused as to why this is such a big issue given one
could fork at any stage?

This isn't meant to sound like I'm pro-Oracle - I'm neutral on the
subject at the moment but I think if a change is going to be made, we
need to understand the rationale behind the various decisions on why
he change is being made.  (Right now the main theme from a lot of
people seems to be "fork because its Oracle" which doesn't seem like a
reason in itself)

:)
Richard.

On Tue, Jan 25, 2011 at 9:22 PM, vtintillier
<[hidden email]> wrote:

> The goal is that Oracle does not have more weight than any other member of
> the community. In KK proposal, name and CLAs are owned by
> an independent entity, that has no private interest in Hudson.
>
> The three lines answer of Andrew just before summarize it all in my opinion.
> Oracle fears it will lose its importance in the community, and try to own
> the name to keep it, whereas they are very minor contributors to the
> project.
>
> On Tue, Jan 25, 2011 at 8:47 AM, Richard Bywater <[hidden email]> wrote:
>>
>> Hi there
>>
>> Having read KK's blog post and the information from Ted, I guess I'm a
>> little confused and so just wanted to try and clarify the position.
>> (Note that currently I don't have any strong feelings either way and
>> I'm not up with license terms etc. so forgive me if I don't get things
>> quite right :) )
>>
>> It appears from the blog post, the only contentious items appear to be
>> Oracle trademarking the Hudson name, and the fact that Oracle will
>> still be collecting CLAs for core.
>>
>> If this is correct then I'm not sure about the reasons for the big
>> push to move away from Oracle. As has been stated (and has been
>> proposed), at any time if Oracle decided to start imposing conditions
>> on the usage of the name Hudson, then the community could fork at that
>> point and create a newly named version as long they didn't use the
>> name Hudson anymore. What would be the issue with leaving the status
>> quo for now and then forking later if circumstances dictate?
>>
>> Also it appears in KK's blog, that CLAs would still be collected
>> albeit with a different master. I'm not 100% sure how this is then any
>> different to the current situation?
>>
>> Maybe if someone could list what things KK/Andrew/etc. agree with
>> Oracle on and what things are still up in the air that would make it
>> easier to decide on which direction the community should head in?
>>
>> My 2 cents...
>> Richard.
>>
>> On Tue, Jan 25, 2011 at 7:23 PM, Alan Harder <[hidden email]>
>> wrote:
>> >
>> > On 1/24/11 7:43 PM, ted wrote:
>> >>
>> >> If I give up the naming rights, then I have nothing left.
>> >
>> > You would be able to voice your opinion and contribute code, etc. just
>> > like
>> > the rest of the community.
>> >
>> >> What would stop you and Cloudbees from going off in a direction that
>> >> Oracle and the rest of the community hated?
>> >
>> > Feedback from the community.  Governance board too.
>> >
>> >> We just want an open community we can all
>> >> work together in as equals.
>> >
>> > Some more equal than others.
>> >
>> >    - Alan
>> >
>> >
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hudson Discussion Summary

vtintillier
Oracle says that everything named Hudson must remain compatible with Hudson plugins. So let's say at some point breaking plugin compatibility is necessary to add one super interesting feature; who has the final word? Oracle because they stated compatibility in their Hudson license? Or a vote by the community? Of course in if such thing happens we can hope that Oracle would be kind enough to follow the community. But what if they just sold Hudson to one of their big customers for millions of dollars? Then they might be tempted to stop such evolution to remain compatible, because at that point they have a new interest in doing this.

And it could happen the other way around. Oracle could want to sell some new feature that imply breaking a lot of other plugins (but they don't care because they do not offer those plugins in their premium package for example) Same thing, who has the final word.

Of course those examples are pure speculation and I have no idea what would be the real actions taken by Oracle in such situations. But the problem is they are the one who own Hudson, and we cannot expect them to always behave kindly. And if forking is of course always possible, I think the sooner the better. For the moment Oracle actions did not had much impact on Hudson (except for infrastructure). So renaming would be more seen like Oracle is forking.

On Tue, Jan 25, 2011 at 9:47 AM, Richard Bywater <[hidden email]> wrote:
So just read the CLA and as far as I can see there is nothing in there
that I can tell really says Oracle gains that much weight from
contributions given that the contributor and Oracle share copyright.

Also in Andrew's comments he seems to be worried about Oracle blocking
a release. Given that a release is a combination of commits, and the
commits can be made by any committer (i.e. you don't need Oracle's
permission to commit if you are a committer), then I'm not sure how
Oracle would block a release? Also as stated in the proposal summary,
the source code itself isn't affected by Oracle trying to own the
name, so I'm confused as to why this is such a big issue given one
could fork at any stage?

This isn't meant to sound like I'm pro-Oracle - I'm neutral on the
subject at the moment but I think if a change is going to be made, we
need to understand the rationale behind the various decisions on why
he change is being made.  (Right now the main theme from a lot of
people seems to be "fork because its Oracle" which doesn't seem like a
reason in itself)

:)
Richard.

On Tue, Jan 25, 2011 at 9:22 PM, vtintillier
<[hidden email]> wrote:
> The goal is that Oracle does not have more weight than any other member of
> the community. In KK proposal, name and CLAs are owned by
> an independent entity, that has no private interest in Hudson.
>
> The three lines answer of Andrew just before summarize it all in my opinion.
> Oracle fears it will lose its importance in the community, and try to own
> the name to keep it, whereas they are very minor contributors to the
> project.
>
> On Tue, Jan 25, 2011 at 8:47 AM, Richard Bywater <[hidden email]> wrote:
>>
>> Hi there
>>
>> Having read KK's blog post and the information from Ted, I guess I'm a
>> little confused and so just wanted to try and clarify the position.
>> (Note that currently I don't have any strong feelings either way and
>> I'm not up with license terms etc. so forgive me if I don't get things
>> quite right :) )
>>
>> It appears from the blog post, the only contentious items appear to be
>> Oracle trademarking the Hudson name, and the fact that Oracle will
>> still be collecting CLAs for core.
>>
>> If this is correct then I'm not sure about the reasons for the big
>> push to move away from Oracle. As has been stated (and has been
>> proposed), at any time if Oracle decided to start imposing conditions
>> on the usage of the name Hudson, then the community could fork at that
>> point and create a newly named version as long they didn't use the
>> name Hudson anymore. What would be the issue with leaving the status
>> quo for now and then forking later if circumstances dictate?
>>
>> Also it appears in KK's blog, that CLAs would still be collected
>> albeit with a different master. I'm not 100% sure how this is then any
>> different to the current situation?
>>
>> Maybe if someone could list what things KK/Andrew/etc. agree with
>> Oracle on and what things are still up in the air that would make it
>> easier to decide on which direction the community should head in?
>>
>> My 2 cents...
>> Richard.
>>
>> On Tue, Jan 25, 2011 at 7:23 PM, Alan Harder <[hidden email]>
>> wrote:
>> >
>> > On 1/24/11 7:43 PM, ted wrote:
>> >>
>> >> If I give up the naming rights, then I have nothing left.
>> >
>> > You would be able to voice your opinion and contribute code, etc. just
>> > like
>> > the rest of the community.
>> >
>> >> What would stop you and Cloudbees from going off in a direction that
>> >> Oracle and the rest of the community hated?
>> >
>> > Feedback from the community.  Governance board too.
>> >
>> >> We just want an open community we can all
>> >> work together in as equals.
>> >
>> > Some more equal than others.
>> >
>> >    - Alan
>> >
>> >
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Hudson Discussion Summary

Bruce Zu

This let me think of a case many years ago:   IBM thinkpad T42 and T43 gone with wind ,  and Lenovo  thinkpad T60 coming  with the same name  ‘thinkpad’.

 

 

 

Thank you!
Best Regards!


Bruce Zu
CNBJ ,CI&CM

Telephone No.:  +86 10 5865 6171   

 Fax No.:                +86 10 5865 6008  

 Mobile No.:        +86 186 010 89005   

 Office Address:  Sony Ericsson Mobile Communication ( China )Co.,Ltd.

                                  27F,Sony Ericsson Building,No.16,Guangshun South street, Chaoyang District,Beijing(100102)

E-Mail Address:  [hidden email]

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of vtintillier
Sent: Tuesday, January 25, 2011 5:00 PM
To: [hidden email]
Subject: Re: Hudson Discussion Summary

 

Oracle says that everything named Hudson must remain compatible with Hudson plugins. So let's say at some point breaking plugin compatibility is necessary to add one super interesting feature; who has the final word? Oracle because they stated compatibility in their Hudson license? Or a vote by the community? Of course in if such thing happens we can hope that Oracle would be kind enough to follow the community. But what if they just sold Hudson to one of their big customers for millions of dollars? Then they might be tempted to stop such evolution to remain compatible, because at that point they have a new interest in doing this.

 

And it could happen the other way around. Oracle could want to sell some new feature that imply breaking a lot of other plugins (but they don't care because they do not offer those plugins in their premium package for example) Same thing, who has the final word.

 

Of course those examples are pure speculation and I have no idea what would be the real actions taken by Oracle in such situations. But the problem is they are the one who own Hudson, and we cannot expect them to always behave kindly. And if forking is of course always possible, I think the sooner the better. For the moment Oracle actions did not had much impact on Hudson (except for infrastructure). So renaming would be more seen like Oracle is forking.

 

On Tue, Jan 25, 2011 at 9:47 AM, Richard Bywater <[hidden email]> wrote:

So just read the CLA and as far as I can see there is nothing in there
that I can tell really says Oracle gains that much weight from
contributions given that the contributor and Oracle share copyright.

Also in Andrew's comments he seems to be worried about Oracle blocking
a release. Given that a release is a combination of commits, and the
commits can be made by any committer (i.e. you don't need Oracle's
permission to commit if you are a committer), then I'm not sure how
Oracle would block a release? Also as stated in the proposal summary,
the source code itself isn't affected by Oracle trying to own the
name, so I'm confused as to why this is such a big issue given one
could fork at any stage?

This isn't meant to sound like I'm pro-Oracle - I'm neutral on the
subject at the moment but I think if a change is going to be made, we
need to understand the rationale behind the various decisions on why
he change is being made.  (Right now the main theme from a lot of
people seems to be "fork because its Oracle" which doesn't seem like a
reason in itself)

:)
Richard.


On Tue, Jan 25, 2011 at 9:22 PM, vtintillier
<[hidden email]> wrote:


> The goal is that Oracle does not have more weight than any other member of
> the community. In KK proposal, name and CLAs are owned by
> an independent entity, that has no private interest in Hudson.
>
> The three lines answer of Andrew just before summarize it all in my opinion.
> Oracle fears it will lose its importance in the community, and try to own
> the name to keep it, whereas they are very minor contributors to the
> project.
>
> On Tue, Jan 25, 2011 at 8:47 AM, Richard Bywater <[hidden email]> wrote:
>>
>> Hi there
>>
>> Having read KK's blog post and the information from Ted, I guess I'm a
>> little confused and so just wanted to try and clarify the position.
>> (Note that currently I don't have any strong feelings either way and
>> I'm not up with license terms etc. so forgive me if I don't get things
>> quite right :) )
>>
>> It appears from the blog post, the only contentious items appear to be
>> Oracle trademarking the Hudson name, and the fact that Oracle will
>> still be collecting CLAs for core.
>>
>> If this is correct then I'm not sure about the reasons for the big
>> push to move away from Oracle. As has been stated (and has been
>> proposed), at any time if Oracle decided to start imposing conditions
>> on the usage of the name Hudson, then the community could fork at that
>> point and create a newly named version as long they didn't use the
>> name Hudson anymore. What would be the issue with leaving the status
>> quo for now and then forking later if circumstances dictate?
>>
>> Also it appears in KK's blog, that CLAs would still be collected
>> albeit with a different master. I'm not 100% sure how this is then any
>> different to the current situation?
>>
>> Maybe if someone could list what things KK/Andrew/etc. agree with
>> Oracle on and what things are still up in the air that would make it
>> easier to decide on which direction the community should head in?
>>
>> My 2 cents...
>> Richard.
>>
>> On Tue, Jan 25, 2011 at 7:23 PM, Alan Harder <[hidden email]>
>> wrote:
>> >
>> > On 1/24/11 7:43 PM, ted wrote:
>> >>
>> >> If I give up the naming rights, then I have nothing left.
>> >
>> > You would be able to voice your opinion and contribute code, etc. just
>> > like
>> > the rest of the community.
>> >
>> >> What would stop you and Cloudbees from going off in a direction that
>> >> Oracle and the rest of the community hated?
>> >
>> > Feedback from the community.  Governance board too.
>> >
>> >> We just want an open community we can all
>> >> work together in as equals.
>> >
>> > Some more equal than others.
>> >
>> >    - Alan
>> >
>> >
>
>

 

1234
Loading...