Julia's business model

Science always followed this model. The value of the people and added knowledge far exceeds earnings of the scientists. From an academic point of view FOSS is another piece of knowledge that is being produced, which happens to be associated with a product (the code).

3 Likes

The basic concept in economics is “public goods” examples include the census data and environmental cleanup. Software, all of it, is a public good. Copyright and patent law try to shoehorn it into nonpublic category, but it’s a mistake.

Slightly-off-topic Diversion: Definition of a “public good” is one that is non-excludable and non-rivalrous… meaning, you can’t keep people from using it without paying (non-excludable), and when they use it there isn’t “less of it” for the rest of us (non-rivalrous). When you make a copy of a program, it just means there’s more copies of programs, so you don’t “take away” anything from the other potential users, therefore software is non-rivalrous (unlike say fish or trees or mineral deposits). The non-excludable part is basically that anyone could give you a copy of a program by simply making a copy, the only way to “exclude” non-paying people from using it, is quite frankly Gestapo type techniques: raiding people and inspecting to see if they have “illicit” copies. So in a just world we don’t have software Gestapo and software is non-excludable.

In fact, software is just one form of “information” and information in general is a public good (like Census or Bureau of Labor Statistics data), you can make perfect copies for essentially nothing (using computers) and you can’t keep people from using it without “thought police”.

Copyright “worked” in a world where making a copy of a book required a printing press, enormous quantities of paper, and a lot of typesetter’s time. Few people could do it, using up the paper and machinery made it rivalrous (printing one book meant you couldn’t at the same time have printed some other book) and you could keep people from making “illicit copies” by simply fining the few people who had printing capacity, you didn’t need a general purpose “thought Gestapo”. Things don’t work that way anymore.

That being said, when people can get money to do a thing, more people will spend more time doing that thing, so if it is possible for companies and universities to pay people to develop Julia, we will get more and quicker Julia development. Paying for support is a viable model for people such as the original poster, who said:

I understand the concern. It seems to me that paying for the development of features or support for your graduate students to take classes or for bug bounties etc is all viable usage of research funds, and WILL contribute to faster development of a better Julia ecosystem.

10 Likes

Coming from Matlab, the idea that a software can be successful without a commercial licensing model may be difficult to grasp. However, as somebody on here already pointed out, most programming languages are already FOSS.

There is also quite a lot of advanced software that is used widely in academia that is FOSS and offers a paid support tier (which JuliaComputing offers as well). An example would be OpenFOAM, where you can pay for development support.

A support contract can usually be paid from research funding, and it will provide valuable input into a research project, through support by the developers, that will help building the features you need for your project (rather than simply shelling out for the license).

Sometimes the concept of FOSS is misunderstood and people cannot accept that there is any money involved. But many successful projects do have a way to buy support, which in turn is a win-win, since you also support the project, as it can be the main stream of income for the project.

I believe JuliaComputing is operating on that model (aside from MIT and research grant funding):

  • a free FOSS license
  • paid support
  • a paid for “professional” product, which includes, e.g., a GUI for ModellingToolkit (JuliaSim) - to be released soon, IIUC.

So I’d check with JuliaComputing for a support contract, and then factor that into my research proposal cost*

EDIT: some “clever” pencil pusher in university admin may come up with the usual: “… but the software is free, so we cannot possibly pay for it …”. So you may have to fight for it*.

**EDIT: It helps to use the word “support license”, rather than “support contract”.

3 Likes

Only tangentially related to the question, but this blog post by Paul Romer constrasting Mathematica and the Jupyter notebook (which by extension includes Julia) is a good read on the subject of proprietary vs. open source.

4 Likes

That’s a really interesting piece altough this part struck me as a bit odd:

Which reminds me. If you are a Julia enthusiast, how do you suppose the investors* in this new language plan to make their big score?
*(Edit Sept. 2021: Removed the link to the Cruchbase entry for Julia Computing because it uses an opaque “data” url.)

2 Likes

I think he’s confusing Julia Computing with Julia the language. Here’s is an archived version that has the link:

Wholly agree that Romer’s swipe at Julia is unwarranted, but aside from that he makes some good points. It is absolutely vital that the computational tools that are used for science and analysis of scientific data be free and available for inspection and reproduction. That is one of the main reasons we created Julia—Matlab was previously the best tool for many kinds of numerical work and it really doesn’t seem right that someone needs to spend thousands of dollars on software in order to even try to reproduce a scientific result. Matlab also has extremely limited support for reproducibility: it regularly makes breaking changes and reproducing results done in Matlab leaves you at the mercy of whether MathWorks continues to allow downloading old versions (or some person you know might still have a an old copy of Matlab lying around somewhere). And perhaps most saliently: if you can’t inspect all the code, do you really understand how a result was produced?

