exhaustively, yes, but not concretely. The exhaustive reply boils down to "it depends", which is really no answer at all. Furthermore, it implies that the simply inclusion of the alv2 as part of the license suite *does* change the dynamic, since something provided under mpl-lgplv3 as not handed the same way "it depends"... Furthermore it does not describe the actual mechanism.
I will be blunt: it certainly *appears* that all this hand waving is being done to be able to accept code when it is beneficial to LO only, and not accept code when it is beneficial to LO *and* AOO, as code under alv2-mpl-lgplv3 would be, except for small code patches and fixes that have no real "value". Such a "it depends" policy allows this, and this is the core of the question. The people who contacted me specifically wanted to provide code to LO, that merged with LO w/ no conflicts, would require extensive re-work to be folded into AOO, but would be licensed under the alv2 and were told that the inclusion of the alv2 as the license of the donation was unacceptable. When asked if dual or triple licensing was acceptable, they were told No. To them, it appeared that the *mere possibility* that it could be used by AOO, even though their people are being paid to work on LO, was enough to prevent their work being even considered. Will the ASF and AOO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is yes. Will the TDF and LO accept code licensed in such a way that it can be directly consumed by AOO and LO: The answer is "it depends"... the logical assumption regarding WHY is not-complimentary to TDF and LO, nor is it beneficial to the OO ecosystem itself, nor is the policy defined enough that code providers know what to do. On Mar 11, 2013, at 6:55 AM, Thorsten Behrens <t...@documentfoundation.org> wrote: > Jim Jagielski wrote: >> Bjoern Michaelsen <bjoern.michael...@canonical.com> wrote: >>> That was not what either Florian or the policy said. This is a >>> matter of community, not just of license. Such combinations of >>> licenses do not lead to a contribution being automatically >>> accepted or rejected, either at Apache or at TDF, we look at each >>> case on its merits. >>> >> >> That is true, and I, of course, understand that. The question is >> whether such a triple-licensed patch would be rejected *regardless* >> of technical merit, and that is a valid question to ask. >> > Hi Jim, > > Florian answered that exhaustively in his earlier email: > > On Mar 7, 2013, Florian Effenberger wrote: >>> as our licensing page states, in order to contribute to >>> LibreOffice and be part of our community, we require a >>> dual-license of MPL/LGPLv3+ for contributions, which gives >>> everyone the benefit of the strong rights these licenses >>> grant. From time to time, depending on the specific case and the >>> quality of the code, we may use and merge other licensed pieces of >>> code with compatible licenses. We examine each case, depending on >>> its merits. >>> >>> In theory, code under a triple license is just as acceptable. In >>> practice, however, TDF has hundreds of affiliated developers >>> working as a team together, doing the actual code review and >>> acceptance work. There is a spectrum of developer opinion on your >>> nurturing of a competing project. Many core developers may be less >>> inclined to invest their time into significant, active assistance: >>> mentoring, reviewing, finding code pointers, merging, back >>> porting, and so on, for functionality that will not provide a >>> distinctive value for LibreOffice. >>> >>> So, while there may be many possible acceptable variations of >>> inbound license and contributions, there are likely relational >>> consequences of those choices that are hard to quantify. Having >>> said that, all developers who want to contribute constructively to >>> LibreOffice are welcome in our community, and we have a high >>> degree of flexibility to fulfill their genuine needs. The best >>> thing to do is just to point them to our developers list. >> > > Jim Jagielski wrote: >> Unfortunately, I am not at liberty to divulge the identity >> of the contacts, but that should not matter. >> > I understand, but in general we like to work directly with those > contributing the code, rather than dealing in hypotheticals. > > With kind regards, > > -- Thorsten -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
