content/projectIndependence.mdtext - comdev-site - Git at Google

 Title: Project Independence
 Notice:    Licensed to the Apache Software Foundation (ASF) under one
            or more contributor license agreements.  See the NOTICE file
            distributed with this work for additional information
            regarding copyright ownership.  The ASF licenses this file
            to you under the Apache License, Version 2.0 (the
            "License"); you may not use this file except in compliance
            with the License.  You may obtain a copy of the License at
            .
              http://www.apache.org/licenses/LICENSE-2.0
            .
            Unless required by applicable law or agreed to in writing,
            software distributed under the License is distributed on an
            "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
            KIND, either express or implied.  See the License for the
            specific language governing permissions and limitations
            under the License.

 While not all aspects of the Apache Way are practiced the same way by
 all projects at the ASF, there are a number of rules and policies that Apache
 projects are required to follow – things like complying with PMC
 [release voting][1], [legal policy][2], [brand policy][3],
 using [mailing lists][4], etc., which are [documented in various places][5].

 A community is not merely a set of rules; it is also a set of behaviors
 that are expressed by the participants when interacting within that
 community.  While the ASF is happy to host
 many different styles of project communities, there are some core behaviors that
 are expected and required of any Apache project.

 A primary purpose of the basic requirements the ASF places on its
 projects are to help ensure long-lived and stable projects by having
 a broad enough community to maintain the project even in the potential
 absence of any individual volunteer or any sea change at a major vendor
 in that area. The [Apache project governance model][7] is explicitly based
 on a diverse community. This is different from other governance models,
 like the “benevolent dictator” idea or the often corporate-backed model
 that Eclipse uses.

 **Please Note:** These requirements apply to *Apache projects*: that is,
 to individual committer and PMC behaviors and actions within the context
 of collaboratively building software products *at The Apache
 Software Foundation*.  By definition here, "Apache project" means the collaborative
 activity of building a software release called an "Apache product" here at the ASF.

 The ASF and all Apache projects welcome the public to broadly re-use any released
 Apache products for virtually any purpose. Third party use like this is governed by
 our permissive [Apache License][6] and by our [formal trademark policy][3].
 While many third parties create Apache licensed
 software, only software released from the ASF itself is properly called "Apache software".

 ## Apache projects are independent

 Apache projects are controlled by their Project Management Committee
 (PMC).  A PMC represents the consensus view of the individual PMC
 members by discussion and [VOTE]ing on project releases and new committers.
 A PMC's actions within their Apache project community and management of
 their project must be in the interest of that consensus and consistent with
 the ASF's mission of producing software for the public good.

 There are also
 certain expectations of diversity within a PMC; the board may apply extra scrutiny to PMCs
 with low diversity (i.e. PMCs that are dominated by individuals with a common employer).
 Similarly, the ASF does not allow corporations to participate directly in
 Apache project management or other governance activities at the ASF; only individuals.

 There are several important aspects to this independence: project management, project use by end users, and project code availability.

 ## Apache projects are managed independently

 Apache projects must be managed independently, and PMCs must ensure that they are acting in the best interests of the project as a whole. Note that it is similarly important that the PMC clearly show this independence within their project community. The perception of existing and new participants within the community that the PMC is run independently and without favoring any specific third parties over others is important, to allow new contributors to feel comfortable both joining the community and contributing their work. A community that obviously favors one specific vendor in some exclusive way will often discourage new contributors from competing vendors, which is an issue for the long term health of the project.

 ## Apache products may be used independently

 All Apache projects must release their code under the [Apache License][6], which clearly specifies the minimum restrictions that users of Apache software must agree to. Apache software is all about being able to use it for virtually whatever our users want: open source, proprietary, secret: we’re happy to have users take our software (although not our name) for virtually any purpose. While our legal guidelines allow certain other software licenses to be used for specific dependencies, the software we release always uses our license.

 Extending this idea, users of Apache software should be able to find our software, learn how to use it, and actually apply it to all its common use cases solely by going to the Apache project’s own website. Apache projects should provide sufficient documentation, install features, basic user help (through mailing lists) and services for the common use cases to the user, without them having to rely on third parties. It is important that our users can both make use of our software freely – both in terms of not having to pay for the software, as well as not having to worry about IP claims or other more restrictive licenses on either the software or the configurations or other common materials required to actually use the software.

 ## Apache projects are branded as Apache projects

 Similar to the requirement that users can use Apache projects independently; so should
 users understand that when they download and use an Apache product that it is from
 Apache and not from nor related to any third party.  That is, the user experience when
 using an Apache project in it's common use cases should clearly show the Apache project
 branding in the UI or in whatever other ways users would normally interact with the product.

 Ensuring that Apache projects are branded as Apache projects is critical to the longevity
 of our communities.  As users use the software, they may discover bugs, or have ideas for
 improving the software, documentation, or other aspects of the project. When a user chooses
 to share these ideas or improvements, ensuring that the actual product they are using
 is clearly branded as coming from Apache ensures that they are likely to contribute
 those ideas and improvements back to Apache and our projects.

 The ASF welcomes third parties who build software that builds atop, improves,
 plugs into, or works with our many Apache products.  However any such third party software
 product must be clearly branded as such, and must follow our [formal trademark policy][3].
 In this way, users clearly understand the different sources for software products such as
 Apache Foo (from the ASF) versus BigCo SuperThing, Powered By Apache Foo (from BigCo).

 ## Apache projects are non-commercial

 The ASF’s mission is to produce software for the public good. All [Apache software is always available for free][8], and solely under the Apache License. While our projects manage the technical implementation of their individual software products independently, Apache software is released from the ASF, and is always meant to serve the public good.

 We’re happy to have third parties, including for-profit corporations, take our software and use it for their own purposes – even when in some cases it may technically compete with Apache software. However it is important in these cases to ensure that the brand and reputation of the Apache project is not misused by third parties for their own purposes. It is important for the longevity and community health of our projects that they get the appropriate credit for producing our freely available software.


   [1]: http://www.apache.org/dev/release.html
   [2]: http://www.apache.org/legal/
   [3]: http://www.apache.org/foundation/marks/
   [4]: http://www.apache.org/dev/#mail
   [5]: https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different
   [6]: http://www.apache.org/licenses/LICENSE-2.0.html
   [7]: http://www.apache.org/foundation/governance/
   [8]: http://www.apache.org/free/
	Title: Project Independence
	Notice: Licensed to the Apache Software Foundation (ASF) under one
	or more contributor license agreements. See the NOTICE file
	distributed with this work for additional information
	regarding copyright ownership. The ASF licenses this file
	to you under the Apache License, Version 2.0 (the
	"License"); you may not use this file except in compliance
	with the License. You may obtain a copy of the License at
	.
	http://www.apache.org/licenses/LICENSE-2.0
	.
	Unless required by applicable law or agreed to in writing,
	software distributed under the License is distributed on an
	"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
	KIND, either express or implied. See the License for the
	specific language governing permissions and limitations
	under the License.

	While not all aspects of the Apache Way are practiced the same way by
	all projects at the ASF, there are a number of rules and policies that Apache
	projects are required to follow – things like complying with PMC
	[release voting][1], [legal policy][2], [brand policy][3],
	using [mailing lists][4], etc., which are [documented in various places][5].

	A community is not merely a set of rules; it is also a set of behaviors
	that are expressed by the participants when interacting within that
	community. While the ASF is happy to host
	many different styles of project communities, there are some core behaviors that
	are expected and required of any Apache project.

	A primary purpose of the basic requirements the ASF places on its
	projects are to help ensure long-lived and stable projects by having
	a broad enough community to maintain the project even in the potential
	absence of any individual volunteer or any sea change at a major vendor
	in that area. The [Apache project governance model][7] is explicitly based
	on a diverse community. This is different from other governance models,
	like the “benevolent dictator” idea or the often corporate-backed model
	that Eclipse uses.

	Please Note: These requirements apply to Apache projects: that is,
	to individual committer and PMC behaviors and actions within the context
	of collaboratively building software products *at The Apache
	Software Foundation*. By definition here, "Apache project" means the collaborative
	activity of building a software release called an "Apache product" here at the ASF.

	The ASF and all Apache projects welcome the public to broadly re-use any released
	Apache products for virtually any purpose. Third party use like this is governed by
	our permissive [Apache License][6] and by our [formal trademark policy][3].
	While many third parties create Apache licensed
	software, only software released from the ASF itself is properly called "Apache software".

	## Apache projects are independent

	Apache projects are controlled by their Project Management Committee
	(PMC). A PMC represents the consensus view of the individual PMC
	members by discussion and [VOTE]ing on project releases and new committers.
	A PMC's actions within their Apache project community and management of
	their project must be in the interest of that consensus and consistent with
	the ASF's mission of producing software for the public good.

	There are also
	certain expectations of diversity within a PMC; the board may apply extra scrutiny to PMCs
	with low diversity (i.e. PMCs that are dominated by individuals with a common employer).
	Similarly, the ASF does not allow corporations to participate directly in
	Apache project management or other governance activities at the ASF; only individuals.

	There are several important aspects to this independence: project management, project use by end users, and project code availability.

	## Apache projects are managed independently

	Apache projects must be managed independently, and PMCs must ensure that they are acting in the best interests of the project as a whole. Note that it is similarly important that the PMC clearly show this independence within their project community. The perception of existing and new participants within the community that the PMC is run independently and without favoring any specific third parties over others is important, to allow new contributors to feel comfortable both joining the community and contributing their work. A community that obviously favors one specific vendor in some exclusive way will often discourage new contributors from competing vendors, which is an issue for the long term health of the project.

	## Apache products may be used independently

	All Apache projects must release their code under the [Apache License][6], which clearly specifies the minimum restrictions that users of Apache software must agree to. Apache software is all about being able to use it for virtually whatever our users want: open source, proprietary, secret: we’re happy to have users take our software (although not our name) for virtually any purpose. While our legal guidelines allow certain other software licenses to be used for specific dependencies, the software we release always uses our license.

	Extending this idea, users of Apache software should be able to find our software, learn how to use it, and actually apply it to all its common use cases solely by going to the Apache project’s own website. Apache projects should provide sufficient documentation, install features, basic user help (through mailing lists) and services for the common use cases to the user, without them having to rely on third parties. It is important that our users can both make use of our software freely – both in terms of not having to pay for the software, as well as not having to worry about IP claims or other more restrictive licenses on either the software or the configurations or other common materials required to actually use the software.

	## Apache projects are branded as Apache projects

	Similar to the requirement that users can use Apache projects independently; so should
	users understand that when they download and use an Apache product that it is from
	Apache and not from nor related to any third party. That is, the user experience when
	using an Apache project in it's common use cases should clearly show the Apache project
	branding in the UI or in whatever other ways users would normally interact with the product.

	Ensuring that Apache projects are branded as Apache projects is critical to the longevity
	of our communities. As users use the software, they may discover bugs, or have ideas for
	improving the software, documentation, or other aspects of the project. When a user chooses
	to share these ideas or improvements, ensuring that the actual product they are using
	is clearly branded as coming from Apache ensures that they are likely to contribute
	those ideas and improvements back to Apache and our projects.

	The ASF welcomes third parties who build software that builds atop, improves,
	plugs into, or works with our many Apache products. However any such third party software
	product must be clearly branded as such, and must follow our [formal trademark policy][3].
	In this way, users clearly understand the different sources for software products such as
	Apache Foo (from the ASF) versus BigCo SuperThing, Powered By Apache Foo (from BigCo).

	## Apache projects are non-commercial

	The ASF’s mission is to produce software for the public good. All [Apache software is always available for free][8], and solely under the Apache License. While our projects manage the technical implementation of their individual software products independently, Apache software is released from the ASF, and is always meant to serve the public good.

	We’re happy to have third parties, including for-profit corporations, take our software and use it for their own purposes – even when in some cases it may technically compete with Apache software. However it is important in these cases to ensure that the brand and reputation of the Apache project is not misused by third parties for their own purposes. It is important for the longevity and community health of our projects that they get the appropriate credit for producing our freely available software.


	[1]: http://www.apache.org/dev/release.html
	[2]: http://www.apache.org/legal/
	[3]: http://www.apache.org/foundation/marks/
	[4]: http://www.apache.org/dev/#mail
	[5]: https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different
	[6]: http://www.apache.org/licenses/LICENSE-2.0.html
	[7]: http://www.apache.org/foundation/governance/
	[8]: http://www.apache.org/free/