Licensing policy for apps developed by Fedora Infrastructure now in effect

[Toshio Kuratomi]

Over the past few months, Fedora Infrastructure has been discussing
having a consistent set of licenses for applications and scripts we
create for Fedora.  The goals of doing this were to

* Be able to share code among the various programs that we write.
* Not have our libraries force a specific license on the apps that we write.
* Not have conflicting licenses between our apps and our libraries
* Have a clear understanding of the steps we must take whenever we want
to move code from an application under one license to a library under a
different one.
* Protect the code we write from being taken proprietary (note, this is
not the same for every author. Mirrormanager, for instance, is under the
MIT/X11 License).
* Be able to stay compliant with licenses within our production,
staging, and publictest environments

At last week's meeting we made a decision about which licenses would
best fit our needs.  The results are recorded here:
  https://fedoraproject.org/wiki/Infrastructure_Licensing

The basics are:
* license code that is meant to be used as a library as LGPLv2+.
* license code that's meant to be used as an application as GPLv2+.
* If we want to write something and use another license we should
discuss it to figure out how it's going to impact us and whether there's
a better way to achieve our goals first.

Most of our apps are currently under GPLv2(only) so we're going to be
working to change the licensing on those apps over time to reflect GPLv2
or later.  If you find something that we've written that's not under
GPLv2+ (or LGPLv2+) that you want to use, please let us know so we can
either get to work on making the license match the guidelines or let you
know why it's not being changed.

The one other thing for Infrastructure developers and System Admins to
note in the Policy is the section on handling AGPLv3 applications.
During the discussions about whether to use AGPLv3+ for our web
applications we found and delimited many issues that need to be
addressed when deploying AGPLv3+ licensed code.  The aGPL portion of the
policy is our first attempt at keeping us compliant with any code that
is under this license.  Highlights are:

* Apps deployed to production under AGPL must be deployed from RPMs.
Any hotfixes to those apps must have the patch in a ticket in trac on
http://fedorahosted.org/fedora-infrastructure with the keyword HOTFIX.
* Any AGPL app deployed in infrastructure must have links in the footer
to the fedora-infrastructure SRPM repo and the trac query that pulls up
our hotfixes so that people can find the exact source that we're running
at any given time.
* Staging must follow the same rules regarding SRPM and hotfixes.  Once
again, failing to link to the exact source for what we have running
would put us out of compliance.
* No AGPL apps can be hosted on publictest boxes at this time as
publictest boxes are intended for development and the high rate of
change in development is not conducive for constantly updating RPMS or
patches in trac.  If there's demand for publictest hosting of AGPL apps
we'll need to design some method of restricting who can access the
applications running there to satisfy the legal requirements.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20090903/1685d0fd/attachment.bin