New FOS license for the YafaRay project

[Samo]

Hi there

At the beginning of this project in 2001, the Lesser GPL 2.1 license was chosen because it allowed for integration of our rendering libraries in both FOS and propietary software with almost no limitations.

However, we are at a point where we need a license upgrade to stay compatible with the latest open source releases made by big studios and chip makers, particularly open source libraries released by Pixar and Disney and optimisation kernels released by Intel and AMD. These releases are usually made under the liberal Apache 2.0 license, which is not compatible with our LGPL 2.1 license because of patent litigation issues.

However, there is not a clear path for the license upgrade and anyway we would like to have input from as many people as possible to make the jump, paticularly from users and maintainers of YafaRay exporters. The main issues are:

• There are two FOS options for a license upgrade, which are GPL 3 and Apache 2.0. While we can upgrade automatically to GPL 3, for an upgrade to Apache 2.0 we would need to reach every present and past developer of the YafaRay project to ask for permission. It is not clear that we will find Mathias Wein for instance.
  
• The general public license 3.0 in its two versions GPL ad LGPL poses a tricky issue on dynamic linking. Dynamic linking consist in loading rendering libraries in runtime by a 3D package, by copying the content of libraries from persistent storage to RAM etc. Dynamic linking is considered as a derivative work by the GPL 3 license thus it wouldn't make it possible for using YafaRay in a propietary software using our Render API.
  
• The YafaRay Render API is currently used by the Blender exporter. It allows for direct rendering of a 3D scene without creating an intermediary XML scene description file. Edificius still uses XML files and we don't know about pCon-planner and other packages using YafaRay and not listed in our site. For instance, there is at least one kitchen modeller software that uses YafaRay and more packackes could integrate YafaRay in the future. If we upgrade to GPL3, propietary software won't be able to use dynamic linking with YafaRay rendering libraries.
• In fact the FSF recommends Apache 2.0 for big libraries like YafaRay.
  
• We can improve our scene description XML file (binary files, compression, etc) to make it faster for writing and loading in propietary applications anyway, but it won't never be as fast as dynamic linking.
  
• Apache 2.0 code is compatible with GPL 3 but not the other way around. We could use Apache 2.0 if we release under GPL 3 license, but no Apache 2.0 project can use GPL3 code

We would like to have your input in these matters to make a good decision with all downsides considered and foreseen. We a looking forward to input from developers of host applications and maintainers of exporters. Thanks in advance.

[Samo]

what export method does sketchup use, API or XML file?

[David Bluecame]

Hello,

Sketchup uses the API with Ruby and Qt interfaces.

[David Bluecame]

In any case I don't see why LGPLv3 cannot be used in commercial software?

See: https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3)

[Samo]

Hi David

I am not an expert on the matter. First of all we need to clarify whether YafaRay is currently using LGPL 2 or LGPL 2+ license which corresponds to the "any later version" clause. I have been looking into source files and I don't have a clear cut answer about it. This is an important distinction because if we using the LGPL 2+ license then migrating to LGPL 3 might not be necessary, since LGPL 2+ and LGPL 3 are compatible licenses. We can keep the LGPL 2+ in our source code but release binaries under LGPL 3 when adding libraries released under Apache 2.0. This is basically what the Blender Foundation is doing with Blender (GPL 2+) & Cycles (Apache 2.0)= GPL3 releases.

About LGPL 3 you are right that, given FSF policy on this matter, a LGPL3 library may be linked to a proprietary applications as long as the render API, if used, is LGPL 3 too. Doubts and misunderstanding comes from the fact that the Apache Foundation considers GPL3 (and LGPL3 for that matter) incompatible with Apache 2.0 because of the the dynamic linking question. This means that, at least for some important people, dynamic linking to a LGPL 3 library is considered hereditary to the whole "combined work".

Besides, with LGPL 3 there are very clear requirements about notices that did not exist in LGPL 2.1:
"You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License"

I welcome this addition in some cases (pcon planner), but are commercial host applications that already collaborate with us worried about giving us publicity in installation or execution time if we release under LGPL3?

[David Bluecame]

Hello,

I think LGPLv2+ is not good for linking to Apache2 or LGPLv3 libraries, as the users could choose to use YafaRay with LGPLv2 which would be against such libraries.

Another possibility would be to check the license of each of our dependencies (in LICENSES file) to see if all of them would be compatible with Apache2 license. For example Qt would not be compatible. If we wanted to change YafaRay license to Apache2 we would have to replace our Qt interface with something more liberal such as, perhaps, wxwidgets? http://www.wxwidgets.org/about/licence/ http://stackoverflow.com/questions/6403222/cross-platform-gui-library-with-liberal-license

[Samo]

Hi

I don't understand what you mean, I suppose you refer in case that somebody releases a derivative yafaray code under LGPL 2.1 instead of LGPL 2.1+

Anyway I suggest this path because we stay compatible with future releases of the LGPL license and we keep our options open. If we migrate to LGPL 3 there is not going back.

[David Bluecame]

