search

AMNS / Nightingale

Nightingale music notation software.
Mozilla Public License 2.0
11 stars 3 forks source link

License #17

Closed chirgwin closed 12 years ago

chirgwin commented 12 years ago

Determine open source software license for Nightingale. Should be decided by July 9, 2012. Also should apply to NightingaleCocoa.

michel-slm commented 12 years ago

Hi both,

Having reviewed several open source projects, either for inclusion in Fedora or when I consider using them in my projects, here are several questions we can consider, to help guide the choice:

  1. Is monetization a goal? This influences whether to pick a permissive license (BSD/MIT, Apache), or stronger licenses that apply transitively to modifications as well (if the modification distributed): MPL/CDDL (license applies within file boundaries), EPL/LGPL (license applies within modules) and GPL (license applies to derivative work as well)
  2. Do we care about explicit patent language? GPLv3 and Apache explicitly mention software patents, while it's implicit in GPLv2, and BSD/MIT is silent on the issue
  3. Do we require copyright reassignment? (related to #1). Sun/Oracle required it, so does Canonical (Ubuntu); Red Hat's Fedora project has the most liberal solution I've seen, where individual contributors retain their copyrights but the project gets a license grant: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
  4. Compatibility with any existing open-source libraries we might want to use. e.g. MPL before version 2 is not compatible with (L)GPL; EPL is not compatible with (L)GPL -- IANAL, but it seems that you can use LGPL components in an EPL project, and vice versa (explicitly stating this exception), but if you use a mix of LGPL and EPL libraries, you might need permission from their authors. It's a mess); Apache 2.0 is compatible with GPL only starting from GPLv3. And of course GPLv2 is not compatible with GPLv3 ...

There is a reasonably comprehensive list here with more details: http://fedoraproject.org/wiki/Licensing:Main#Software_License_List

donbyrd commented 12 years ago

Extremely helpful. Thanks, Michel! What a mess all this is.

FYI, your message apparently did not go to Geoff, but I'll cc him on this -- and David Gottlieb, our other participant so far.

See comments below; I'd much appreciate feedback from anyone.

On Mon, 25 Jun 2012 20:49:54 -0700, Michel Alexandre Salim reply@reply.github.com wrote:

Hi both,

Having reviewed several open source projects, either for inclusion in Fedora or when I consider using them in my projects, here are several questions we can consider, to help guide the choice:

  1. Is monetization a goal? This influences whether to pick a permissive license (BSD/MIT, Apache), or stronger licenses that apply transitively to modifications as well (if the modification distributed): MPL/CDDL (license applies within file boundaries), EPL/LGPL (license applies within modules) and GPL (license applies to derivative work as well)

By "monetization", I assume you mean "possibly making money". The answer to that is definitely "maybe" :-) , so we probably don't want to be permissive, at least for now.

  1. Do we care about explicit patent language? GPLv3 and Apache explicitly mention software patents, while it's implicit in GPLv2, and BSD/MIT is silent on the issue

