Third-party products and services that provide JUCE

Commercial / Licences
1

The JUCE 8 EULA contains a new clause that governs the provision of products or services that make it possible for others to create plug-ins and software containing JUCE.

1.4. Products

A product (“Product”) is any product, service, or project that combines the Framework with any other source code, object code, content or any other copyrightable work. You own all rights in any Products you create aside from our rights in the Framework, which we retain ownership of at all times.

1.12. Products That Create Products

You may not create, make available as a service, nor Distribute Products that create other Products. Any Products that are created using software or a service must be licensed by the user of that software or service.

Please contact sales@juce.com for an alternative licence agreement if you want to Distribute Products that create Products.

We will be changing the definition of “Product” above, but I think we can still provide some useful information about 1.12.

We already have bespoke EULAs in place with companies providing similar services. These agreements are covered by NDAs, which were all imposed by those companies, not us. I cannot share the structure of those agreements, nor even the names of the companies involved, but you can guess. The current EULA is a very poor fit for such services. It is a bad enough fit that we are already working outside of it for major platforms using JUCE to create plug-ins. We have introduced a change that is both rational and formalises the current status quo.

Despite being limited in what we can say about existing licensing arrangements, we can state that they are all quite different, and are all dependent upon what the service is providing to users. Working out a fair licensing deal will likely depend on a lot of different factors that would be difficult to put into a single template. There is, for example, no single template that would apply to all of the existing arrangements we have. We have been able to accommodate all of these different companies, with terms that I believe benefit both parties, so I’m confident we could offer the same to you.

Some additional requirements are likely to be:

  • the licensee must notify JUCE of all sales of products that create other products
  • the licensee must identify products that create other products to all users as being “Powered by the JUCE Framework"

Then, dependent upon many different factors, either:

  • a per-unit fee for each product that creates other products
  • a percentage of all revenue collected from a subscription providing access to products that create other products

This would then remove any legal requirement for an end-user of your product or service to obtain their own JUCE licence for the JUCE derivative they have created.

However, please let me state again that there is no single template that fits all of the licensing arrangements we currently have in place. The above is a starting point for a discussion, but if those additional points are a poor fit for your service that doesn’t prevent us from working out an alternative arrangement.

6 Likes
2

@t0m thanks for your continued communication and efforts around these changes. The clarity is appreciated, and I also am thrilled you are being so active seeking community engagement.

On this one, let me throw in an example which may help with your drafting which I don’t think is what you intend.

Imagine I create a perl script baconStartJuce which takes three arguments. The first is a plugin name and the second is one of three types Synth, Delay, or MidiEffect. The third is a directory.

When you run that script it sets up that directory with my baseline juce plugin. You know, git init, the submodules i want, write a shell cmake file, create a plugin processor and editor shell, and hook up the innards to a basic plugin.

So using your definition that perl script is a “Product” - it combines the Framework with etc… - and it creates other products. But it only creates them in source form. To be useful you compile it, acquire a juce license, etc…

And for total avoidance of doubt, if you use that (imagined) perl script and make a cool vst3 and sell it you need to own JUCE.

The perl script is a dumb example, but several bits of software (like sudaras starting point repos which are very popular) rhyme with it.

I don’t think you mean to have those efforts be blocked by the EULA, nor make them available only to AGPL3 users, but I figured I would ask.

If you don’t want to hinder those classes of things, perhaps you want a concept like “Distributable Product” or “End-User Runnable Product” to distinguish from “Source Product”? You know “A product is … with any other copyrightable work and which is distributed in binary runnable form for end users or made available for use on a server via any network protocol” (which I’m sure your lawyers can turn into 17 sentences :))

Clearly if I set up a CI pipeline which built those vst3s and signed them and made them so you could slap on your logo and sell them without you running a compiler, i should call you. And clearly if I write that code then run the software server side to add delay to wav files, I should call you. Absolutely clear. But there’s some source-to-source angle here also (just like there is with the subordinate library issue I know you are working on) which I think may require a bit of care.

Thanks again for the transparency and efforts here.

5 Likes
3

As far as I understand all „products that create software using JUCE“ can be licensed under the GPL right? That of course does not affect the requirement of the end user to license JUCE as if he would have used JUCE directly but that would apply to most open source build systems.

1 Like
4

