On Thu, 2011-12-08 at 11:42 -0800, Andy Grover wrote: > Hi Jerome, > > I think this is a necessary step to encourage a healthy FOSS development > model around targetcli, to foster increased usage and development of the > main body of code -- in the Linux kernel. > Really, I honesty don't think forking the code to a distro specific version and introducing changes to the codebase without any discussion from us (or the list) is fostering healthy FOSS development. > Just as it's clear that RTS's decision to contribute the kernel target > code (LIO) has benefited both the community and RTS, I hope it's also > clear that RTS can benefit from engaging in community-driven targetcli > development. > I don't see how our use of the MIT license for contributions dis-engages the community-driven model of development any more than what Fedora or your employer is also doing wrt contributions using MIT. Also, none of the other major distributions who have included our userspace code have a problem with respecting our wishes wrt to outside contributions. Also, we are not limiting or obfuscating our code in any way, and provide a fully usable free version for all to use and improve. Considering Redhat's policy on obfuscating RHEL kernel code that includes my own copyrighted work with target-core, I personally consider this a bigger affront to the spirit of the GPL (and my copyright) than the licensing terms of our userspace bits that do not effect the actual source code. So that said, we would still like an answer from you as to why you think it's OK for Redhat to use MIT for contributions or take other more drastic measures when it feels necessary to protect it's intellectual property position, but not OK for a small company who is funding the vast majority of development work to also protect it's intellectual property position. --nab > Regards -- Andy > > > On 12/06/2011 02:17 PM, Jerome Martin wrote: > > [Resent to list as plain text] > > > > Hi Andy, > > > > As you can imagine, we are quite surprised and disappointed by your > > decision to fork targetcli. We tried supporting and accommodating you > > to the very best of our abilities, and you reciprocated by just > > forking and actively soliciting the target-devel community for > > contributions without much of a warning. > > > > You claim that making contributions to targetcli (which is available > > under the AGPLv3) under the MIT license or by signing a simple CLA > > would be “against the spirit of free software.” > > > > We explained to you that we need the flexibility to use contributions > > under our free software licensing terms, so that our intellectual > > property position doesn’t become too complicated. As a company, we > > have made the decision to make intellectual property that took us > > considerable expense available for free to the community, and we want > > to make sure our resources are devoted to making our products the best > > they can be, rather than fighting legal battles over contributions. > > > > To that end, we simply ask to make contributions under the MIT > > license, or, alternatively, agree to co-ownership of the > > contributions, or, if that is not possible, get an unrestricted > > license to the contributions. This way: > > > > * Everyone can continue to use their own code freely; > > * Everyone owns their own enhancements to their code; > > * We guarantee that contributions get released as open source software, and > > * We are not asking for a copyright assignment. > > > > Now, let’s compare our fairly liberal contribution terms to some of > > the more prominent terms of your own employer, Red Hat: > > > > * Fedora: Contributions require signing the “Fedora Project > > Contributor Agreement” (FPCA), which allows code contributions under a > > number of “acceptable licenses”, the default license being the MIT > > license, see [1]. Effectively, Red Hat reserves the right to relicense > > any code submitted under the “default license” to any of the “Good > > Licenses”, including the AGPLv3, see [2]. This is similar to our > > terms, but more restrictive in that Red Hat doesn’t allow co-ownership > > or retained ownership of enhancements, and doesn’t guarantee that the > > contribution will be released at all. > > > > * JBOSS: Contributions require signing a “Contributor License > > Agreement” (CLA), which assigns all rights, including the copyrights, > > to Red Hat, and expressly grants Red Hat the right to sell the > > contribution, see [3]. There is no concept of shared or retained > > ownership – all rights are fully assigned to Red Hat. Besides, this > > CLA isn’t legal in Europe, as copyrights are not transferrable there > > (except by heritage). > > > > * Alfresco: Contributions require signing a “Standard Contribution > > Agreement”, which allows Red Hat, at their sole discretion, to > > relicense the contribution under their “free software licensing terms, > > other terms they may use in the future, or commercial terms,” (!) see > > [4]. Obviously, this is much more restrictive than our terms. > > > > * Cygwin: Contributions require signing an “Assignment Contract” that > > provides the transfer of the contributors “entire rights, title and > > interest (including all rights under copyright), including “any future > > revisions of these changes and enhancements,” (!) to Red Hat, see [5]. > > Obviously, this is much more restrictive than our terms, and it isn’t > > legal in Europe (where copyrights are not transferrable). > > > > I could probably keep expanding the list… > > > > To summarize, your arguments are inconsistent with some of your > > employer’s, Red Hat, most prominent own open source contribution > > terms. It eludes me how you can find our liberal contribution terms to > > be “against the spirit of free software”, while you seem fine with > > your employer’s considerably more restrictive terms. In fact, Red > > Hat’s more restrictive terms make you look hypocritical, and your > > action appears as an aggressive move of a large company to undermine a > > small startup that has been making significant contributions to Linux. > > We’d love to continue to provide great open source software, but we > > can’t do so if you have us worry about future legal complications. > > > > Please kindly explain why you’re concerned with our liberal > > contribution terms (either MIT license or co-ownership), while you’re > > fine with your employer’s more restrictive terms (including mandatory > > CLAs, relicensing under e.g. the AGPLv3 or some unspecified commercial > > license, copyright assignments that are illegal in Europe, sole > > ownership of all future changes, etc.). > > > > Thanks, > > -- > > Jerome > > > > > > [1] Fedora Project Contributor Agreement, Fedora wiki, > > https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement > > [2] Fedora Licensing, section “Good licenses,” Fedora wiki, > > https://fedoraproject.org/wiki/Licensing#Good_Licenses > > [3] JBOSS Software Contributor Agreement, only available with a login, > > https://cla.jboss.org/contributions/sign.seam?cid=804 > > [4] Source Code page, Alfresco wiki, http://wiki.alfresco.com/wiki/Source_Code > > [5] Cygwin copyright assignment form, Cygwin web site, > > http://cygwin.com/assign.txt > > > > > > On Tue, Dec 6, 2011 at 12:51 AM, Andy Grover <agrover@xxxxxxxxxx> wrote: > >> > >> Hi all, > >> > >> Unlike the kernel target code, RTS has stated a policy of requiring > >> contributions to their userspace tools to be either under CLA, or MIT > >> license[1]. This is so RTS can incorporate the contributions into their > >> proprietary version. Meanwhile, RTS licenses targetcli and friends under > >> the AGPLv3[2]. > >> > >> I'm not willing to contribute code under those terms. I'll do AGPL if > >> the code is AGPL, or I'll even do MIT if everyone else agrees to MIT > >> licensing, but I won't agree to MIT when you are using AGPL, and I don't > >> think anyone else should agree, either. It's against the spirit of free > >> software. > >> > >> Therefore, I have made updated targetcli, rtslib, and configshell repos > >> available here: > >> > >> https://github.com/agrover/targetcli-fb > >> https://github.com/agrover/rtslib-fb > >> https://github.com/agrover/configshell-fb > >> > >> fb stands for "free branch". > >> > >> These will track RTS's repos, and will also accept contributions from > >> others, without CLA, under the AGPLv3. I invite all developers with an > >> interest in this area (and a basic knowledge of Python) to contribute! > >> You can also help out by submitting bug reports via Github issue > >> tracking. Mailing list TBD but target-devel for now. > >> > >> These new repos will be the basis for future Fedora packaging of > >> targetcli, and I plan to be aggressive in updating rawhide. > >> > >> Regards -- Andy > >> > >> [1] http://www.linux-iscsi.org/wiki/Contributing > >> [2] http://en.wikipedia.org/wiki/Affero_General_Public_License > >> -- > >> To unsubscribe from this list: send the line "unsubscribe target-devel" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > -- > > Jérôme Martin > > > > > > > > -- > > Jérôme Martin > > -- > > To unsubscribe from this list: send the line "unsubscribe target-devel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe target-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
