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