How would it be possible to allay your concerns? I think we've tried to be as clear as possible with our intentions - how could we rule out such possibilities with our license agreement?
It isn’t that I don’t trust you or your intentions now, it’s that intentions (and requirements) change.
You asked about allaying fears. Personally for me this means actually take-to-the-bank licensing that I could get through a legal audit, even if hypothetical.
Talk of “secret sauce” and future closed source and IP licensing of future maybe-must-have magic... that’s way too much future risk for me.
An example of what I think is good licensing is JUCE (https://juce.com). Everything from “free” to “paid with support”, all open source… but the point is I always know exactly where I stand legally, what I can and cannot do... and what I can and cannot do in the FUTURE.
We're very keen to make sure that the end-user developers are totally unencumbered and license-free, because we want lots of people to adopt it.
All our licensing is more aimed at device and driver builders - think of it like e.g. openGL - the industry making GL cards and drivers is legal complex, but none of that stuff affects the coders writing GL apps.
Or what if want to write a Vulkan to Metal like MoltenVK?
What if I want to write an interpreter for your bitcode?
What if I want to port soul secret source on top of Apple's Accelerate framework? Would you sue me to oblivion?
And good point. I understand where you’re coming from, but... I didn’t understand it when I read the post and blurb(s).
I never want to agree to an EULA before starting to develop something outside of a professional setting. That's an immediate dealbreaker for me. But even if I did - I wouldn't be able to disassemble or reverse engineer your software (2.2)? Also - why are there so many clauses in the EULA telling me to obey really specific laws? Aren't these redundant to section 2?
- end-user developers. This is kind of like being a user of any other language, there's no EULA, nothing to sign, you just write SOUL code, test and debug it with whatever tools (which may themselves have a EULA, but probably nothing heavy)
- device and host developers: These are the people writing DAWs, plugins, hardware that can run SOUL code, audio device drivers etc. These are professionals, and licensing is a normal part of life when you're doing this kind of work.
What secret sauce is this? What parts of https://github.com/soul-lang/SOUL are closed source?
Real answer: Mainly the JIT engine, and the very complex rewriting algorithms that turn multi-threaded soul code into a form that can actually be executed.
We're certainly keen to open-source everything when possible, just been advised by our lawyers not to do that yet. C'est la vie.
