Hudson Discussion Summary
Locked
1234
1234
 
|
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
|
Re: Hudson Discussion Summary
|
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 |
Re: Hudson Discussion Summary
|
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, |
Re: Hudson Discussion Summary
|
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. |
|
|
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. |
|
|
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. |
Re: Hudson Discussion Summary
|
|
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.. > |
Re: Hudson Discussion Summary
|
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 |
Re: Hudson Discussion Summary
|
|
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:
|
|
|
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 |
|
|
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 |
Re: Hudson Discussion Summary
|
|
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 > > |
|
|
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 |
Re: Hudson Discussion Summary
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/ |
Re: Hudson Discussion Summary
|
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 |
Re: Hudson Discussion Summary
|
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 > > |
Re: Hudson Discussion Summary
|
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 |
Re: Hudson Discussion Summary
|
|
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 >> > >> > > > |
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 |
|
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!
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 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
> 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 >> > >> > > > |
«
Return to Jenkins dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |