Licensing for embedding Lux in an application

[jromang]

I
But then lux based on PBRT automatically forbids using it in closed source, right ?

Right

[strattonbrazil]

Matt & Greg choosed the GPL, so here we have to respect their choice (fortunately ) ; personnally I also think GPL is the best choice for luxrender - I would not be happy to see someone using luxrender in a closed-source-commercial application without contributing or giving anything in return.
Here is the FSF point of view : http://www.gnu.org/philosophy/why-not-lgpl.html

I think looking at the article, it seems to make more sense to make luxrender LGPL (ignoring the title). Reading through the article:

Using the ordinary GPL is not advantageous for every library. There are reasons that can make it better to use the Lesser GPL in certain cases. The most common case is when a free library's features are readily available for proprietary software through other alternative libraries. In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.

I guess the question is if this applies to luxrender. Does it provide any features not found in proprietary software like modo's renderer? Or maxwell? Or the slew of other proprietary renderers? I think luxrender might be one of the top open-source renderers right now, but does it do anything especially unique compared to closed software? In that case, it seems the only thing the GPL does is keep luxrender from getting integrated in non-GPL code (including open-source projects under Apache, MIT, BSD, etc.). Yafray runs under LGPL and can be linked to open or closed software without have to create a strictly GPL license.

Right now if a company decided to use luxrender internally, they could modify it as much as they want and not share their changes unless they distributed it. However, if luxrender did provide a LGPL license, a company could attach it to their product and it would be in their best interest to make sure the LGPL product didn't die, and any changes a company made and wanted to distribute would be contributed back to luxrender. It seems at least from the FSF article's description that luxrender is a better match for LGPL than GPL.

If Autodesk, for instance, decided that mental ray wasn't the best choice for Maya anymore since it is now owned by nvidia, they would have to pick a new renderer. They would license or buyout a product from a myriad of quality renderer developers, but if they certainly couldn't choose luxrender just because it's GPL and (as the article states), there aren't any compelling features that differentiate luxrender from other commercial products (no offense -- awesome renderer). If it were LGPL, luxrender would be used in a huge world-wide product and Autodesk would be insane not to contribute back to it. This might seem like a trite example, but it's a factor in choosing an integrated renderer (not even in just closed-source but non-GPL open-sourced software). Exporters are nice, but I think integration is extremely important in today's workflow. I can't agree that having luxrender integrated into Maya, Softimage, or any other commercial app would be anything but a win for luxrender.

I know the LGPL may seem evil, but the FSF didn't provide it for it never to be used. That would be silly. If one were to decide based strictly on FSF's recommendations ("a free library's features are readily available for proprietary software through other alternative libraries"), which features are available in luxrender not available to proprietary alternatives?

[jeanphi]

Hi,

And your point is?
Right now LuxRender is interfaced with quite a lot of software, it provides tight integration even with non GPL software and various companies are quite happy to use it as it is now.
A relicensing is out of the question anyway and I quite like the fact that it is GPL licensed (and I don't think I'm alone).

Jeanphi

[pixie]

In the sense one doesn't have to GPL windows to use GPL software I don't see why one couldn't find a solution to integrate Lux as a render in a given software, providing the part that binds both software is GPL.

[strattonbrazil]

Right now LuxRender is interfaced with quite a lot of software, it provides tight integration even with non GPL software and various companies are quite happy to use it as it is now.
A relicensing is out of the question anyway and I quite like the fact that it is GPL licensed (and I don't think I'm alone).

Jeanphi

What do you consider tightly integrated? I was under the impression of the the exporting tools don't use any particular luxrender GPL libraries. I see support for C4D, SketchUp, XSI, etc. but these are these tightly integrated? I thought they separate tools that wrote out to a luxrender-compatible scene file, or sent a scene to a luxrender server. Is that correct? I don't own any of those products (besides Maya), so I don't know how they've been integrated. Can you, for instance, do progressive renders in those programs? I imagine a lot of people have wanted to use luxrender in proprietary tools.

My point, and I don't mean to sound facetious, but if LuxRender would be more integrateable in these tools if licensed under the LGPL? It seems right now these programs can't link to luxrender libraries directly. Have they found a way around that in every case? It just seemed like it would be ideal to have an LGPL license in that case. Lord Crc mentioned that right now all exporters cannot be linked to the source unless they are GPL and send the scene via stdin and get an image back. Maybe this provides a level of integration that's transparent to the user, but if that's the case why GPL over LGPL then? From an open-source project point of view, it doesn't matter. But from a closed source project, picking LGPL just means it's harder to implement.