Yes, if we use part of the code of an Apache2 licensed software within YafaRay, we cannot use LGPLv2.1+ because that would imply that a 3rd party could reuse our or link to our code choosing our LGPLv2.1 license.

If we want to use Apache2 licensed code in YafaRay then we cannot offer our code with LGPLv2.1+ license. We have to use LGPLv3 to require users that reuse/link our code to use LGPLv3 as well.

If we want to keep our options open and continue using LGPLv2.1+, then we cannot link to nor reuse code from Apache2 nor LGPLv3 licensed software such as Embree, Disney BRDF, recent versions of Qt, etc.

[David Bluecame]

Of course, I'm not a lawyer and I could be wrong. I'm basing my opinion on the following references:

https://en.wikipedia.org/wiki/License_compatibility

https://www.quora.com/What-are-the-major-differences-between-GNU-LGPL-v3-and-v2-1

It's true that in a table within this link there are special mentions to LGPLv2.1+
https://www.gnu.org/licenses/gpl-faq.html

In this table it looks like a software licensed as LGPLv2.1+ can reuse code from software licensed LGPLv3. In that case, the combination will have to be licensed as LGPLv3.

In it, it's also mentioned that (and this is nice) a software licensed LGPLv2.1+ can link to a LGPLv3 licensed library (for example recent versions of Qt?) and the combination would still be LGPLv2.1+. This is nice actually.

However it does not mention what happens with Apache2 code. From the above I would suppose the combination of code between LGPLv2.1+ and Apache2 code would have to be licensed as LGPLv3. I don't know whether it would be possible to link to Apache2 code keeping our LGPLv2.1+ license.

[David Bluecame]

Hello,

I've not seen much activity here. What is the decision?

[Samo]

David

The only difference between LGPLv2 and LGPLv2+ is the "LGPLv2 or later" clause added to the begining of the license text, which means that the code is released either under LGPLv2 or the most recent version of LGPL, which is currently LGPLv3. This is why LGPLv2+ is one way compatible with LGPLv3.

While Cycles have an Apache 2.0 license and Blender has got an GPL 2.0+ license, you will find no Apache license in Blender binaries. The Apache 2.0 code and derivative work is released under the GPL 3 license, which is perfectly legal. I think we can do the same:

1. We keep our LGPL 2.1+ headers or/and migrate our LGPL 2.1 source code to LGPL 2.1+

2. We keep Apache 2.0 licenses in Apache non modified source code or in Apache derivative code. We release binaries of that Apache code under LGPL 3 license.

3. We use the LGPL 3 license only in derivative source code that combines Apache 2.0 and LGPL 2.1+. This way we don't need to migrate the whole code base to a new license.

4. Taking into account that YafaRay is a "pluginised" app, we don't need to use a LGPL 3 license in libraries which are dynamically linked to other LGPL 3 libraries in execution time, because it does not make sense that you can dynamically link a LGPL3 library to a propietary software but not to another LGPL 2.1+ binary.

5. Since the Apache Foundation does not allow dinamic linking with GPL code, we release binaries under a dual license LGPL 2.1+ and LGPL 3. The Apache code is relicensed into LGPL3 binaries like the Blender Foundation does.

6. We hope that all of this make legal sense and anyone doing derivative work on YafaRay code is professional enough to understand the full implications of Yafaray dual licensing. For instance, any propietary software using YafaRay should credit us at least in regard to the LGPL3 license. We suppose anyone doing work on Yafaray code will respect each license, and will retain the "LGPL 2.1 or later" clause.

We can as well ask for legal support to our umbrella foundation or to the FSF about these matters, but this will take more time.

[David Bluecame]

Hello, Alvaro.

I like your idea of only changing the headers of the source code where we merge some Apache 2 code. I'm not sure about plugins/runtime linking and licenses, though...

I think the best way of action as you mentioned is to ask SPI and/or FSF about this, to be 100% sure that what we do is correct. I think time/delays from doing so should not be a concern. I personally prefer to be 100% sure that what I do is correct even if it takes longer...

Thanks and best regards!

[David Bluecame]

Hi, Álvaro.

Did you ask SPI / FSF this question about the LGPLv3 / LGPLv2+ / Apache2 licenses?

[Samo]

I don't think it is possible, if we want to honor Apache Foundation's views about dynamic linking to GPL code. I mean, the LGPL 3.0 binary partially made with Apache code could still contain the Apache 2.0 incompatibility with the LGPL 2.1+ license, even in execution time & dynamic linking. Notice that Blender could be in the very same situation. The only clear option is a full migration to LGPL 3 I think. I am pretty sure that the FSF answer, if we ever get one, will be to make a full LGPL 3 migration, and our umbrella organisation does not have this kind of legal services.

[David Bluecame]

Hello, Álvaro.

Please I need to know what the decision is regarding YafaRay's license.

If the decision is to switch to LGPLv3, how should I proceed respect to change the code (put the new license full text in the headers or only a portion/link, etc, etc??)

Best regards.