Thanks for the clarification. Still I have some question regarding 1.12 because the only way I understand it, it doesn’t make much sense to me, so I hope I am wrong.

Suppose SomeCompany makes and sells a desktop application named PluginFactory.
This application can be used by the customers to create plug-ins that are made with JUCE, think of it as a tool like ProJucer, but it emits the resulting plug-ins already in binary form, i.e. the user doesn’t need to compile anything themselves (for example, PluginFactory may be shipped with a pre-cooked static library that uses JUCE internally, and it uses some local or remote build tools to compile the final product).

These generated plug-ins clearly are Products (capital P = made with JUCE), and that’s without question, and:

  • If PluginFactory is itself compiled with JUCE, then PluinFacotry is undoubtedly also a Product, and it is a product that makes other Products, so according to rule 1.12 it is forbidden.

but

  • if PluginFactory is NOT made with JUCE, (for example it uses QT, or it is made with Java, etc.), is it a Product? Or it is just a tool, not a Product, that creates plug-ins which are in turn Products?

If in this latter case PluginFactory is not a Product, then it seems unnecessarily arbitrary to forbid that it becomes a Product only when it is made with JUCE, isn’t it? After all, the “damage” is in the fact that it generates JUCE plug-ins, not whether the generator is made with JUCE or not, right?.

On the other hand, if PluginFactory is considered a Product anyway, then it seems that anything that generates Products is also a Product, and thus should be forbidden. If this is the case, then it should be impossible to obtain (emphasis mine):

The only way I see this possible is that there might be a distinction between “generators” that create binary plug-ins that are ready to use (forbidden) and “generators” that e.g. generate the IDE project, which has JUCE as a dependency, and the final user builds its plug-in with it. In this latter case, the final user can do so only after having obtained a JUCE license, which sounds obviously fair

1 Like
5

If you are complying with the (A)GPLv3 then you are completely separate from the JUCE EULA.

If, at end of a build system available under the GPLv3, you have a derivative of JUCE where all you need to do to make it non-GPLv3 is licence JUCE from us under the JUCE licence (so no bits of the GPL build system made it into the end product), then that would be very similar to how you would build JUCE locally.

6

Surely for it to have the ability to make a JUCE plugin, it must contain JUCE (either original source code, or pre-compiled libraries) so even if it’s not made with JUCE, it still contains JUCE?

GitHub Actions is a service that produces JUCE plugins - however GitHub Actions itself doesn’t contain any JUCE. You, as the user of GA, have to pass JUCE as a dependency to GA. I think that’s the difference - PluginFactory “knows” about JUCE and so is therefore a “JUCE Product”, whereas GA doesn’t “know” about JUCE and so isn’t.

How you put that in legal terms I’ve no idea :sweat_smile:

7

As I mentioned in the other thread the industry standard is something similar to Qt:

Applications may not pass on functionality which in any way makes it possible for others to create software with Licensed Software

We want to be less restrictive than that. We are aware of existing projects that add lots of value to the JUCE ecosystem where those projects allow a user to plug their own version of JUCE into the process. If a user has to supply their own copy of JUCE then it is unambiguous that they are creating their own derivative of JUCE, and that they would require their own licence. We want to continue to allow these projects to operate without the additional overhead of a custom licence agreement. These projects are not creating Products, the users of these projects are creating Products.

In most cases the ability to create a JUCE plug-in means that PluginFactory would have to contain JUCE. However, it may do something dynamic like pull JUCE from a web server, so we have the follow up clause too:

Any Products that are created using software or a service must be licensed by the user of that software or service.

8

Yeah I think this is exactly the correct way to think about the question I raised and matches what think people expect! So sounds like this issue is “just” drafting to make it clear. Excellent and thank you!

Those projects may also be products in their own right of course but my key question was about developer and source generator tools getting swept in. If I wrote my own projucer and it didn’t use juce that’s not a product. Cool!

9

Ok, thanks @t0m for answering my questions from the other thread, best as you could. I understand that this is a more complicated topic.

So in order to reach out and talk about our licensing, we will need to spill the beans on the details of our platform to you. And as you said, everyone else has NDAs on their part. So, what’s the process here? Do i first send an NDA to sales before i tell them what this is about or do you have processes/documents in place for that? Will it be possible for us to finalize that deal, even if all the other JUCE 8 EULA mess is not resolved yet?

