Congrats on the acquisition!
I'm really excited to see how this improves the development of JUCE. Jules, you deserve this.
Also, I'm loving the blurry picture being used within the promo of this aquistion ;).
Congrats on the acquisition!
I'm really excited to see how this improves the development of JUCE. Jules, you deserve this.
Also, I'm loving the blurry picture being used within the promo of this aquistion ;).
Thanks - the whole of SLUSH was a bit blurry to be honest! :)
yup, thanks folks at Nu Desine for making such good looking GUI, we're proud to use it in the banner.
I'd like to see JUCE switch to a permissive software license (i.e. non-GPL). For example the ISC License, or the MIT License.
Inspired of the current JUCE activities we had a dicussion within our research group regarding the license issues. The current GPL license model does not allow integrating external non GPL libraries into JUCE easily. This can be a bit problematic if working with various stakeholders working under dirrerent license models. In the future we would like to see licensing switching to LGPL model which is a bit more permissive.
I'm sure I'm not alone among commercial developers in being both excited and apprehensive. Hope you're planning a NAMM meetup!
Hey Matti, thanks for posting. Do you want to elaborate on the difficulties to integrate JUCE with other libraries under the GPL license?
Hi Mikey
Yes we'll be at NAMM at the ROLI booth, and will organise a meetup in LA around that time.
Congrats Jules!! Thank you for all those lines of code - wishing you many more successful buyouts
Hi JB,
To my knowledge GPL license has a viral effect. For example if we in our project extend our main application (MIT license) with JUCE technology (GPL) then the derivative work should also be licensed under GPL.
In practice, if I release a JUCE application utilising an OSC library licenced under MIT lisence, then the resulting derivative work should be released under GPL. Therefore I would like to propose some other license model in order new modifications of the JUCE open source components to flourish and grow. Given that, GPL model restricts our work sometimes. However, some other may find it feasible.
We also aknowledge that by bying a JUCE license we are able to sublicence our binary and, thus free to redefine our license to meet our needs. So there is now problem at all : )
BR,
Matti
Not quite..
For example, say you publish a program which combines:
- Your own code (under any open-source license, GPL, BSD, LGPL etc)
- Someone else's GPL library
- Someone else's BSD/MIT/permissive library
The beauty of open-source is that the only thing you're actually publishing is your own code, plus some suggestions for how to build it. You don't need to publish/distribute the other libraries yourself, as they're publicly available - you just need to tell people that for it all to compile, they'll need to get these other libraries and use them. (You may of course distribute them yourself, as their licenses will allow that).
Technically, perhaps your users would be breaking a license when they compile and run it all, but the GPL has clauses to allow people to use the code privately so I don't even think that'd be the case.
However if you were to build the same app as closed-source, and not publish your own part of the codebase, then you would personally be violating the GPL licenses involved when you build and distribute the binary.
So IIANL, but I really think that the GPL works just fine for us, and you don't need to worry about this!
Thank you Jules for your detailed description. Then it is all good.
+1 for a meetup around NAMM. I think that all business users are interested in your future plans. Congrats to both parties by the way!
I don't understand, did this forum lose the ability to automatically quote people? Anyway...
Jules wrote:
However if you were to build the same app as closed-source, and not publish your own part of the codebase, then you would personally be violating the GPL licenses involved when you build and distribute the binary.
So IIANL, but I really think that the GPL works just fine for us, and you don't need to worry about this!
Let me be clear, I am advocating that JUCE use a "permissive license" (http://en.wikipedia.org/wiki/Permissive_free_software_licence) such as ISC or MIT. This means that someone can combine JUCE with their own code and publish only the binary without publishing their source code (a violation under the GPL). Real freedom means users can do what they want including holding back their own sources, or publishing commercial software that uses JUCE without paying for a license and without distributing the source code to the application.
Sure, but that's not what the original question was about - Matti was saying (if I understood correctly) that he thought there was a problem releasing an open-source project that mixed GPL with non-GPL sources.
Personally I'd love to be able to offer it under a permissive license, but since that would instantly destroy the business model, it's not a very feasible option right now!
And Jules: Vinnie is BACK! :-D
The Vinnster is always welcome round here!
+1 for this.
Currently nothing has changed - we may re-think things later next year, but right now it's business as usual.
I wonder what this means for the future of Projucer.. anyone remember that one? :)