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
<thb@documentfoundation.org> wrote:
Jim Jagielski wrote:
Bjoern Michaelsen <bjoern.michaelsen@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