Future of open source JUCE?

General JUCE discussion
1

This post has been updated to reflect the outcome of discussion below.

When visiting the JUCE website, it is increasingly difficult to find mention of the open source code and licensing. Rather, the marketing language is oriented towards the commercial licensing options.

Note: after discussion, the above concern still remains. It may be something to be worked out with the JUCE marketing and website management team alongside a JUCE community advocate.

When one does manage to find the open source repository, they are immediately informed that the code has additional terms and conditions, such as requiring the acceptance of a privacy policy permitting data collection from downstream users. These additional terms and conditions seem to be incompatible with the spirit and definitions of Free Software and Open Source Software. Furthermore, the main repository now contains code that has long been known to be incompatible with any free/open source project, namely the Steinberg VST SDK.

Note: The concern about the README still stands, but with better understanding. It was agreed that it would be useful to describe more clearly how GPL projects are exempted from the End User Agreement and Privacy Policy, which is mentioned in source code headers. It has also been explained that downstream developers are responsible for removing any GPL incompatible code, namely the Steinberg VST2 SDK from their projects, since JUCE is merely distributing the SDK with permission from Steinberg for convenience of developers.

Note: the following statement is in error, and was clarified in further discussion.
It is a shame, as in videos from even one year ago JUCE seemed to be a mature open source project with a thriving community. Even the commit history for the main repository has dwindled considerably in the past year.

Note: the following statement is also better understood. However, I am not the only person with these concerns.
What is going on with this project? Should we look for alternative frameworks for open source audio development?

2

I checked GitHub and I think they make it super clear: https://github.com/WeAreROLI/JUCE

3

The github main page says by downloading the library you agree to the privacy policy.
However, if you license JUCE under the GPL, then you don’t have to agree to the privacy policy. That privacy policy also doesn’t mention the GPL as an exception, so I don’t think the language on the github page is very clear.

Also later in this paragraph there is no mention of the GPL as an exception to this:

However, the license at the top of every source file is pretty clear:

   This file is part of the JUCE library.
   Copyright (c) 2017 - ROLI Ltd.
   JUCE is an open source library subject to commercial or open-source
   licensing.
   By using JUCE, you agree to the terms of both the JUCE 5 End-User License
   Agreement and JUCE 5 Privacy Policy (both updated and effective as of the
   27th April 2017).
   End User License Agreement: www.juce.com/juce-5-licence
   Privacy Policy: www.juce.com/juce-5-privacy-policy
   Or: You may also use this code under the terms of the GPL v3 (see
   www.gnu.org/licenses).
   JUCE IS PROVIDED "AS IS" WITHOUT ANY WARRANTY, AND ALL WARRANTIES, WHETHER
   EXPRESSED OR IMPLIED, INCLUDING MERCHANTABILITY AND FITNESS FOR PURPOSE, ARE
   DISCLAIMED.
1 Like
4

I don’t think this is the case. What files?

And a side note, the newest VST SDKs are now dual licensed under the GPL. Did you mean the old ones?

1 Like
5

This is the paragraph that is most concerning:

BY DOWNLOADING, INSTALLING OR USING ANY PART OF THE JUCE LIBRARY, YOU AGREE TO THE JUCE 5 END-USER LICENSE AGREEMENT AND JUCE 5 PRIVACY POLICY, WHICH ARE BINDING AGREEMENTS BETWEEN YOU AND ROLI, LTD. IF YOU DO NOT AGREE TO THE TERMS, DO NOT USE THE JUCE LIBRARY.

6

What makes you think that? A quick look here will show you that the last 12 months have been the most active yet


I agree that the wording could be clearer and it’s something we’ll take a look at. The majority of JUCE users are at least contemplating releasing their JUCE-based software and the language in the README addresses them.

JUCE contains multiple parts that are licensed differently. There are more permissive licenses found in the included audio formats like the FLAC library, and the VST SDK is dual GPL v3 licensed. If you want to release your software under the GPL v3 (or you’re simply not releasing your software, just using it for your own ends) then you’re not bound by the terms of the JUCE 5 license and nothing else will prevent you from doing that.

2 Likes
7

There is a issue describing the VST2 SDK on GitHub.

Ah, my mistake. I can’t remember what repository commit graph I saw recently to give me that impression.