Regarding Romer’s swipe at Julia:

Which reminds me. If you are a Julia enthusiast, how do you suppose the investors in this new language plan to make their big score?

I’m really not sure where his fear, uncertainty and doubt regarding Julia come from, but these are some facts about Julia’s freeness:

  • We gave Julia the most liberal, permissive license we could—the MIT license. It only requires that if you publish something that contains a substantial portion of Julia, you release it under the same license terms as Julia itself. That’s it. Otherwise you can use and modify it as you see fit.

  • Unlike many open source projects, we do not require a contributor license agreement (CLA). That means that individual contributors still own the copyright to what they contribute to the project. That in turn means that we cannot change the license to Julia without getting the express permission of the 1000+ contributors to the language. That’s obviously not going to happen, so Julia is guaranteed to be MIT-licensed forever—we cannot one day wake up and decide that we want to change the license to something restrictive. We also cannot use an open-core model where we relicense an enhanced version of Julia with a commercial license that we charge for (note the section on CLAs in the wikipedia page). If we were to distribute an enhanced Julia+, it would contain a “substantial portion” of the MIT-licensed Julia, and unless it’s also available under MIT license terms, we’d be violating the copyright of all those 1000+ contributors.

We made these choices intentionally to make sure that Julia is and remains as free as possible.

Regarding how Julia Computing (which is not the Julia project) makes money, it’s not a mystery—there’s a products tab at the top of the company’s website:

  1. We sell support in the form of the JuliaSure product that I’ve already linked to. If you have a Julia problem, no matter what it is, we can fix it.

  2. We also offer a cloud computing environment on JuliaHub that caters specifically to Julia users and let’s you easily spin up Julia on a high-core cloud VM (up to 96 cores with 768GB RAM), or a beefy GPU machine (NVIDIA Tesla V100), or clusters thereof. Yes, you can do this yourself on AWS, Azure, GCP, etc. but configuring these things to work well is a lot less trivial than it might seem, especially if you want a well-tuned cluster and Julia configured to use it properly. JuliaHub also offers VS Code as a cloud-based IDE, which lets you edit and run your code directly on the VM you’ve spun up. If you need Julia running on a bunch of GPU machines to train an ML model quickly, using JuliaHub is one of the fastest, easiest ways to do it.

  3. JuliaHub has other features that can be essential inside of organizations. Each business gets a company.juliahub.com end-point that is authenticated and integrates with their SSO. This end-point is a private package server which supports private package registries, and lets you search both open source and private packages (docs and code) in one place, just like you can search and register open source packages on juliahub.com.

  4. The JuliaHub platform also offers next-generation simulation products like Pumas for pharmacological simulation (Pumas AI is a separate company that we partner closely with) and JuliaSim for many other kinds of advanced simulations. In the future, we’ll be rolling out more industry-specific products that run on top of the JuliaHub computational platform and we’ll be opening up (paid) access to these applications on the individual juliahub.com tier as well.

  5. This is a platform feature rather than a product, but JuliaHub offers unparalleled support for reproducibility and verifiability of results. This can be crucial for customers in regulated industries like pharma, finance, and engineering. Let’s say you run pharma simulations on JuliaHub and the FDA wants to know how you got the results you did. We’ve got you covered. We leverage and extend Julia’s excellent built-in reproducibility story by recording for each job: the exact user code that was run, the Julia version that was used, the package manifest with the exact versions of dependencies (both Julia and binary), the VM image that the job was run in, and (this is work in progress) immutable snapshots of input and output data sets. So we know exactly how you got the result you did and you can reproduce those results easily and forever.

What isn’t and never will be part of Julia Computing’s business model is trying to make people pay for using the Julia language. There will never be a better version of Julia that is only available to paying customers. (If you’re a skeptic, the MIT license and lack of CLA legally guarantee this.) Many of the packages that are used to build JuliaHub, Pumas and JuliaSim are even open source. The value-adds that make customers willing (happy even) to pay are:

  • Putting it all together into a smooth, scalable, well-tuned cloud platform
  • Cloud security features, certifications and guarantees
  • Industry-specific complete solutions with well designed workflows
  • Support for regulatory requirements in various industries.

Finding a healthy business model that builds on an open source project is hard but not impossible.

55 Likes

No you wouldn’t. The MIT license is not a copyleft.

All the Julia contributors have explicitly given permission for anyone to make and distribute a derived work, like a hypothetical “Julia+”, in which the new portions have additional restrictions (e.g. they are proprietary “closed source” commercial software). Nor is there any requirement to make the modified “Julia+” source code available (whether to customers of the binaries or to the original authors).

