Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
On Wed, May 6, 2015 at 4:06 AM Emma Gordon (projectcalico.org) e...@projectcalico.org wrote: If fuel plugin code is checked into a stackforge repository (as suggested in the fuel plugin wiki https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code? Disclaimer, I'm not a lawyer this not legal advice. The authors own the work (code) according local assignment rules and the Berne convention. This would be treated the same as any other work. The Authors can decide what rights they may want people with regards to copy-right (and other intellectual property rights), hence the licenses that we pass around with opensource projects to clarify the author(s) intent. Additional authors or contributors to the work can further describe their own license on their part of the work (as they hold their own copyright) but these are usually not accepted by the maintainers of a work. To that end, you don't have to use the Apache 2.0 License on your plugin if you don't desire it. It could however cause the plugin to see limited use. The point of plugins is that this in your control. I would also point out that your plugin could easily contain multiple licenses depending on what you are including. I'm working on a way to easily identify this with the plugins metadata. This can occur multiple ways as there are many parts in a plugin. a) there is the data describing how the plugin interacts with fuel. All of this data is highly structured and has little IP (usually the wording you use for the text fields is it) b) any configuration management code you use to apply the plugin and its settings. This could include your pure code, or even multiple works from others, for example puppet modules. c) Packages that you need to include as part of the plugin package to ensure they can be found. These could each have their own license and even carry GPL licensed parts. In these cases I'd recommend adding a LICENSES file describing the locations where items may change license (similar to any other programs Open Source Notice file.) from what ever is written on in the license string in the plugin metadata.yaml. As I noted above, I'm working to get this incorporated into the data we present on the plugins repo page. (Likely by pointing to this file in the metadata, but it's not settled yet) Is there a contributor license agreement to sign? (For example, contributors to OpenStack would sign this https://review.openstack.org/static/cla.html) The Openstack CLA is not required for Fuel, and is not obligatory. You again have control here and simply configure your gerrit settings for your project as you see fit. Thanks, Emma __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
If fuel plugin code is checked into a stackforge repository (as suggested in the fuel plugin wiki https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code? Is there a contributor license agreement to sign? (For example, contributors to OpenStack would sign this https://review.openstack.org/static/cla.html) Thanks, Emma __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code?
On 2015-05-06 11:02:42 + (+), Emma Gordon (projectcalico.org) wrote: If fuel plugin code is checked into a stackforge repository (as suggested in the fuel plugin wiki https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code? I am not a lawyer, but my understanding is that the individual copyright holders mentioned in comments at the tops of various files, listed in an AUTHORS file (if included) and indicated within the repository's Git commit history retain rights over their contributions in a project relying on the Apache License (or those rights may belong to their individual respective employers in a work-for-hire situation as well). Is there a contributor license agreement to sign? (For example, contributors to OpenStack would sign this https://review.openstack.org/static/cla.html) If Fuel is planning to apply for inclusion in OpenStack, then it may make sense to get all current and former contributors to its source repositories to agree to the OpenStack Individual Contributor License Agreement. Note that it does _not_ change the ownership of the software (copyrights), it's intended to simply reinforce the OpenStack Foundation's ability to continue to redistribute the software under the Apache License by affirming that the terms of the license are applied correctly and intentionally. More detailed questions are probably best posed to the legal-disc...@lists.openstack.org mailing list, or to your own private legal representation. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fuel][Plugin] Contributor license agreement for fuel plugin code?
. There are not. The error code set was based around a specific expected web browser / website model from 20 years ago. I honestly think we'd be better served by limiting our use of non 200 or 400 codes to really narrow conditions (the ones that you'd expect from the browser interaction pattern). This would approach the whole problem from the least surprise perspective. 404 - resource doesn't exist (appropriate for GET /foo/ID_NUMBER where the thing isn't there) 403 - permissions error. Appropriate for a resource that exists, but you do not have enough permissions for it. I.e. it's an admin URL or someone else's resource. All other client errors, just be a 400. And use the emerging error reporting json to actually tell the client what's going on. -Sean On 05/05/2015 09:48 PM, Alex Xu wrote: From API-WG guideline, exceed quota should be 403 https://github.com/openstack/api-wg/blob/master/guidelines/http.rst 2015-05-06 3:30 GMT+08:00 Chen CH Ji jiche...@cn.ibm.com mailto:jiche...@cn.ibm.com: In doing patch [1], A suggestion is submitted that we should return 400 (bad Request) instead of 403 (Forbidden) I take a look at [2], seems 400 is not a good candidate because /'//The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. //'/ may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji ? ? Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com mailto:jiche...@cn.ibm.com Phone: +86-10-82454158 tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net -- Message: 16 Date: Wed, 6 May 2015 11:02:42 + From: Emma Gordon (projectcalico.org) e...@projectcalico.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Cc: Joe Marshall joe.marsh...@metaswitch.com Subject: [openstack-dev] [Fuel][Plugin] Contributor license agreement for fuel plugin code? Message-ID: 0365813da4f34a468c57038eaa5f396fe387a...@enficsmbx1.datcon.co.uk Content-Type: text/plain; charset=us-ascii If fuel plugin code is checked into a stackforge repository (as suggested in the fuel plugin wiki https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code? Is there a contributor license agreement to sign? (For example, contributors to OpenStack would sign this https://review.openstack.org/static/cla.html) Thanks, Emma -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/06c39ae9/attachment-0001.html -- Message: 17 Date: Wed, 6 May 2015 12:11:06 +0100 (BST) From: Chris Dent chd...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova] Which error code should we return when OverQuota Message-ID: alpine.OSX.2.11.1505061159290.9820@seed.local Content-Type: text/plain; charset=utf-8; Format=flowed On Wed, 6 May 2015, Sean Dague wrote: All other client errors, just be a 400. And use the emerging error reporting json to actually tell the client what's going on. Please do not do this. Please use the 4xx codes as best as you possibly can. Yes, they don't always match, but there are several of them for reasons? and it is usually possible to find one that sort of fits. Using just 400 is bad for a healthy HTTP ecosystem. Sure, for the most part people are talking to OpenStack through official clients but a) what happens when they aren't, b) is that the kind of world we want? I certainly don't. I want a world where the HTTP APIs that OpenStack and other services present actually use HTTP and allow a diversity of clients (machine and human). Using
