Thanks for the simple example, Ralph. :) Matt
On Tue, Jan 17, 2012 at 2:25 PM, ralph.goers @dslextreme.com <ralph.go...@dslextreme.com> wrote: > I don't have the link in hand at the moment, but lets pretend that someone > wrote some code under the GPL, LGPL or some other non-Apache license. > Someone else takes that code and simply changes the license header to the > Apache license. You then, with all good intent, pick up that software and > commit it to an Apache project. This would open up the project to lots of > bad consequences. > > We require IP clearance to prevent exactly this situation, or variants of > it. > > Ralph > > > On Tue, Jan 17, 2012 at 12:11 PM, Matt Benson <gudnabr...@gmail.com> wrote: >> >> This thread brings up another issue. During this process we have >> encountered the sentiment that the ASF's insistence on (arguably) >> extensive documentation to import e.g. ALv2-licensed code seems to >> express a lack of confidence in "its own" license on the part of the >> ASF. My response has been, paraphrased, that the ASF, in the interest >> of protecting its projects, may go "above and beyond" with regard to >> IP clearance. With his permission, I'll paste what Red Hat's Richard >> Fontana had to say on the matter: >> >> RF: >> > > I must say that I am in strong agreement with those who expressed >> > > puzzlement at the apparent insufficiency of the Apache License 2.0 -- >> > > I understand this to mean that the ASF has no confidence in its own >> > > license, at least when that license comes from third parties. If the >> > > ASF isn't confident in that license when it comes from others, why >> > > should anyone be confident in that same license when it comes from the >> > > ASF? �I don't want to make a big deal out of this, I just want to add >> > > my support as a lawyer to a viewpoint you're hearing from >> > > developers. I have, in fact, raised this very question before, in a >> > > number of contexts. >> >> Now, before anyone says "how dare he!" he also went on to say: >> >> RF: >> > I don't mind the ASF choosing to have such IP policies, >> > because of the unique role of the ASF and my very high degree of trust >> > and confidence in the ASF. It's really in non-ASF contexts where I've >> > raised the issue (for example, I recently made some comments along >> > these lines on the OpenStack developers' mailing list). And we've been >> > criticized on the other side, for example with Fedora. I guess the >> > only points of tension come about in situations like this where we >> > have Red Hat code migrating to Apache incubator status. But, as a >> > personal matter, and as a Red Hat employee, I am very pleased to see >> > this happening >> >> So I am satisfied to accept that this is "the way it is," toe the >> line, and put on the brave external face. But so I don't look like an >> idiot saying "it is what it is," is there an authoritative explanation >> of the motivation behind our policies to which future querents should >> be directed? >> >> Matt >> >> On Tue, Jan 17, 2012 at 1:54 PM, Sam Ruby <ru...@intertwingly.net> wrote: >> > On Tue, Jan 17, 2012 at 2:33 PM, ralph.goers @dslextreme.com >> > <ralph.go...@dslextreme.com> wrote: >> >> I didn't mention CCLA's on purpose. A corporation will have a CCLA on >> >> file >> >> to either a) declare that certain employees are permitted to contribute >> >> software or b) declare that certain software is contributed to the ASF. >> >> A >> >> CCLA that is on file that only includes Schedule A doesn't grant the >> >> ASF >> >> permission to use specific software created by the company. If the >> >> company >> >> is donating the software they need to specify it. If the software is >> >> being >> >> contributed via an ICLA then the CCLA simply says the company is giving >> >> the >> >> contributor the right to contribute software that normally the company >> >> would own. However, an individual should never contribute software >> >> under >> >> their ICLA that they didn't author, unless they have explicit >> >> permission >> >> from the other authors. For a "significant" contribution a software >> >> grant >> >> is typically the best way to do it. >> > >> > I concur. >> > >> > Either an (additional|updated) CCLA with a concurrent software grant >> > (Schedule B) for the code in question -or- simply a separate Software >> > Grant would be appreciated. >> > >> > If RedHat is on board with this (and everything in this conversations >> > indicated that that is indeed the case), then that shouldn't be a >> > problem? >> > >> > - Sam Ruby >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
