we likely need a CLA that all contributors sign before being granted git and wiki write access. I have suggested agreeing to license instructions to the OPF and also agreeing to license under LGPLv3 (general) and GPLv2 (for qemu/linux).
it is already on the wiki (FAQ) and GFDL as well, but not the CLA. needs discussion as whilst everyone in FOSS thinks "copyright" they are woefully ill-educated on patents and trademarks.
I think we should have the license be (SPDX syntax): LGPL-3.0+ OR GPL-2.0 OR GFDL-1.3-no-invariants-or-later OR (whatever OPF needs) This means authors provide the necessary licenses for *all* of LGPLv3+ and GPLv2 and GFDLv1.3+ (with no invariant sections or front/back text, since those aren't allowed to be modified) and OPF licensing, but downstream users may select *any* subset of those licenses and completely ignore the rest. LGPLv3 provides the required patent license. GPLv2 for linux/qemu. GFDL by luke's request. (this is inspired by Rust which has Apache-2.0 OR MIT as their license, likely because of Apache 2.0's patent license and MIT's simplicity)
(In reply to Jacob Lifshay from comment #2) > I think we should have the license be (SPDX syntax): > LGPL-3.0+ OR GPL-2.0 OR GFDL-1.3-no-invariants-or-later OR (whatever OPF > needs) it needs to be an AND not an OR. otherwise there is a choice not to release under one explicit chosen license. contributor agreements are no licenses.
(In reply to Luke Kenneth Casson Leighton from comment #3) > (In reply to Jacob Lifshay from comment #2) > > I think we should have the license be (SPDX syntax): > > LGPL-3.0+ OR GPL-2.0 OR GFDL-1.3-no-invariants-or-later OR (whatever OPF > > needs) > > it needs to be an AND not an OR. otherwise there is a choice not to > release under one explicit chosen license. it needs to be OR, not AND, because having *the license* be A OR B means any contributors must license under each and every license for *all* licenses listed in order to satisfy the whole OR expression (allow downstream users to be the ones that pick which license(s) to follow). if it were AND, that would instead restrict *users* meaning anyone using any of our code would have to follow all stipulations of all licenses *combined*, which realistically means they have major problems since some of those licenses have contradicting clauses such as GPL vs. GFDL: http://lists.debian.org/debian-legal/2003/04/msg00258.html the contributor license agreement would say contributors have to agree to license under the *combined license expression*: LGPL-3.0+ OR GPL-2.0 OR ...
(In reply to Jacob Lifshay from comment #4) > it needs to be OR, not AND, because having *the license* be A OR B means any > contributors must license under each and every license for *all* licenses > listed in order to satisfy the whole OR expression (allow downstream users > to be the ones that pick which license(s) to follow). that's a horribly confusing a definition of OR. not a good idea. plus... actually, yes if someone then makes a derivative work and gets confused, we have a problem. > if it were AND, that > would instead restrict *users* meaning anyone using any of our code would > have to follow all stipulations of all licenses *combined*, which > realistically means they have major problems since some of those licenses > have contradicting clauses such as GPL vs. GFDL: > http://lists.debian.org/debian-legal/2003/04/msg00258.html documentation is different from source code so it would be mutex-either-or. > the contributor license agreement would say contributors have to agree to > license under the *combined license expression*: > LGPL-3.0+ OR GPL-2.0 OR ... use of SPDX is not helping here given the "re-definition" of the meaning of "OR". needs more thought.
what SPDX OR means is like in Firefox's old triple-license (which afaict is MPL-1.1 OR GPL-2.0+ OR LGPL-2.1+): https://github.com/mozilla/gecko-dev/blob/caae487a245201724aa1e3248896e1233ccdab2f/toolkit/content/license.html - The contents of this file are subject to the Mozilla Public License Version - 1.1 (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.mozilla.org/MPL/ <snip> - Alternatively, the contents of this file may be used under the terms of - either the GNU General Public License Version 2 or later (the "GPL"), or - the GNU Lesser General Public License Version 2.1 or later (the "LGPL"), - in which case the provisions of the GPL or the LGPL are applicable instead - of those above. If you wish to allow use of your version of this file only - under the terms of either the GPL or the LGPL, and not to allow others to - use your version of this file under the terms of the MPL, indicate your - decision by deleting the provisions above and replace them with the notice - and other provisions required by the GPL or the LGPL. If you do not delete - the provisions above, a recipient may use your version of this file under - the terms of any one of the MPL, the GPL or the LGPL.
(In reply to Luke Kenneth Casson Leighton from comment #5) > (In reply to Jacob Lifshay from comment #4) > > > it needs to be OR, not AND, because having *the license* be A OR B means any > > contributors must license under each and every license for *all* licenses > > listed in order to satisfy the whole OR expression (allow downstream users > > to be the ones that pick which license(s) to follow). > > that's a horribly confusing a definition of OR. mostly just that you're thinking of it in terms of what contributors have to do, but it's designed to be worded in terms of what downstream users have to do. > not a good idea. we just have to state it in a non-confusing way. > documentation is different from source code so it would be mutex-either-or. we really should have the docs (and everything else we can) under the same set of licenses since that allows us to copy stuff from/to the docs without license issues