www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Third Party FOSS licenses
Date Mon, 03 Aug 2015 04:34:28 GMT
On Sun, Aug 2, 2015 at 4:31 PM, Lawrence Rosen <lrosen@rosenlaw.com> wrote:

> Henri Yandell and I have been having a civilized conversation about mixing
> Apache and MPL software. He permits me to share parts of it.
>
>
>

That's very kind of him, I wasn't aware he had (beyond knowing that any
private discussion can be made public) ;)


> I modified Henri's definitions of "mix" and "appears with" by adding the
> underlined phrase about *derivative works*. These are now polite phrases
> instead of "ground beef" or "pee in a pool":
>
>
>
> Mix *and create a derivative work*: When MPL source is added to existing
> Apache 2.0 source (the same file) *and creates a derivative work* such
> that the Apache 2.0 source must now be licensed under MPL.
>
>
>
>
> Appears with: When MPL source is place beside existing Apache 2.0 source
> files, such that the Apache 2.0 source does not need to be licensed under
> the MPL.
>
>
> *You also have to create a derivative work.* That is much rarer than you
> imagine. When you are *merely mixing FOSS code* for *functional
> convenience* (into the same or different files) and *it has nothing to do
> with the copyrightable aspects of the works* (e.g., DRM protection for
> the binary, packaging it into one TAR file, making separate programs
> convenient to install), then you have almost certainly *not created a
> derivative work*. That is not worth a $35 copyright application fee since
> any competent programmer in the world can replace that easily without
> infringement. For free. The only sour spot is that you are required by
> almost EVERY FOSS license to post notices of what you have mixed.
>
>
>
> This is also why I believe that the GPL static linking doctrine is
> ridiculous. *You also have to create a derivative work!*
>
>
>
> The two paragraphs above ought to be reviewed and approved by real
> attorneys working for real companies. I'm tired of talented programmers
> expounding otherwise on this legal issue. But if correct, it makes the
> combining of FOSS software generally trivial.
>
>
>
If the Open Source lawyers (nebulous group definition for those lawyers
with a history of publishing opinions on Open Source) have consensus on
this, then it would be an item of interest. I don't see that the those two
paragraphs make any substantial difference to our policies. Our policies
focus on the mix+create use case.


>
>
> It does mean that you may more often ask your lawyer the following
> question, "Am I creating a derivative work?" rather than "Can I mix or
> appear with?"
>
>
>
> If we're prepared to mix MPL inside Apache code, such that it can't be
> reversed, I think Apache should move to using MPL 2.0 as it's default
> license.
>
I have never suggested that and would never.
>

I'll note that was followed by "Bit quick above so apologies if it's leaky
as a sieve - got a busy family day and need to get the kids moving".

With editing, the intent of my quick text was that the MPL 2.0 be used as
the primary license for that product. That said though, if we end up with
lots of scenarios with MPL mixed inside Apache without removal being
possible, then yes, we might as well decide on MPL as the default license.


> The Apache License is an excellent FOSS contributor and distribution
> license for lots of projects. I have myself written such FOSS licenses
> (e.g., AFL 3.0, in our Category A) that are fully compatible with and
> equally generous as ALv2. Our Apache projects currently understand third
> party code
>

"Our Apache projects currently understand third party code"?

Our projects follow (aka understand) the same policy you're railing
against.


> and we don't randomly start mixing it up in our releases.
>

Because we have a policy that strongly discourages that (a policy you want
to change/super-simplify).


> This is a GOOD THING. Nothing needs to change but our Third Party
> Licensing Policy. We just need to stop projects here from being much
> worried about *mixing* FOSS code and making it *appear together*, or at
> least to understand the legal definitions.
>

The advantage of 'mixing' and 'appear together' is that (with description)
they might actually match how someone looks at code. That said, they're
specific for MPL and not great at that. The intent of the terms was to get
you to focus on the mixing scenario for reciprocal licenses and not the
appearing together/collective one.

That said, a deep article on what a derivative work is in software would be
very interesting; not the purpose of this list though.


>
>
> Only when an Apache contributor creates a derivative work of an MPL work
> (as perhaps by mixing it intimately and profoundly with ALv2 software) must
> the mixed result be under the MPL.  Nothing wrong with that. Also that's
> free for anyone to do or undo.
>

Excellent. Now if we have enough legal volunteers to allow lawyers to work
with the projects (because of course everyone on the projects are amateurs)
to help them determine the exact line of derivative work we'll be laughing.
:)

Or we could draw a simpler line (see current policy).

Hen

Mime
View raw message