[PROPOSAL] Libcloud Project
Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project seeks to build a last community around cloud API interoperability, and is not fascinated with any short term gains of being associated with the Apache Brand. Documentation TODO: links to related material on Cloud APIs/interop (?) Initial Source Initial source is contained completely inside the libcloud github repository. External Dependencies * zope.interface * For Python = 2.5, a JSON Parser such as SimpleJSON is required. Cryptography Uses standard Python APIs for SSL/HTTPS. Required Resources Mailing lists *
RE: [PROPOSAL] Libcloud Project
This looks interesting, I'd be happy to help Mentor and have already put my name down. Gav... -Original Message- From: Paul Querna [mailto:p...@querna.org] Sent: Tuesday, 27 October 2009 5:00 PM To: general@incubator.apache.org Subject: [PROPOSAL] Libcloud Project Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project seeks to build a last community around cloud API interoperability, and is not fascinated with any short term gains of being
Re: [PROPOSAL] Libcloud Project
+1, sounds really interesting, I'd be happy to be a mentor too if you need another. ...ant On Tue, Oct 27, 2009 at 8:15 AM, Gavin ga...@16degrees.com.au wrote: This looks interesting, I'd be happy to help Mentor and have already put my name down. Gav... -Original Message- From: Paul Querna [mailto:p...@querna.org] Sent: Tuesday, 27 October 2009 5:00 PM To: general@incubator.apache.org Subject: [PROPOSAL] Libcloud Project Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project
Re: [PROPOSAL] Libcloud Project
On Tue, Oct 27, 2009 at 6:59 AM, Paul Querna p...@querna.org wrote: I would like to propose incubating the existing Libcloud project to join the ASF Cool! I will try to make the time to help out a little; I'm interested in this space :) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
Yo. Looking pretty cool! Sorry, but, few tidbits inline... On Fri, Oct 23, 2009 at 3:53 PM, Nicholas L Gallardo nlgal...@us.ibm.com wrote: The Wink community voted on and approved the release of Apache Wink 1.0. We would now like to request the approval of the Incubator PMC for this release. Podling vote thread: http://www.mail-archive.com/wink-...@incubator.apache.org/msg02060.html The Maven staging area is at: https://repository.apache.org/content/repositories/wink-staging-002/ You're not going to get a +1 from me on all those artifacts - its way too much work for me to look through all of them [1]. I looked just at the distributions... The distributions are in: https://repository.apache.org/content/repositories/wink-staging-002/org/apache/wink/apache-wink/1.0-incubating/ The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Fwd: [PROPOSAL] Libcloud Project
+1 Add me as Mentor if you need someone more :-) Cheers Jean-Frederic Original Message Subject: [PROPOSAL] Libcloud Project Date: Mon, 26 Oct 2009 23:59:36 -0700 From: Paul Querna p...@querna.org Reply-To: general@incubator.apache.org To: general@incubator.apache.org Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project seeks to build a last community around cloud API interoperability, and is not fascinated with any short term gains of being associated with the Apache Brand. Documentation TODO: links to related material on Cloud APIs/interop (?) Initial Source
[PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
hi, we would like to propose Openmeetings project to join the incubator. Full Proposal: http://wiki.apache.org/incubator/OpenmeetingsProposal Quick summary: OpenMeetings is Web Conferencing application that fits into educational or business sector. You can make conference sessions in different room-types with up to 100 peoples in a Room. It contains all main features of Web Conferencing: Audio/Video, Whiteboard, Screen Sharing, Chat and Moderation System. It is translated into more then 20 languages and its a basic goal of OpenMeetings to be easy to embed into existing environments. It already uses many of Apache Technologies like Tomcat, Mina, Velocity, Commons, ... You may find all existing documents and further material on the GoogleCode pages: http://code.google.com/p/openmeetings/ We appreciate any feedback and comments on the proposal. sebastian wagner -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com
Re: [VOTE] Release Wink 1.0
On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk bryant@gmail.com wrote: The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. I think you're suggesting a different LICENSE/NOTICE for source versus binary distributions. Yep, I see how it looks like thatthough maybe I'm _really_ suggesting a source-only distribution :-) Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. Whenever you violate that SHOULD, you are turning lazyness/sloppiness into a mess for your users. For example, with this current wink distribution, you are (appear to be?) passing on a lot of CDDL obligations down to wink users, which is annoying to users that care about such things. If all your user wants to do is copy/paste the glue code from GzipHandler, that's a rather heavy license to wade through. Similarly, that user of that GzipHandler code now has to copy/paste the entire contents of the NOTICE file. Do you really want to place a burden on your users like that? I did some random checking looking at some source versus binary Apache project distributions (incubator and non-incubator) and as far as I can tell, they kept their same LICENSE and NOTICE files even though they were not re-distributing the dependency binaries in the source archive. Don't mean to say we should just follow the crowd, but I don't think this is standard practice unless another thread has a viewpoint on this. Unfortunately, most apache projects are not as good at following policies as they should be, and most engineers (including me! :-) ) are not nearly as good at applying legal rules and guidelines as they should be. http://www.apache.org/dev/release.html#license What Are The Requirements To Distribute Other Artifacts In Addition To The Source Package? ... Nothing in this section is meant to supersede the requirements defined here and here that all releases be primarily based on a signed source package. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. I see varying degrees of attribution to slf4j in other Apache (incubating and non-incubating) projects (some have none, some have a line). The slf4j line was kept from the Wink 0.1 release. IMHO, this is not a release blocker, but we can remove it in a future release if it is the right thing to do. Fortunately we have quite a clear rule on this topic these days, so no opinions are necessary: http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable for normal documentation. For background color, here's an earlier thread on this list (which is where I learned about the existence of that clear rule): http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
Hi Leo, Thanks for the links. One general comment I have is that I understand this is part of the incubation process (and no offense intended to Leo since obviously taking energy and time for this) but if I can't look and see if other Apache projects are doing things the right way, I think we should have more examples of what goes in the NOTICE and LICENSE files and points out licenses/situations/projects/wording that require that they be put in LICENSE/NOTICE files and not. It seems to be a common sticking point on this list for incubator projects. I would put up a patch for the website but obviously I am still learning. On Tue, Oct 27, 2009 at 2:37 PM, Leo Simons m...@leosimons.com wrote: On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk bryant@gmail.com wrote: The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. I think you're suggesting a different LICENSE/NOTICE for source versus binary distributions. Yep, I see how it looks like thatthough maybe I'm _really_ suggesting a source-only distribution :-) Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. Whenever you violate that SHOULD, you are turning lazyness/sloppiness into a mess for your users. For example, with this current wink distribution, you are (appear to be?) passing on a lot of CDDL obligations down to wink users, which is annoying to users that care about such things. If all your user wants to do is copy/paste the glue code from GzipHandler, that's a rather heavy license to wade through. Similarly, that user of that GzipHandler code now has to copy/paste the entire contents of the NOTICE file. Do you really want to place a burden on your users like that? I wouldn't, however just out of curiosity, how does this apply with Section 4.4 of the Apache license? If the Work includes a NOTICE text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works;... I would consider that a copied portion of just the Apache Wink code to be a Derivative Work, and none of the other NOTICE attributions (CDDL) apply to the user (hence excluding those notices so their NOTICE file is relatively brief). I'm not a lawyer but just want some clarification for this use case for personal knowledge. I did some random checking looking at some source versus binary Apache project distributions (incubator and non-incubator) and as far as I can tell, they kept their same LICENSE and NOTICE files even though they were not re-distributing the dependency binaries in the source archive. Don't mean to say we should just follow the crowd, but I don't think this is standard practice unless another thread has a viewpoint on this. Unfortunately, most apache projects are not as good at following policies as they should be, and most engineers (including me! :-) ) are not nearly as good at applying legal rules and guidelines as they should be. Agreed. http://www.apache.org/dev/release.html#license What Are The Requirements To Distribute Other Artifacts In Addition To The Source Package? ... Nothing in this section is meant to supersede the requirements defined here and here that all releases be primarily based on a signed source package. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. I see varying degrees of attribution to slf4j in other Apache (incubating and non-incubating) projects (some have none, some have a line). The slf4j line was kept from the Wink 0.1 release. IMHO, this is not a release blocker, but we can remove it in a future release if it is the right thing to do. Fortunately we have quite a clear rule on this topic these days, so no opinions are necessary: http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable for normal documentation. For background color, here's an earlier thread on this list (which is
Re: [VOTE] Release Wink 1.0
On Tue, Oct 27, 2009 at 9:23 PM, Bryant Luk bryant@gmail.com wrote: Hi Leo, Thanks for the links. One general comment I have is that I understand this is part of the incubation process (and no offense intended to Leo since obviously taking energy and time for this) but if I can't look and see if other Apache projects are doing things the right way, I think we should have more examples of what goes in the NOTICE and LICENSE files and points out licenses/situations/projects/wording that require that they be put in LICENSE/NOTICE files and not. It seems to be a common sticking point on this list for incubator projects. I would put up a patch for the website but obviously I am still learning. On Tue, Oct 27, 2009 at 2:37 PM, Leo Simons m...@leosimons.com wrote: On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk bryant@gmail.com wrote: The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. I think you're suggesting a different LICENSE/NOTICE for source versus binary distributions. Yep, I see how it looks like thatthough maybe I'm _really_ suggesting a source-only distribution :-) Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. Whenever you violate that SHOULD, you are turning lazyness/sloppiness into a mess for your users. For example, with this current wink distribution, you are (appear to be?) passing on a lot of CDDL obligations down to wink users, which is annoying to users that care about such things. If all your user wants to do is copy/paste the glue code from GzipHandler, that's a rather heavy license to wade through. Similarly, that user of that GzipHandler code now has to copy/paste the entire contents of the NOTICE file. Do you really want to place a burden on your users like that? I wouldn't, however just out of curiosity, how does this apply with Section 4.4 of the Apache license? If the Work includes a NOTICE text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works;... I would consider that a copied portion of just the Apache Wink code to be a Derivative Work, and none of the other NOTICE attributions (CDDL) apply to the user (hence excluding those notices so their NOTICE file is relatively brief). I'm not a lawyer but just want some clarification for this use case for personal knowledge. I did some random checking looking at some source versus binary Apache project distributions (incubator and non-incubator) and as far as I can tell, they kept their same LICENSE and NOTICE files even though they were not re-distributing the dependency binaries in the source archive. Don't mean to say we should just follow the crowd, but I don't think this is standard practice unless another thread has a viewpoint on this. Unfortunately, most apache projects are not as good at following policies as they should be, and most engineers (including me! :-) ) are not nearly as good at applying legal rules and guidelines as they should be. Agreed. http://www.apache.org/dev/release.html#license What Are The Requirements To Distribute Other Artifacts In Addition To The Source Package? ... Nothing in this section is meant to supersede the requirements defined here and here that all releases be primarily based on a signed source package. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. I see varying degrees of attribution to slf4j in other Apache (incubating and non-incubating) projects (some have none, some have a line). The slf4j line was kept from the Wink 0.1 release. IMHO, this is not a release blocker, but we can remove it in a future release if it is the right thing to do. Fortunately we have quite a clear rule on this topic these days, so no opinions are necessary: http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable
Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
On Tue, Oct 27, 2009 at 4:22 AM, Sebastian Wagner seba.wag...@gmail.com wrote: hi, we would like to propose Openmeetings project to join the incubator. Full Proposal: http://wiki.apache.org/incubator/OpenmeetingsProposal Quick summary: OpenMeetings is Web Conferencing application that fits into educational or business sector. You can make conference sessions in different room-types with up to 100 peoples in a Room. It contains all main features of Web Conferencing: Audio/Video, Whiteboard, Screen Sharing, Chat and Moderation System. It is translated into more then 20 languages and its a basic goal of OpenMeetings to be easy to embed into existing environments. It already uses many of Apache Technologies like Tomcat, Mina, Velocity, Commons, ... You may find all existing documents and further material on the GoogleCode pages: http://code.google.com/p/openmeetings/ Sounds cool! I do have a question about how the project uses Red5 Media Server. Red5 is licensed under the LGPL, how exactly does OpenMeetings use it? Thanks, Paul - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
On Tue, Oct 27, 2009 at 9:23 PM, Bryant Luk bryant@gmail.com wrote: Thanks for the links. One general comment I have is that I understand this is part of the incubation process (and no offense intended to Leo since obviously taking energy and time for this) but if I can't look and see if other Apache projects are doing things the right way, I think we should have more examples of what goes in the NOTICE and LICENSE files and points out licenses/situations/projects/wording that require that they be put in LICENSE/NOTICE files and not. It seems to be a common sticking point on this list for incubator projects. I would put up a patch for the website but obviously I am still learning. Yeah it's painful isn't it? How to get the legal stuff right remains surprisingly difficult after all these years. Help making it easier is always very welcome! [1] Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. ... just out of curiosity, how does this apply with Section 4.4 of the Apache license? Ooh, you're getting into this now, eh? Good :-) IANAL, I don't really know. I suspect the precise nitty-gritty legal case is actually a little more lenient than our policies. As in, even if legally all is sound whatever way, our release policies try to enforce some additional clarity and consistency to make things as easy as possible for the user. http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable for normal documentation. For background color, here's an earlier thread on this list (which is where I learned about the existence of that clear rule): http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e Thanks for the link to the information. However, I would like to get a consensus to make sure that we should not be attributing SLF4J at all. In an artifact that does not contain SLF4J (like your source distro), do not attribute (at all). In an artifact that does contain SLF4J (like your binary distro), well, see https://issues.apache.org/jira/browse/LEGAL-59 to figure out that no-one is really that sure. If you look at HTTPD, it has the expat license (which is MIT) inside its LICENSE file: http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE but no mention about it in its NOTICE file: http://svn.apache.org/repos/asf/httpd/httpd/trunk/NOTICE Is that ok? Probably. Is that the *only* right way? Not so sure. My personal rule is that when in doubt do what Roy voted +1 on is not a bad strategy when it comes to licensing stuff [2]. which I believe have been used in recent release votes. I'm fine with deleting/re-wording the attributions (afterall, less for us to maintain) and hope not too troublesome but I would like some consensus to make sure that this and future releases are right (without quotes ;-) ). Please note, I didn't actually vote on the release, I just pointed out a few things that probably ought to change. I didn't vote because I don't want to go and review all those very many binaries (or the build process that creates them) and I'm not familiar enough with the codebase to somehow know that all those binaries are somehow ok. If I had thought these minor tidbits that I raise are enough to actually vote -1, I would've made that clear, sorry that it wasn't. Even if I _did_ vote, releases are majority votes, and 2 +1 beats a single -1. Its just you need 3 votes. In other words, all you need is one more +1 :) ciao, Leo [1] Oh, and for reference, my first encounter with apache licensing policy was when someone had imported the entire codebase of some non-apache project into apache CVS, stripped all the license headers including copyright info, and replaced them with apache ones. We got a polite note from the original projects' owners to fix that pretty please. We got spanked around pretty bad for that one at the following apachecon, and then we all had lots of beer :) [2] there is another rule, have whatever Greg is having, though less of it - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
On 27 Oct 2009, at 11:22, Sebastian Wagner wrote: hi, we would like to propose Openmeetings project to join the incubator. Full Proposal: http://wiki.apache.org/incubator/OpenmeetingsProposal Wow, two new proposals in a day! Would be good to get a feeling for what this is. Is www.openmeetings.de a genuine free-for-all to sign up and play? And what would be a good time of day to find life there? -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT] [VOTE] Graduate Lucene.Net as a subproject under Apache Lucene
Jukka Zitting wrote: George Aroush wrote: Anyone?! Sorry for the silence. What you need to do in practice is pretty much listed in [1]. See [2] for an example of how Tika requested the mailing list migration. [1] http://incubator.apache.org/guides/graduation.html#project-first-steps [2] https://issues.apache.org/jira/browse/INFRA-1796 Also Clutch tries to steer you. See the Steps section below the main table: http://incubator.apache.org/clutch.html#h-Graduate -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Libcloud Project
+1... There has been few new, accepted proposals lately... On Tue, Oct 27, 2009 at 2:59 PM, Paul Querna p...@querna.org wrote: Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project seeks to build a last community around cloud API interoperability, and is not fascinated with any short term gains of being associated with the Apache Brand. Documentation TODO: links to related material on Cloud APIs/interop (?) Initial Source Initial source is contained completely inside the libcloud github
Re: [PROPOSAL] Libcloud Project
+1 the idea is very interesting On Tue, Oct 27, 2009 at 9:56 PM, Niclas Hedhman nic...@hedhman.org wrote: +1... There has been few new, accepted proposals lately... On Tue, Oct 27, 2009 at 2:59 PM, Paul Querna p...@querna.org wrote: Hi, I would like to propose incubating the existing Libcloud project to join the ASF: Proposal Wiki: http://wiki.apache.org/incubator/LibcloudProposal Libcloud is a unified Python API around many common cloud services provider, and I believe it could benefit greatly by joining the Apache Software Foundation. I also believe the ASF needs more Python projects, and more projects involved in the developing cloud infrastructure. We still need a few mentors, so feel free to signup :-) We would appreciate feedback and comments on the proposal. Full proposal is bellow. Thanks, Paul Libcloud, a unified interface to the cloud Abstract libcloud (http://www.libcloud.org) is a pure python client library for interacting with many of the popular cloud server providers. It was created to make it easy for developers to build products that work between any of the services that it supports. Proposal * Provide unified API for manipulating servers instances across many hosting providers who provide an API to manipulate instances. Current API includes: list, reboot, create, destroy, list images, list sizes. * (future) Provide utilities for manipulating and creating server images in many formats. (See the independent Stacklet project for ideas) * (future) Provide unified API for storing large objects on popular hosting provider storage APIs. Background While there are some projects to create open standards for interoperability within the cloud, most have failed to gain widespread adoption. Libcloud takes the approach of exposing a unified API to cover multiple vendor's APIs, and in the future to support standard APIs, assuming they become prevalent. Rationale There is a strong need in the developing cloud infrastructure for a community supported, high quality, and vendor independent tool set for managing servers and their resources. When new servers are just an API call away, traditional infrastructure models are changing quickly. Having a good library built around Apache's values and tradition will enable new server infrastructure to evolve much more quickly. Initial Goals Libcloud is an existing open source project, with patches from many different contributors. We view the moving to Apache as a way to improve this community, and look into future APIs around creating server images and large object storage. Current Status Libcloud is already open source under the ASL 2.0: * Libcloud Website http://www.libcloud.org * Libcloud Mailing Lists http://groups.google.com/group/libcloud * Libcloud Source Control http://github.com/cloudkick/libcloud Meritocracy Libcloud has involvement from members of both the ASF and other open source projects. Communication is driven by both IRC and E-Mail lists. Community Currently libcloud has several contributors, but not a large user community other than a few companies. We would like to increase our userbase as part of the incubator process. Core Developers Alex Polvi who wrote most of the original code is familiar with open source from working at OSUOSL and at Mozilla. Tom Davis drove much of the re factoring of the initial code base. Jed Smith, Ivan Meredith, Jeremy Orem, Jerry Chen and Paul Querna (ASF member) have all contributed mainly to developing provider specific drivers. Alignment Currently there are not many Apache communities involved with cloud computing or python based infrastructure. We believe introducing such a community is a good thing for the Apache Software Foundation. Known Risks Orphaned products libcloud is being used actively by Cloudkick to develop services. It is a core part of our ongoing infrastructure improvements. Inexperience with Open Source libcloud was open sourced in July 2009, during OSCON. Core contributors include former employees of Mozilla and an ASF member. Homogenous Developers Much of the initial development was done by Cloudkick, but much of the core design was re-factored by the community, and many of the drivers for each provider have been contributed by 3rd parties. Reliance on Salaried Developers The majority, but not all, of the developers are paid by their employer to work on libcloud at this time. Relationships with Other Apache Products Libcloud doesn't share many attributes with existing Apache projects due to it being in Python and addressing a new need. A Excessive Fascination with the Apache Brand Libcloud project seeks to build a last community around cloud API interoperability, and is not fascinated with any short term gains of being associated with the Apache Brand. Documentation TODO: links to related material on Cloud