Before the JUCE 8 EULA dropped we were in the process of hiring a legal firm for our company organization, and pushing all of this out until the final JUCE8 EULA is resolved sounds horrible. But from what I understand this is all separate from the regular EULA anyways and we can figure this out - and finalize it - with sales in parallel?

10

A product (“Product”) is any product, service, or project that combines the Framework with any other source code, object code, content or any other copyrightable work. You own all rights in any Products you create aside from our rights in the Framework, which we retain ownership of at all times.

I think we may be able to change “combines” to “is a combination of”, and maybe get all the way there.

1 Like
11

Please send us an NDA - you have a much better understanding of the things that you want to protect than we do. I’m sure we can work something out.

2 Likes
12

Clever!

13

Alright I think we’re all getting a clearer picture now. Please forgive me if this got cleared up anywhere already but one thing that isn’t addressed yet is how to handle dynamic logic being developed by non-C++ coders and whether they need to get an additional JUCE license even if they are not “closely working with JUCE”.

There are quite a few platforms which offer this and I can totally understand that there won’t be a one-size-fits-all solution, so maybe just let me sketch out three different developer types which are using my platform and hopefully this will make it a bit less abstract so people can deduce it for their use case too:

  1. A UI logic designer. They will most likely be using the Graphics API in HISE which closely mirrors the JUCE API including typing stuff like (g.fillRect(this.getLocalBounds(0));), which is more or less a direct wrapper around the JUCE call.
  2. A instrument logic designer. They will be working in Javascript to develop high level instrument logic like portamento legato or key switches. The API mirrors a few classes from JUCE (eg. the MIDI message class), but the bulk of the API they use is customly made for this purpose.
  3. A DSP developer (non C++). They will be using a visual programming environment to stack high level DSP modules together with the option of writing custom C++ code or Faust code (which does not really depend on JUCE). They are not using anything that resembles the JUCE API.

So my educated guess would be that 1. (and eventually 2.) will now require a JUCE 8 license (where they were fine with a single company wide JUCE 7 license as long as there was only one developer handling the final assembling and testing). What about developer type Nr. 3? Would they be fine without a license - they basically are the same as a C++ coder who develops DSP code with his own framework and I think that this shouldn’t require a JUCE license.

I’m just trying to gather a bit more information as I will have to communicate this to my clients in a transparent way. I’m also happy to continue this conversation in private, but I think a question this generic might still be of interest for the general public.

1 Like
14

I understand this will be a frustrating response, but we are working on changing the definition of a Product and a contributor. As this requires legal input it is doing to take a few days. Once we have a clearer idea of what’s possible I’ll be able to answer those questions.

1 Like
15

No worries, take your time I just wanted to make sure that this topic doesn‘t get buried in the noise as I think it will have strong consequences for many projects.

16

No, not necessarily, As an example…

My Product (SynthEdit) contains no JUCE.

However, it can write to disk a bunch of source-code that when combined with JUCE and compiled will build a functioning plugin.

I don’t own any JUCE license, I do not distribute binaries containing JUCE code. I am not subject to anything in the JUCE license. I owe JUCE no money.

An end-user of my software would need their own JUCE license to distribute plugins that have been created via this functionality that SynthEdit provides.

5 Likes
17

But I think that‘s fair use - if the end user combines this with JUCE after exporting (which looks like an optional step from your description) he uses JUCE and needs a license, no?

18

If we change the definition of a Product to be “is a combination of” other content and JUCE, then SynthEdit would not be creating Products, and we don’t restrict that use case. That’s what we’re aiming for.

2 Likes
19

@chrisboy2000 I think the proposal for the new language means that you are correct with your determination of 1., 2. and 3. from your previous post.

Given HISE provides the option for a user to supply their own copy of JUCE to export plug-ins, would you consider a custom licensing agreement along the lines suggested by the original post in this topic? For your users wanting to create plug-ins like this, having to separately licence and combine JUCE is not a great workflow (but I do want to stress that we want to keep supporting this option!) and we could make this easier and potentially more cost effective for them. No need to reply in this thread! I just wanted to surface the idea so that anyone in a similar position could consider it.

20

will this apply to older juce versions? That is to say, will it be fine if the product keeps using Juce 6 or 7?