From 32eea0cf49ab96ba6385f02c83808578a7cab6bb Mon Sep 17 00:00:00 2001 From: Brian Rosmaita Date: Thu, 21 Jul 2022 12:38:49 -0400 Subject: [PATCH] Add Legal Issues FAQ Bring the wiki page content under version control and incorporate it into the Project Team Guide. Change-Id: Ieb66c48aa420b9c3920e503376f260456dff3ad9 --- doc/source/index.rst | 1 + doc/source/legal-issues-faq.rst | 189 ++++++++++++++++++++++++++++++++ 2 files changed, 190 insertions(+) create mode 100644 doc/source/legal-issues-faq.rst diff --git a/doc/source/index.rst b/doc/source/index.rst index 3b8dd17..7b9a3f2 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -36,6 +36,7 @@ Contents: glossary deprecation technical-guides/index + legal-issues-faq Indices and tables diff --git a/doc/source/legal-issues-faq.rst b/doc/source/legal-issues-faq.rst new file mode 100644 index 0000000..759f280 --- /dev/null +++ b/doc/source/legal-issues-faq.rst @@ -0,0 +1,189 @@ +================ +Legal Issues FAQ +================ + +The `legal-discuss@lists.openstack.org +`_ +mailing list is a forum for questions that have a legal aspect to them. These +questions may concern (for example) licensing, third party packages, +contributor agreement questions and trademark issues. The list will be used to +build into an ad-hoc knowledge base in the form of this FAQ about those thorny +legal issues that most commonly affect the OpenStack project. + +Opinions documented here do not constitute legal advice from the OpenStack +Foundation or anyone else. + +Frequently Asked Questions +========================== + +.. contents:: + :depth: 1 + :local: + :backlinks: none + +NOTICE Files +------------ + +Q: Should we include NOTICE files in OpenStack projects? + +A: If a NOTICE file exists in a project, the Apache License requires that +derivative works include the attribution notices from the file. This could be +helpful for a number of purposes - (a) ensuring an attribution to the OpenStack +project gets included in derivative works and (b) helping distributors of +derivative works to include any required attribution notices for third party +code included in the project. However, neither of these issues are deemed +significant or important enough to warrant the cost of maintaining the files or +requiring distributors to include an OpenStack project attribution notice. + +For the full background, `see this thread +`_. + +.. _incorporating: + +Incorporating BSD/MIT Licensed Code +----------------------------------- + +Q: If we include BSD or MIT licensed code in an OpenStack project, how best +should we comply with the terms of the license? + +A: The `2 core clauses in the BSD license +`_ +make some demands about the retention of copyright notices, the license and +disclaimers in both source and binary distributions of the code. The +`MIT license +`_ +contains similar requirements. Probably the easiest thing to do when +incorporating BSD or MIT licensed code is to copy the copyright/license header +from the source file into the destination file, as well as copying the +copyright notice, license and disclaimer into the toplevel LICENSE file with a +brief explanation of which code is under that license. + +For the full background, `see this email +`_. + +Copyright Headers +----------------- + +Q: Generally speaking, what's the idea with copyright headers in source files +and what should be included in them? + +A: Copyright notices are not required in order to create or protect your +copyright rights, but they may nonetheless be useful. (Also, copyright notices +from code taken from outside of OpenStack will typically +:ref:`need to be preserved ` +as a requirement of the license of that external code.) We have some overall +copyright guidance on this page, and discussions about copyright headers in +source files continue on mailing lists. In general, + +* All references to "OpenStack LLC" can be changed to "OpenStack Foundation" + because copyrights held by OpenStack LLC were transferred to the Foundation + when the new entity was created. (However, note that in some cases "OpenStack + LLC" or "OpenStack Foundation" appear to have been included in copyright + notices `in error + `_ + by contributors not employed by Rackspace or the Foundation at the relevant + time period.) + +* If the content has been substantially updated in 2013, add the year to the + change. + +* Always keep the license in the header. + +* We do not yet have guidance for when to add or remove a copyright header in + source files. + +* Reviews of copyright headers may vary across projects. + +* For documentation, refer to `Documentation/Copyright + `_. + +Note that the combination of our use of a CLA and per-file copyright notices +from individuals or companies may be creating a confusing +`duplicative licensing situation +`_. + +Q: Should **"All rights reserved"** follow a copyright notice? + +A: It is not necessary to follow a copyright notice with the words "All rights +reserved". While it is harmless, some people regard "All rights reserved" as +being inappropriate in conjunction with an open source license grant. Therefore +it is recommended that developers not include "All rights reserved" in +copyright headers. + +Copyright Notices in Blueprints +------------------------------- + +Q: Should I include a copyright notice in a blueprint? + +A: `No +`_. + +OpenStack Foundation Copyright Headers +-------------------------------------- + +Q: Should I Include an OpenStack Foundation copyright header in my code? + +A: **No**, unless you are an employee or contractor of the OpenStack +Foundation. Most existing OpenStack Foundation copyright headers you see in +OpenStack code are likely associated with code from Rackspace developers before +the OpenStack Foundation existed when OpenStack LLC was a wholly owned +subsidiary of Rackspace. Once the foundation was formed, all OpenStack LLC +assets (including copyrights) were transferred to the foundation and the +copyright headers were updated. It's likely the only valid reason for OpenStack +Foundation copyright notices on new code these days is where the code was +authored by an employee or contractor of the foundation. + +For the full background, `consult this thread +`_. + +New Project Names +----------------- + +Q: What sort of things should I bear in mind when choosing a new project name? + +A: Some of the non-Apache-specific material in the Apache Software Foundation's +guidelines `Choosing names for ASF projects +`_ +may be helpful. See also the last +paragraph of `section 5.1 +`_ +of SFLC's *A Legal Issues Primer for Open Source and Free Software Projects*. + +A few categories that are best avoided when coming up with a non-generic +project name are: surnames, ubiquitous words, famous trademarks in other +fields, and references to famous things (e.g., superheroes, car names, movie +characters, famous people). + +Legal Concerns Over Project Names +--------------------------------- + +Q: I am concerned that there may be legal issues around an existing OpenStack +project name. What should I do? + +A: FIXME + +Licensing of library dependencies +--------------------------------- + +Q: Is it OK for OpenStack Projects to use GPL or AGPL libraries? + +A: No, see the `Licensing requirements +`_ +page. + +.. note:: + + This question is about GPL libraries. LGPL libraries would not require + such discussion. + +Licensing of non-library dependencies +------------------------------------- + +Q: Is it OK for OpenStack Projects to require AGPLv3 licensed technologies for +production deployment? + +A: This issue has come up in the context of Ceilometer and Marconi requiring +MongoDB. The concern has been raised that some users will be unwilling to +deploy any AGPLv3 technologies, but we're still trying to understand those +concerns in detail. See `this thread +`_.