Ugh. Software patents are really stupid. But it seems like a good idea to say something about them, doesn't it?

  1. Do we require copyright reassignment? (related to #1). Sun/Oracle required it, so does Canonical (Ubuntu); Red Hat's Fedora project has the most liberal solution I've seen, where individual contributors retain their copyrights but the project gets a license grant: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

I don't understand the implications of this offhand, but will think about it.

  1. Compatibility with any existing open-source libraries we might want to use. e.g. MPL before version 2 is not compatible with (L)GPL; EPL is not compatible with (L)GPL -- IANAL, but it seems that you can use LGPL components in an EPL project, and vice versa (explicitly stating this exception), but if you use a mix of LGPL and EPL libraries, you might need permission from their authors. It's a mess); Apache 2.0 is compatible with GPL only starting from GPLv3. And of course GPLv2 is not compatible with GPLv3 ...

The main lesson I learned from my experience with Variations2 was to be wary of the GPL. At least one (DjVu) and probably more of the 30 or so FOSS components we wanted to use wasn't GPL v2 compatible, and -- based on the compatibility info in the Fedora page -- it looks like GPL v3 isn't much different. And who knows at this point what FOSS libraries we might want to use?!? So I continue to be anti-GPL.

There is a reasonably comprehensive list here with more details: http://fedoraproject.org/wiki/Licensing:Main#Software_License_List

This is amazing! I did most of the research on software licensing for IU's Variations2 project, and I thought I'd at least heard of most of the open-source licenses in existence; maybe so, but that was in 2005, and a lot has happened since then.

THanks again, Michel. Comments, anyone?

--DAB

Reply to this email directly or view it on GitHub: https://github.com/AMNS/Nightingale/issues/17#issuecomment-6566369

Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics & Music Indiana University, Bloomington

michel-slm commented 12 years ago

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

Hi Don, all,

On 06/26/2012 09:57 PM, Don Byrd wrote:

Extremely helpful. Thanks, Michel! What a mess all this is.

FYI, your message apparently did not go to Geoff, but I'll cc him on this -- and David Gottlieb, our other participant so far.

Hmm, Geoff opened the GitHub issue, so I'm assuming he does get Cc:ed on updates. I think it's just that GitHub's email notification system let you reply to a pre-generated address, and add any replies sent there to the issue itself, thus only that random-looking address shows up on the email.

See comments below; I'd much appreciate feedback from anyone. Further commented with some clarifications, after that I'll stop hogging the discussion :)

  1. Do we care about explicit patent language? GPLv3 and Apache explicitly mention software patents, while it's implicit in GPLv2, and BSD/MIT is silent on the issue

Ugh. Software patents are really stupid. But it seems like a good idea to say something about them, doesn't it?

Right. And we want to avoid the faux pas Google did when they open-sourced the VP8 video codec as WebM -- they initially went BSD but with an Apache-like patent clause, and after getting negative feedback about introducing an untested new license variant, finally went with standard BSD and decoupled the patent language.