Ok, thanks. It would be helpful to have both a clear description of the GPL exception to the privacy policy and a clear statement that end-user tracking would not happen. :slight_smile:

8

Just to hammer this home:

No, of course we’re not considering ever dropping the GPL.
To suggest that there’s even a possibility of that happening is complete fantasy.

Clear enough?

It would be a stupid move for us to make, and nobody here has ever even floated the idea.

Although
 let’s not forget that a big chunk of our code did already drop the GPL
 to become even MORE permissive, moving to the ISC license :slight_smile:

Fair enough that you misunderstood a few things, but now you’ve left us with a FUD-laden post, with an incendiary title, any many casual readers who are considering JUCE might see it and think “oh hey, here’s a guy saying that JUCE is abandonware and that it won’t be open-source any more, perhaps he knows something I don’t
”

We don’t censor or correct people’s posts on the forum, and we like it when people call us out for the many real mistakes that we make. But it would be appreciated if you’d add an edit to your post to acknowledge things you’ve since learned.

This has already been discussed repeatedly elsewhere, but the TL;DR is:

Steinberg kindly allowed us to include the SDK because a lot of JUCE-users need it.

Whether you choose to keep those files, use them, ignore them, delete the folder, or whatever else suits you is entirely your own business.

If you don’t build a VST2, then the SDK is just a bunch of ignored bits on your disk, not some kind of thought-crime.

Whether or not you’re allowed to release software that uses VST2 is not a question that we can’t comment on - it’s a question for your legal advisors or Steinberg to answer. We’re simply helping you get their files into the correct place in case you need them.

1 Like
9

I have adjusted the original post to better reflect key take-aways from this discussion.

10

I think the main concern (from the related GitHub issue) is the VST2 SDKs become part of downstream ‘forks’ of the JUCE repository. To my knowledge, Steinberg did not give third parties, who may have forked JUCE, the right to distribute the VST2 SDK code.

11

Who’s problem is that? Not JUCE’s problem!

12

Like I said in my reply to that issue: if you don’t want those files in your fork, then just delete them from your fork!

(I mean, the whole point of making a fork is to let you modify the repo!)

Seriously, nothing to see here, move along.

2 Likes
13

How do developers sync changes with the JUCE repo, if they don’t want the VST2 SDK? How might people access the VST2 SDK on an opt-in basis? There may be a middle ground here, where the proprietary SDK can be made available to developers who want/need it, without including it in the Free Software codebase.

14

Oh, wow, I’ve no idea. How on earth could anyone possibly keep a fork or branch in sync with the original branch using only the GIT source control system
??

I mean yeah, I guess Linus never considered how you might keep some changes in sync with the origin when he designed GIT for THAT EXACT PURPOSE.

Maybe try this simple breakdown of the “problem”:

  • The only people who could possibly think they face any kind of legal issue are people who have a public JUCE fork on github.
  • The only reason for creating a JUCE fork (or any fork of anything) is to maintain your own set of changes and keep them in sync with the original repo.
  • So anyone who could possibly care less about this is ALREADY maintaining a fork of some changes against our repo and presumably understand how forks and merging/rebasing works.
  • For them to adding one more commit where they delete the VST2 SDK is a 30-second one-time task.
  • Everyone else can just pull from our original repo and get on with their lives.
1 Like
15

Except for one point you mentioned. If we fork JUCE and remove the VST2 SDK, then we end up with a new repository that cannot be reconciled with the official JUCE.

16

What do you mean by “reconciled”?

17

Indeed, reconciled may not have been the proper word. There is just no way to remove the VST2 SDK from the history of the repo (which is what the agreement says) and still be able to pull changes from the original one.
I suppose it’s a question of legal view, can we say that it has been deleted if it’s just in the history bu not on HEAD anymore).

18

You mean the fact that you’ll have a git commit with the files being deleted?

19

Csound got a warning about the VST sdk and it had to be removed from the history as well. Created a bit of a mess too. I don’t think it’s enough to remove from the HEAD.

20

Hmm, I’m not a lawyer so don’t really know about this. I guess if you fork a repo, is all the history considered “yours” or is that still “JUCE/Roli’s”?

This is a fairly unique case as JUCE has official permission to host the SDK. I think that agreement would have to specifically include allowing it in either “forks” or “fork histories”.

One for Steinberg really.

1 Like