On Thu, Oct 12, 2017 at 11:32 AM, Wayne Beaton
<wayne.beaton@...> wrote:

My understanding is that the Secondary Licensing provision in the EPL-2.0 is
not the same as dual licensing using an OR. From our FAQ (which we're still
working on):

The notion of Secondary Licenses is intended to permit combining content
licensed under the EPL-2.0 with an otherwise incompatible license,
specifically the GNU General Public License, v2.0 or greater. This means
that the content that includes a Secondary License clause may be combined
with content distributed under the terms of that Secondary License, and the
combined content can be then be collectively distributed under the terms of
that Secondary License.

Further,

Is EPL-2.0 with the Secondary License clause considered dual licensing?
It is extremely close to dual licensing. The EPL-2.0 is the only license,
until such time as it is combined and distributed with a work under the
Secondary License. After such time, any recipient of the combined work can
consider the content licensed under the Secondary License. The original work
remains under the EPL-2.0 and is never really dual-licensed. Once a
downstream adopter has received the content under the Secondary License,
they can modify and further distribute it solely under the terms of the
Secondary License.

Does this help?

I hope to make our FAQ public later today or earlier tomorrow. That may
provide further context.

Wayne:
This helps a lot to better understand the EPL terms.

My understanding:

I cannot use EPL 2.0-licensed code under a Secondary license
unless I combine it with some other code using that Secondary license.
And only its is only when I combine that the Secondary license terms may
apply to the combo. Otherwise, only the the EPL-2.0 applies.

My take is that a license expression can never replace nor capture all
the specific
details of licensing. This what the license texts are for. The license
expression is
just a concise, imperfect but mightily handy summary of the licensing.

Therefore, even though this may not be it exactly, I still think we
can use existing
license expressions OR constructs for this case and with no change needed.

An expression such as EPL-2.0 OR GPL-2.0 is enough to tell me there is some
choice. Then when I read the actual text and notice, I get the details
and specific
terms. If I elect the GPL-2.0 choice without reading the licensing
first then I am
foolish at best. We cannot prevent foolishness. If I build a tool that automates
such a choice, I can easily have a special case where the EPL-2.0 shows up
as a choice with another license and process this as a special case.

Be it here or in the much-talked-about case of FSF or-later-or-only-or-may-be
licensing nuances, an expression can never entirely replace the actual
license texts
and notices. I think this is just fine this way: a name alone can
never capture nor
convey all the nuances and attributes of a thing.

--
Cordially
Philippe Ombredanne