"dual licensing"
IMO when Apache 2.0 licensed code is merged into Llama 2 Community License Agreement (L2CLA) licensed code, the resulting output falls under L2CLA, and this is quite self-evident.
It's similar to the situation of when Apache 2.0 licensed code is combined with GPLv3 licensed code - because Apache 2.0 is a permissive license, the combined code falls under GPLv3. The licenses are compatible in the sense that code from one can be merged into the other, but not that the output is dual licensed - the less permissive license takes precedence over the more permissive license.
L2CLA is less permissive than Apache 2.0, but for different reasons than GPLv3. Nevertheless, the same principle still applies. The Apache 2.0 license explicitly allows relicensing while L2CLA does not. All you have to do is include attribution for the Apache 2.0 licensed code at the point you do the merge.
Additionally, clause 1.b.v of the L2CLA states:
"v. You will not use the Llama Materials or any output or results of the Llama Materials to improve any other large language model (excluding Llama 2 or derivative works thereof)."
I think the L2CLA was written without the concept of model merging in mind, but model merging is allowed under the L2CLA so long as the merged model is considered a derivative work of Llama 2.
L2CLA doesn't have a relicensing clause; this does not mean that it's an open question, it means that relicensing is not allowed. On the other hand, the Apache 2.0 relicensing clause is designed to have high compatibility:
"You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License."
The person doing the merge just has to comply with the Apache 2.0 terms themselves when releasing the merge (i.e. keeping attribution notices intact). The L2CLA attribution clause is actually weaker than the Apache 2.0 attribution clause, but that doesn't matter because of Apache 2.0's permissive relicensing clause - the person doing the merge has to follow the Apache 2.0 terms, but the terms aren't expected to travel any further than that.
In summary:
IMO TheBloke you shouldn't just rely on the original model poster for the license terms. Your quantized model would also be considered a derivative work of Llama 2, and if Meta decides to start going after people legally I doubt they'll stop at the point in the chain where the licensing error occurred.
It would be good if Huggingface themselves provided some official advice on this, but they are under no obligation to. Ideally since Mergekit can read Huggingface metadata it should refuse to merge models that have incompatible licenses and choose the correct output license if the licenses are compatible, or at least warn users about the implications, but again they are under no obligation to.
In any case, this is a legal ticking time bomb for the open source LLM community. The purpose of the Llama 2 license is clear - Meta is happy to let the open source community do its thing, but if any of the work is commercialised in a significant way down the line, they want to be able to claw back some of the profits. That does not work if a derivative of Llama 2 is ever erroneously relicensed under any other open source license - whether that's by a commercial operator or by a hobbyist.