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 > >