This is the whole point of the difference between copyleft licenses like GPL and non-copyleft licenses like MIT and BSD in the free/open-source software world.

(This is not a criticism of Julia’s licensing! In Julia’s case, I think it was the right choice to use a non-copyleft license, in order to minimize barriers to adoption, and the likelihood of a proprietary modified version becoming prevalent seems low based on the experiences of other free/open-source languages.)

11 Likes

That’s true—the source code doesn’t have to be available, but if you do make the source code available, you have to include the MIT license with that, so you can’t publish the code under more restrictive terms (well, you can, but the MIT terms also apply, so people can just ignore the restrictive terms and choose the MIT license). Even if we distributed a hypothetical Julia+ without source code, my reading of the MIT license is that we would still have to include the MIT license with it, which means that those terms would apply to Julia+, so someone could decompile the code and modify it. Perhaps I’m reading that wrong—I guess the question is what the MIT license that you’re required to include applies to. GPL is explicitly very expansive; MIT presumably only applies to actual modifications to the MIT code and definitely can’t be applied to linked libraries, but that still seems to me like it would probably apply to any enhanced version of Julia. In any case, we’re not going to do that, whether we could get away with it legally or not.

1 Like

The full MIT license text is pretty straightforward:

https://opensource.org/licenses/MIT

It says basically that whatever is derived from the licensed work, if you do release it, it has to be MIT licensed. So yes, you could release binaries, but anyone who received one could do basically whatever they want with it. If you try to sell the binaries themselves, anyone who received one could immediately offer it for “free download” for example. Also yes anyone could suck out bits of it and link it to something else as a binary even if they didn’t have the source, etc.

2 Likes

That only applies to the original code. The new additions could impose additional restrictions.

Proprietary forks of non-copyleft code are commonplace, from Nvidia’s LLVM fork, to numerous proprietary BSD forks, to (in olden days) forks of the X11 system that was the origin of the MIT license. I think you are doing a disservice by making it seem like this is not possible for Julia.

7 Likes

That’s my reading as well. So it’s not as hardcore as the GPL in this regard but still undermines attempting an open core model (without a CLA).

The work needs to be “derived” though. So for example if you had a binary only package of functions added in to Julia, you might argue that’s by itself not derived from Julia, and could be distributed under another license. So you could have Julia+ which is Julia + some libraries linked with Julia and the libraries wouldn’t be derived and hence could be licensed in a different way. I’m not an expert here though.

1 Like

No, because you can sell a proprietary fork in which the new additions are not MIT licensed.

This is not hypothetical! It’s actually happened many times.

It’s totally fine to prefer non-copyleft licenses; I often use them myself. But they don’t provide copyleft protection against proprietary forks; you need to be aware of this when you use them.

7 Likes

Ok, thanks for clarifying this. In any case, the legalese is besides the point: selling a proprietary fork of Julia is not the Julia Computing business model.

3 Likes

“The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.”

So if you take Julia + add your own non-MIT licensed stuff, but you are distributing “a substantial portion of the Software” you must include the MIT license.

Including the license for the code you copied doesn’t mean that your own code can’t have a different license though.

4 Likes

Yes. But it only applies to the old code. Nothing in the license prevents you from adding restrictions to the new code in your fork.

Again, this is not hypothetical. It’s the whole reason why copyleft licenses exist.

7 Likes

Has it actually been argued successfully in court? My reading on it is if you wanted to do this you’d be best to distribute Julia + as a separate binary your stuff… Because otherwise the agglomerated thing would be “a substantial portion” of the software and require the MIT license as a whole. Only by making a clear delineation would you be in a low legal risk scenario. But again, not an expert.

Clearly, if you distribute your own code as a separate block of stuff… you can do whatever you want. It’s when the whole includes your parts that it seems questionable / risky to give any specific reading on it (unless there have been court cases specifically ruling on this issue, which there might very well be)

Many, many companies have distributed proprietary forks of BSD/MIT-like code, or incorporated such code into other proprietary projects. As far as I know, no one has ever even tried to force the release of these forks under an open-source license—that’s only been done for the GPL and similar copyleft licenses (and for a long time there were people raising doubts that the GPL was enforceable, but that’s seems pretty settled now).

There are tons of books and articles on this stuff, many written by legal experts or people (e.g. Bruce Perens) who have consulted closely with legal counsel. Copyleft vs. non-copyleft has a long history, and what you’re claiming flies in the face of that.

The MIT license is great! But claiming it prevents proprietary forks is pure misinformation. If you want to prohibit proprietary forks, you need a copyleft license.

14 Likes