[Freeipa-devel] contribution policy draft

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/15/2009 12:46 AM, Karsten Wade wrote:
> Here's my simple thinking:
> 
> 1. We get this to say what we *mean* it to say:
> 
>    http://freeipa.org/page/User:Quaid/Contribution_policy_(draft)
> 
> 2. We pass that back to Red Hat Legal, saying, "These are the policies
>    we want contributions to be under; it doesn't need to be a CLA.  Can
>    you help us word this so it is a sufficient replacement for the
>    CLA."
> 
> Here is the page where I've gathered requirements so far; the policy
> draft is transcluded, too.  I wrote the policy draft from my
> experience with Fedora Project policy and borrowing liberally from the
> ideas in the Wikipedia Terms of Use[1].
> 
> http://freeipa.org/page/User:Quaid/Contribution_policy_(draft)
> 
> What is missing?
> 
> What is sufficient for you, as contributors, to know your work is
> covered for being free and open forevermore?
> 
> Thanks - Karsten
> 
> [1] http://wikimediafoundation.org/wiki/Terms_of_Use
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

Karsten, I'd also like to put together something similar for the SSSD
contribution page (not currently existing in any useful form). The SSSD
has some different licensing requirements, however. While all portions
of the server should be GPL (version debatable), we have several shared
libraries that need to be LGPL, and we also have a nebulous set of
plugins that are loaded by server-processes*. These last present a
somewhat troublesome legal question.

We need to figure out how to license contributions so that end-users are
allowed to create back-end plugins that may or may not be open-source
(for example, a company might decide to produce a closed-source backend
to the SSSD to support their one-time password device). We need to
ensure that this is possible within the license.


* For clarification, in the SSSD service model, we have business logic
performed in several "data provider" backend services. These are
separate, small processes that handle some basic setup (such as hooking
into the main Data Provider process) and then loads a plugin shared
object that must expose certain functions that handle all of the
business logic for a particular authentication or authorization feature.

My concern is that neither the GPL nor the LGPL would be acceptable for
the data provider backend services, because the plugins would have to be
considered derivative works (which is not acceptable for some potential
users).
- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkpdr/YACgkQeiVVYja6o6MNzwCeP/ETwn0iyyFi7q8peMWp15wj
3iwAn0SBdXTMzbN+51+JEOfYvFryFYt7
=7q5h
-----END PGP SIGNATURE-----