As a small player, I guess the defensive patent language in Apache (I'll just use the Fedora short-name for it, ASL 2.0 -- I trust nobody here will confuse it with the unrelated IRC terminology) or LGPL/GPL v3 wouldn't hurt -- it basically states that contributors automatically license, non-exclusively and for free, any patent they held that is needed by their code contribution.

If such contributors later sue us for infringement, any patent license they get as part of the software (thus, Nightingale) is automatically revoked, so effectively they can no longer distribute the software. Something like this happened several years ago over the RAMBus memory technology -- one of the companies involved in standardizing it later turned around and started trying to recoup royalty payments. Needless to say, almost nobody used the technology now (I think Sony's PS2 used it - but I can't remember for sure now. And you have the debacle of companies as big as Microsoft being found to infringe MP3 patents years after its invention - company A buys company B and discovers some patents that would apply that are not being monetized yet!

  1. Do we require copyright reassignment? (related to #1). Sun/Oracle required it, so does Canonical (Ubuntu); Red Hat's Fedora project has the most liberal solution I've seen, where individual contributors retain their copyrights but the project gets a license grant: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

I don't understand the implications of this offhand, but will think about it.

Some companies like having the right to relicense the software -- thus, for example, MySQL is available under GPL as well as under a proprietary commercial license -- but to do that, they need to either own the entire code base (and thus requiring external contributors to sign away their rights) or to at least secure some rights to those contributions. Full copyright reassignment tends to be unpopular -- it's moderately acceptable when a trustworthy organization requires it (the Free Software Foundation, for instance - though like you, I have a mild case of FSF/RMS/GPL allergy). Less so when it's Sun/Oracle (MySQL, OpenOffice -- for many years Linux vendors maintain out-of-tree patches to OpenOffice, later becoming LibreOffice, partly because of the copyright reassignment requirement, and partly because Sun ran the project without sufficient cooperation with outside contributors) -- or when Canonical does it.

We basically want to prevent a situation occurring when we might need to change the license, and get stymied by having to secure agreements from every existing contributor.

  1. Compatibility with any existing open-source libraries we might want to use. e.g. MPL before version 2 is not compatible with (L)GPL; EPL is not compatible with (L)GPL -- IANAL, but it seems that you can use LGPL components in an EPL project, and vice versa (explicitly stating this exception), but if you use a mix of LGPL and EPL libraries, you might need permission from their authors. It's a mess); Apache 2.0 is compatible with GPL only starting from GPLv3. And of course GPLv2 is not compatible with GPLv3 ...

The main lesson I learned from my experience with Variations2 was to be wary of the GPL. At least one (DjVu) and probably more of the 30 or so FOSS components we wanted to use wasn't GPL v2 compatible, and -- based on the compatibility info in the Fedora page -- it looks like GPL v3 isn't much different. And who knows at this point what FOSS libraries we might want to use?!? So I continue to be anti-GPL.

That pushes us into MPL v2 (which is GPLv3 compatible) and EPL territory. The former is weaker (people can skirt around the requirements by putting their code into separate files) but is more compatible than EPL. We'd probably have to play it by ear, which is why a license grant signed by all contributors before we merge their code is nice - it affords such flexibility if we made the wrong choice at the beginning.

We'd probably have to nominate someone to have that right over the codebase, though, in lieue of having an actual foundation. With the Clojure programming language, the original developer held that right.

There is a reasonably comprehensive list here with more details: http://fedoraproject.org/wiki/Licensing:Main#Software_License_List

This is amazing! I did most of the research on software licensing for IU's Variations2 project, and I thought I'd at least heard of most of the open-source licenses in existence; maybe so, but that was in 2005, and a lot has happened since then.

Indeed, at open source conferences, the Fedora developer in charge of licensing tends to give one of the more fascinating talks :)

Best,

Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: A36A937A Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP6o/+AAoJEEr1VKujapN6+swH+wXAjWzbrRLq5x4VeD0V8Dxi uARe8soEyV+jhYYnRKGPiwupZss5CcOyfT38dRVh604b96GuoJHjnJSrWVHmpYB1 9+7JY8aOte5WANnSsxCCU6a7wN7zYETDSxrncXf0isYzgpm40SjK8s9kpSvBLYOu EElJEvajn6cmF35Ui2HtrDYhwEOIQekIGlBEJvi6XFhvsjpEy3hqsVkwTeI3XXZp 5YiZOXgOnxyjvK2qtJeBvVtMIWvgIB2sw5Oh+/TbjztrcPuS+/gCpno9p7TXdx5+ LuS/JpsalidZMN5hQECzb0hTp/j4MpEbrlhXT0bbyrCJ1jYk0hxQr4Yg0Ohp+9c= =dV1T -----END PGP SIGNATURE-----

donbyrd commented 12 years ago

On Tue, 26 Jun 2012 21:46:03 -0700, Michel Alexandre Salim reply@reply.github.com wrote:

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

Hi Don, all,

On 06/26/2012 09:57 PM, Don Byrd wrote:

Extremely helpful. Thanks, Michel! What a mess all this is.

FYI, your message apparently did not go to Geoff, but I'll cc him on this -- and David Gottlieb, our other participant so far.

Hmm, Geoff opened the GitHub issue, so I'm assuming he does get Cc:ed on updates. I think it's just that GitHub's email notification system let you reply to a pre-generated address, and add any replies sent there to the issue itself, thus only that random-looking address shows up on the email.

See comments below; I'd much appreciate feedback from anyone. Further commented with some clarifications, after that I'll stop hogging the discussion :)

  1. Do we care about explicit patent language? GPLv3 and Apache explicitly mention software patents, while it's implicit in GPLv2, and BSD/MIT is silent on the issue

Ugh. Software patents are really stupid. But it seems like a good idea to say something about them, doesn't it?

Right. And we want to avoid the faux pas Google did when they open-sourced the VP8 video codec as WebM -- they initially went BSD but with an Apache-like patent clause, and after getting negative feedback about introducing an untested new license variant, finally went with standard BSD and decoupled the patent language.

As a small player, I guess the defensive patent language in Apache (I'll just use the Fedora short-name for it, ASL 2.0 -- I trust nobody here will confuse it with the unrelated IRC terminology

What's that about American Sign Language? :-)

) or LGPL/GPL v3 wouldn't hurt -- it basically states that contributors automatically license, non-exclusively and for free, any patent they held that is needed by their code contribution.

If such contributors later sue us for infringement, any patent license they get as part of the software (thus, Nightingale) is automatically revoked, so effectively they can no longer distribute the software. Something like this happened several years ago over the RAMBus memory technology -- one of the companies involved in standardizing it later turned around and started trying to recoup royalty payments. Needless to say, almost nobody used the technology now (I think Sony's PS2 used it - but I can't remember for sure now. And you have the debacle of companies as big as Microsoft being found to infringe MP3 patents years after its invention - company A buys company B and discovers some patents that would apply that are not being monetized yet!

Yep. There are also debacles of companies as big as Apple being found not to infringe GUI patents because Xerox didn't bother to defend them for years. But, with their Fumbling the Future at PARC, Xerox holds the all-time record for intellectual-property screwups. (A digression, excuse me.) ANyway, what you say makes sense.

  1. Do we require copyright reassignment? (related to #1). Sun/Oracle required it, so does Canonical (Ubuntu); Red Hat's Fedora project has the most liberal solution I've seen, where individual contributors retain their copyrights but the project gets a license grant: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

I don't understand the implications of this offhand, but will think about it.

Some companies like having the right to relicense the software -- thus, for example, MySQL is available under GPL as well as under a proprietary commercial license -- but to do that, they need to either own the entire code base (and thus requiring external contributors to sign away their rights) or to at least secure some rights to those contributions. Full copyright reassignment tends to be unpopular -- it's moderately acceptable when a trustworthy organization requires it (the Free Software Foundation, for instance - though like you, I have a mild case of FSF/RMS/GPL allergy). Less so when it's Sun/Oracle (MySQL, OpenOffice -- for many years Linux vendors maintain out-of-tree patches to OpenOffice, later becoming LibreOffice, partly because of the copyright reassignment requirement, and partly because Sun ran the project without sufficient cooperation with outside contributors) -- or when Canonical does it.

We basically want to prevent a situation occurring when we might need to change the license, and get stymied by having to secure agreements from every existing contributor.

OK, this makes sense too.

  1. Compatibility with any existing open-source libraries we might want to use. e.g. MPL before version 2 is not compatible with (L)GPL; EPL is not compatible with (L)GPL -- IANAL, but it seems that you can use LGPL components in an EPL project, and vice versa (explicitly stating this exception), but if you use a mix of LGPL and EPL libraries, you might need permission from their authors. It's a mess); Apache 2.0 is compatible with GPL only starting from GPLv3. And of course GPLv2 is not compatible with GPLv3 ...

The main lesson I learned from my experience with Variations2 was to be wary of the GPL. At least one (DjVu) and probably more of the 30 or so FOSS components we wanted to use wasn't GPL v2 compatible, and -- based on the compatibility info in the Fedora page -- it looks like GPL v3 isn't much different. And who knows at this point what FOSS libraries we might want to use?!? So I continue to be anti-GPL.

That pushes us into MPL v2 (which is GPLv3 compatible) and EPL territory. The former is weaker (people can skirt around the requirements by putting their code into separate files) but is more compatible than EPL. We'd probably have to play it by ear, which is why a license grant signed by all contributors before we merge their code is nice - it affords such flexibility if we made the wrong choice at the beginning.

We'd probably have to nominate someone to have that right over the codebase, though, in lieue of having an actual foundation. With the Clojure programming language, the original developer held that right.

Good point. We've been talking about setting up a U.S. 501(c)(3) organization -- it doesn't have to be a foundation, but it'd be a nonprofit -- to hold the rights. I don't know if this is going to happen, though.

There is a reasonably comprehensive list here with more details: http://fedoraproject.org/wiki/Licensing:Main#Software_License_List

This is amazing! I did most of the research on software licensing for IU's Variations2 project, and I thought I'd at least heard of most of the open-source licenses in existence; maybe so, but that was in 2005, and a lot has happened since then.

Indeed, at open source conferences, the Fedora developer in charge of licensing tends to give one of the more fascinating talks :)

:-)

Thanks for hogging the discussion, Michel! I understand a lot more now. Don't have much to add until I take a closer look at some of the licenses you mentioned.

--DAB

Best,

Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/

Email: salimma@fedoraproject.org | GPG key ID: A36A937A Jabber: hircus@jabber.ccc.de | IRC: hircus@irc.freenode.net

() ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJP6o/+AAoJEEr1VKujapN6+swH+wXAjWzbrRLq5x4VeD0V8Dxi uARe8soEyV+jhYYnRKGPiwupZss5CcOyfT38dRVh604b96GuoJHjnJSrWVHmpYB1 9+7JY8aOte5WANnSsxCCU6a7wN7zYETDSxrncXf0isYzgpm40SjK8s9kpSvBLYOu EElJEvajn6cmF35Ui2HtrDYhwEOIQekIGlBEJvi6XFhvsjpEy3hqsVkwTeI3XXZp 5YiZOXgOnxyjvK2qtJeBvVtMIWvgIB2sw5Oh+/TbjztrcPuS+/gCpno9p7TXdx5+ LuS/JpsalidZMN5hQECzb0hTp/j4MpEbrlhXT0bbyrCJ1jYk0hxQr4Yg0Ohp+9c= =dV1T -----END PGP SIGNATURE-----

Reply to this email directly or view it on GitHub: https://github.com/AMNS/Nightingale/issues/17#issuecomment-6594677

Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics & Music Indiana University, Bloomington

donbyrd commented 12 years ago

NOTES TOWARDS A NGALE FOSS LICENSE AGREEMENT - DAB, 2 JULY 2012

Note: as used herein, "GPL" alone refers to all versions of the GPL proper, but does not include the LGPL.

Information Sources

A reasonably comprehensive list of FOSS licenses, with details (including a GPL Compatibility Matrix):

http://fedoraproject.org/wiki/Licensing:Main#Software_License_List

We should also consider a contributor agreement. The Fedora FPCA is one example:

https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

It links to the the old (retired) Fedora Individual Contributor License Agreement, so there's a 2nd example.

Surely there's a discussion of license issues for open-source projects in general somewhere, but I haven't seen one. Does anyone know?

A list of issues (based on Michel's)

  1. Is monetization a goal? This influences whether to pick a permissive license (BSD/MIT, Apache), or stronger licenses that apply transitively to modifications as well (if the modification distributed): MPL/CDDL (license applies within file boundaries), EPL/LGPL (license applies within modules) and GPL (license applies to derivative work as well). However, the GPL's strength also makes monetization almost impossible, unless we use multiple licenses; see below.

    Recommendation: Monetization definitely may be a goal, so we don't want to be permissive, but we also don't want the GPL's kind of strength.

  2. Do we require copyright reassignment by contributors? (related to #1) Sun/Oracle required it, so does Canonical (Ubuntu); Red Hat's Fedora project has the most liberal solution we've seen, where individual contributors retain their copyrights but the project gets a license grant:

    https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

    Some FOSS organizations like having the right to relicense the software -- thus, for example, MySQL is available under GPL as well as under a proprietary commercial license -- but to do that, they need to either own the entire code base (thus requiring external contributors to sign away their rights) or to at least secure some rights to those contributions. Full copyright reassignment tends to be unpopular. It's moderately acceptable when a known-to-be-trustworthy organization requires it (the Free Software Foundation, for instance). Less so when it's Sun/Oracle (MySQL, OpenOffice -- for many years Linux vendors maintain out-of-tree patches to OpenOffice, later becoming LibreOffice, partly because of the copyright reassignment requirement, and partly because Sun ran the project without sufficient cooperation with outside contributors) -- or Canonical. We basically want to prevent a situation occurring when we might need to change the license, and get stymied by having to secure agreements from every existing contributor.

    Recommendation: go with a compromise like the Fedora approach; it's much preferable to either not having any rights to relicense or insisting contributors completely give up their own rights.

  3. Do we care about explicit patent language? GPLv3 and Apache explicitly mention software patents, while it's implicit in GPLv2, and BSD/MIT is silent on the issue. And we want to avoid the faux pas Google did when they open-sourced the VP8 video codec as WebM -- they initially went BSD but with an Apache-like patent clause, and after getting negative feedback about introducing an untested new license variant, finally went with standard BSD and decoupled the patent language. As a small player, I guess the defensive patent language in Apache (the Fedora short-name for it is ASL 2.0) or LGPL/GPL v3 wouldn't hurt: it basically states that contributors automatically license, non-exclusively and for free, any patent they hold that is needed by their code contribution. If such contributors later sue us for infringement, any patent license they get as part of the software (thus, Nightingale) is automatically revoked, so effectively they can no longer distribute the software. Something like this happened several years ago over the RAMBus memory technology -- one of the companies involved in standardizing it later turned around and started trying to recoup royalty payments. Needless to say, almost nobody used the technology now (Sony's PS2 may have used it). And you have the debacle of companies as big as Microsoft being found to infringe MP3 patents years after its invention - company A buys company B and discovers some patents that would apply that are not being monetized yet!

    Recommendation: The LGPL/GPL v3 "defensive patent language" seems like the best.

  4. Compatibility with any existing open-source libraries we might want to use. E.g. MPL before version 2 is not compatible with (L)GPL; EPL is not compatible with (L)GPL -- IANAL, but it seems that you can use LGPL components in an EPL project, and vice versa (explicitly stating this exception), but if you use a mix of LGPL and EPL libraries, you might need permission from their authors. It's a mess); Apache 2.0 is compatible with GPL only starting from GPLv3. And of course GPLv2 is not compatible with GPLv3 ... (The main lesson Don learned from experience with Variations2 was to be wary of the GPL. At least one (DjVu) and probably more of the 30 or so FOSS components we wanted to use wasn't GPL v2 compatible, and -- based on the compatibility info in the Fedora page -- it looks like GPL v3 isn't much different. And who knows at this point what FOSS libraries we might want to use?!?) Furthermore, they're incompatible with the Terms of Service for Apple's App Store. That pushes us into MPL v2 (which is GPLv3 compatible) and EPL territory. The former is weaker (people can skirt around the requirements by putting their code into separate files) but is more compatible than EPL. We'd probably have to play it by ear, which is why a license grant signed by all contributors before we merge their code is nice: it affords such flexibility if we made the wrong choice at the beginning.

    Recommendation: All versions of the GPL (but not necessarily the LGPL) are too restrictive because of incompatibility with some other FOSS licenses and with Apple's App Store.

  5. Are we willing to use "an untested new license variant"? This would give us more flexibility, e.g., to add defensive patent language to any agreement.

    Recommendation: Since none of us is a lawyer and we have no budget for one, just use an existing license.

  6. Should we consider multiple licenses, e.g., one for commercial use (non-free) and one, perhaps the GPL for other use (free)? Offering multiple licenses makes things considerably more complicated.

    Recommendation: Following the KISS principle, use only one.

  7. We don't yet have a formal organization to hold rights over the codebase, though we plan to set up a U.S. 501(c)(3) -- probably a foundation -- ASAP. In the meantime, we'd probably have to nominate someone to hold the rights. With the Clojure programming language, it was the original developer.

    Recommendation: Have either Don or Geoff hold the rights, with the understanding they'll transfer the rights gratis to the 501(c)(3) as soon as it exists. (If it seems worthwhile to reassure potential contributors, we could put that understanding in writing, though it's hard to see how it'd be enforcable.)

Conclusions and Further Questions

Does everyone agrees with the above analysis and recommendations? Please comment. Assuming everyone does agree:

the FPCA says contributors must waive Section 4d of the Creative Commons Attribution ShareAlike 3.0 Unported license when it is used as a "default license" because "Section 4d, if invoked, would potentially make the licensing non-free. By promising to waive that clause (which the license permits), you're ensuring that your contribution will be Free for Fedora and for everyone else." This seems to make monetization impossible except for the "default license" phrase; I'm not sure what its implications are.

But, even if it's agreed we need a contributor agreement, how high priority is it? Could we put off dealing with it for a few weeks or even a couple of months?

michel-slm commented 12 years ago

I've not found a definitive guide to picking a software license -- it's probably hard to find one that combines clarity with lack of obvious bias one way or another. This one is quite humorous, though:

http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html

Note - as long as we have a contributor agreement that allows the project relicensing rights, GPL is actually beneficial to monetization -- provided the decision to offer just a single license is not set in stone. What GPL does, in that case, is to make monetization difficult for every third party instead (they can offer services / support, but only under the terms of the GPL meaning their customers get the source and the right to further redistribute under the GPL. It is possible to make money this way -- see Red Hat). The project can either offer enhanced versions under non-GPL terms (see MySQL) or make new features initially available under more restricted terms (see Ghostscript).

I don't think we need a contributor agreement straight away. It will become urgent only once the project takes off -- so it's more the kind of issue that we would like to have :). We don't want to get to the Linux situation, though, where there are thousands of individual contributors, and in effect the project is stuck on GPLv2...

Back to monetization. I think generally the weaker the license, the harder it is to monetize -- since everyone could take the code and run with it without contributing back (see for instance Mac OS X - the userland is mostly taken from FreeBSD, but while Apple chose to keep the code open source as Darwin, they used a different license - the APSL - which is more restrictive than BSD, and so most of the changes do not flow back to the originating project unless Apple chose to donate the code back. Contrast to WebKit which started out as a KDE (a desktop project for free Unixes) library, and because it's licensed under the LGPL Apple has to (and does) share their contributions back. So I'm not sure we want to go lower than the MPL/CDDL sort of weak copyleft -- and preferably get to the EPL/LGPL level. It's not that hard to get around the MPL's limitation by putting modifications in external files, so the project's copyright holder does not have as much of an advantage over other people trying to monetize it.

Compatibility-wise - given that LGPL is basically GPL but with the "virality" restricted so people using a defined API/ABI would not be required to use the same license - I don't know how much more compatible LGPL is compared to GPL.

At this stage my favorite is MPLv2 -- it also has a defensive patent revocation clause, which seems standard in the latest batch of licenses -- http://www.mozilla.org/MPL/2.0/ , see section 5.2. LibreOffice recently decided to adopt the MPL based on compatibility reason -- it's stronger than the ASL that Apache OpenOffice uses, but is not too strong that the Apache Software Foundation disallow using code licensed under MPL in Apache projects; and it's also L/GPLv3+ compatible and apparently allowed in app stores:

http://lwn.net/Articles/498898/

(read the link to the LibreOffice FAQ for details -- I'm reading it right now)

donbyrd commented 12 years ago

It's more and more obvious that Michel knows a lot more about licensing than I do; for example, I was under the impression that LGPL was less restrictive than it clearly is. And -- contrary to the impression my last post might have given -- I don't want to have a lengthy discussion of the subject; there's waaaaaay too much else to do! So I'm inclined to say let's go with MPL v2 only. That handles issues #1, #3, #4, #5, and #6. Comments, anyone?

What about issue #2, the project's copyright reassignment rights? That's the obvious problem with postponing a contributor agreement.

I enjoyed several things on the Coding Horror blog page, especially (since rock climbing is one of my favorite pastimes) the "Software Projects as Rock Climbing" analogy :-) . Thanks, Michel!