GPL - current license - jump through an extra hoop to send data to a separate luxrender process
LGPL - just compile the two together, tighter integration (at least from a developer perspective)

Both have the advantage of not allowing changes to be distributed, but GPL means you have to do a little extra work to get your data over to luxrender simply to bipass the license issue and the other just accepts the fact that people want to integrate it. If that's the case, is the only reason to GPL the product to make it harder to interface to, and then provide interfaces to interface with it to get around the GPL?

Why is a relicensing out of the question? This is your project and I'm asking more for curiousity (and I was considering integrating luxrender into my app, which may have to move to a GPL license from BSD). What are the advantages of GPL over LGPL in luxrender? Is it an ideological perspective? Are there features a 3rd-party cannot use because it's GPL'd and not interfaceable through the network or a system pipe?

Thanks.

In the sense one doesn't have to GPL windows to use GPL software I don't see why one couldn't find a solution to integrate Lux as a render in a given software, providing the part that binds both software is GPL.

The GPL provides special exceptions for "system" libraries to a specific OS. I don't think that applies here.

[jeanphi]

Hi,

Modifying the license would require approval of all present and past contributors, and that wouldn't be feasible. I don't want to prevent interaction with closed source solutions, but the GPL is a nice signal that this is not the preferred way of making use of LuxRender. This is central to LuxRender, PBRT has been designed to be used and extended by the academic world, and LuxRender is trying to extend that to provide a production ready solution where new ideas can be implemented and provided to all users.
Exporters can be GPL licensed and written as scripts for example, this doesn't require the hosting application to be GPL licensed.

Jeanphi

[pixie]

Hi,

Modifying the license would require approval of all present and past contributors, and that wouldn't be feasible. I don't want to prevent interaction with closed source solutions, but the GPL is a nice signal that this is not the preferred way of making use of LuxRender. This is central to LuxRender, PBRT has been designed to be used and extended by the academic world, and LuxRender is trying to extend that to provide a production ready solution where new ideas can be implemented and provided to all users.
Exporters can be GPL licensed and written as scripts for example, this doesn't require the hosting application to be GPL licensed.

Jeanphi

So Lux can't use say cinema 4d sdk due to it's own license? So it hinders itself, weird... or somehow it assume that by using cinema's sdk (as an example) it has somehow become derivative work of lux... ?

[jeanphi]

So Lux can't use say cinema 4d sdk due to it's own license? So it hinders itself, weird... or somehow it assume that by using cinema's sdk (as an example) it has somehow become derivative work of lux... ?

Why would Lux use C4D SDK? An exporter could use C4D SDK, be GPL licensed and also use Lux as a library, right? And if C4D SDK license prevents use by a GPL licensed exporter, why would it be better that Lux changes its license rather than C4D SDK?

Jeanphi

[pixie]

So Lux can't use say cinema 4d sdk due to it's own license? So it hinders itself, weird... or somehow it assume that by using cinema's sdk (as an example) it has somehow become derivative work of lux... ?

Why would Lux use C4D SDK? An exporter could use C4D SDK, be GPL licensed and also use Lux as a library, right? And if C4D SDK license prevents use by a GPL licensed exporter, why would it be better that Lux changes its license rather than C4D SDK?

Jeanphi

I suspect that if cinema doesn't have problems with closed source plugins that it wouldn't have with open ones. AFAIK cinema's own SDK allows seamless integration within Cinema, while no derivative happens in the process. I would love to see such implementation in the future.

[strattonbrazil]

Hi,

Modifying the license would require approval of all present and past contributors, and that wouldn't be feasible. I don't want to prevent interaction with closed source solutions, but the GPL is a nice signal that this is not the preferred way of making use of LuxRender. This is central to LuxRender, PBRT has been designed to be used and extended by the academic world, and LuxRender is trying to extend that to provide a production ready solution where new ideas can be implemented and provided to all users.
Exporters can be GPL licensed and written as scripts for example, this doesn't require the hosting application to be GPL licensed.

Jeanphi

That makes a lot of sense. Thanks.

In regards to sending the scene to a luxrender session, does that mean you can't do progressive renders? I was looking at LuxBlend and that seems to just take the scene and launch a luxRender type session where you see the progressive rendering there. Is that supported without linking to the library?