ASL 2.0 | MIT

[sirinath]

Is it possible to change the license to ASL 2.0 and / or MIT

[cjbrooks12]

No, I don't have any plans to change the license or release it under multiple licenses. I intentionally chose LGPL for this project, as it best fits the goals I have for it while still being flexible enough that it shouldn't prevent anyone from using it how they want.

What reasons do you have for wanting the license changed?

[sirinath]

Quite a few organisation have licensing restriction on viral licenses.

[cjbrooks12]

Yes, I am aware that it might fall under a licensing black-list from some organizations, but the LGPL license does permit private usage within an organization (unlike the GPL), so any restrictions there are self-imposed. An organization is free to use Orchid to create their websites without disclosing any of their sources, according to the LGPL.

But my target audience is for open-source projects, where I do wish the viral clause to remain.

[sirinath]

If you are small contractor the number of clients you can use is lesser and trying to negotiate if the license is not readily whitelisted takes time and you don't get paid for this time.

[cjbrooks12]

Is this situation something you are currently experiencing and having issues with?

[sirinath]

This is an issue which comes up with software which does not have readily white listed licenses.

[cjbrooks12]

Well, unfortunately I just am not going to be able to fully support every use-case as much as I would like to. Orchid still has a small community and I haven't heard anyone having a problem with the license yet where that was the primary reason they couldn't use it.

The license will remain LGPL, but I'm willing to continue this discussion with anyone who does run into a situation where Orchid's license is blocking their adoption of it.

[sirinath]

I am writing to see if you are willing to revisit this issue. I have looked into Hugo and Zola but still Orchid is at the top of my list if the licensing issue can be sorted.

[cjbrooks12]

Do you now have a specific project where the client is not wanting to use Orchid on the project because of the license? I am sorry, but at this time I'm not willing to re-license Orchid on a hypothetical situation that may never actually happen. If there is a specific situation you're dealing with, then I will certainly be willing to revisit this concern and try to find a resolution that works for both of us.

Also, note that even Google has an exception for LGPL on their ban of "restrictive" licenses. If Google makes available the possibility of using LGPL code in their shipped products, I think you could make a strong case to your clients too. Keep in mind that simply using Orchid to generate a site, or even writing your own plugins, are both considered "dynamically linking" to it and are not modifying and redistributing it, and as such your sources/inputs/plugins for it are not required to be disclosed (as would be the case with GPL).

[sirinath]

At the moment the concern is hypothetical but never the less real concerns which pop up. Negotiating issues related to licenses take time and effort which is not paid for. If this happens multiple times this is compounded. Simply saying we avoid any problematic licenses simplifies things and helps cut down time spent on addressing these concerns. E.g. If a project we use gets abandoned and we pay for its maintenance of the project do we own the code we paid for [without restriction].

[cjbrooks12]

Yes, I do understand the concern. But changing the license is not as simple as just replacing a text file in the repo. I'd need to do an audit of all dependencies to make sure they comply with the new license and find appropriate replacements if they do not. I'd need to publicize the new license so all other users are fully aware of the change, and potentially work with them to make sure their projects comply with the new license. All this is work that I'm not paid for, and the loss of control I have over the project with a more permissive license is something that could cause serious concerns for me and for Orchid over time, especially if I ever decide to try and monetize Orchid in some way.

But please hear me: my intention is not to prevent you from using Orchid for your client work. In fact, I want to enable you and empower you to do so! But right now, neither of us know this will actually be a problem until you ask your clients about it. And if they do have concerns, then at that point I would be willing to discuss options for you, so that you don't have to have those same conversations and losses over and over. Maybe it would be selling a premium version of Orchid without the LGPL license. Maybe Orchid will have gained enough popularity by then that I would feel comfortable changing the license. I really don't know what it would look like, which is why I do want to have conversations about this, but I do feel like changing the license is something that needs to come as the resolution of a real problem, not as the prevention of a future problem.

So again, I will be keeping the LGPL license for the time being. And I'd encourage you to move forward and present Orchid to your clients in its current form, with its current license, because you really don't know; they may just be OK with it. If a client does push back because of the license, please do reach out so we can resume this discussion with that real problem to solve, or I can help you find an alternative tool that solves your problems and has a license your clients are OK with.

[altavir]

It is not necessary for all dependencies to be of the same license if you are not using custom distribution. Classpath exception is invented exactly for that.

[cjbrooks12]

Now, I'm not a lawyer, nor have I consulted with one, but I believe that exception is in a modified version of the GPL license and is not generally applicable to all Java libraries licensed under GPL. There is a general exception to system libraries, such as the Java stdlib. But if any of Orchid's dependencies are GPL, being dynamically linked to them through the classpath requires Orchid to also be licensed under a GPL-compatible license (such as LGPL).

At this time, I believe that all of Orchid's dependencies have MIT, ASL, BSD, or other permissive licenses, but I would still need to double-check that before making any changes to Orchid's license, to ensure I don't potentially break compatibility with any of them.

[sirinath]

So again, I will be keeping the LGPL license for the time being.

I respect this as this is your project.

And I'd encourage you to move forward and present Orchid to your clients in its current form, with its current license, because you really don't know; they may just be OK with it. If a client does push back because of the license, please do reach out so we can resume this discussion with that real problem to solve, or I can help you find an alternative tool that solves your problems and has a license your clients are OK with.

Most probably many potential clients will be OK with the current license. But if we spend some time on developing themes and other POC when we show it around any licensing issue pops up it will be sunken cost to us. There may be instances we might not find any new work regardless of the license but having conducive license increase the chances. So for things we are exploring and trying out we like to minimise the risk.

But changing the license is not as simple as just replacing a text file in the repo. I'd need to do an audit of all dependencies to make sure they comply with the new license and find appropriate replacements if they do not.

To change the license you don't need to worry about the libraries you just have to ask those who have contributed unless you have a GPL style license without linking exceptions in your dependencies. If you have a GPL dependency then the project will have to be GPL. As the number of contributors increases a GPL style license becomes difficult to change as you have to get permission from every contributor unless you have a contributor license agreement.

All this is work that I'm not paid for, and the loss of control I have over the project with a more permissive license is something that could cause serious concerns for me and for Orchid over time, especially if I ever decide to try and monetize Orchid in some way.

If you want more control of the project a Contributor License agreement is something you might want as you will own the contributions also, but many companies do not let employees sign contributor license agreements which means contributions many become less. Recently Racket changed its license and the process was a nightmare: https://github.com/racket/racket/issues/1570 as they did it rather late then there were many contributors.

[svenruppert]

@sirinath Please, stop NOW. It is not the first project you are asking for it: for ex. here: https://github.com/SwiftLaTeX/SwiftLaTeX/issues/1 Respect other peoples choice. Maybe it is time, that you are helping other projects, instead of just using them for your own business?

[sirinath]

@svenruppert I respect the choice. I just aked just to see if this is possible and responded to the follow-up comments. As for SwiftLaTeX I found an alternative which is LaTeX.js which meets my requirement. Any way SwiftLaTeX is unrelated to Orchid.