Open source & money: a complicated topic

what are models for funding the development of software, while still reserving user’s right to edit the software (or part of the software), and/or reserving the right to use open source software made by others ? what works and what doesn’t ? what’s legal/illegal ~ ethical/unethical ?

plz share examples/experiences/thoughts/opinions!

ay

dreaming up some future projects here & I’m thinking about ways to join up open source DSP with proprietary DSP. cuz some people are able/prefer to open up what they work on, and other folks need/prefer an income for their work.

esp with JACK and OSC handy it seems like there are plenty of options for tunneling data between multiple binaries without mixing code but for GPL stuff it’s kinda taking advantage of a weird/vague line in GPL (i wanna use supercollider (which is GPL))

A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
“aggregate” if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation’s users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.

so does audio/UDP/stdin communication make them one work, or are they separate ? what if I want to package the binaries together so users don’t need to do 7 installs, would that make it a “larger application” ? maybe they still run when you take away the GPL files, but what if some parts of it don’t work properly ? does that make non-GPL code an “extension by nature” ?

not sure if I really need to worry about going to court over an edge case like this but I don’t want to feel like I’m stepping on the toes of folks who have put a lot of hard work into free tools. curious what the vibe is out there.

anyways an example of GPL3 “aggregate” would be like a linux distribution that includes some nonfree components and some free components. (e.g. Red Hat Enterprise.) the GPL parts don’t infect the other parts. the parts do not interact. the clause is there mainly for distribution and not development.

so yes, you can package supercollider and your thing in an installer together without issue - this is exactly what a “mere aggregate” does.

[ed] simply put, in general if you’re not compiling or linking their source then your project can be made compliant.

but my personal, non-legal take is that it’s unethical or at least obnoxious, to monetize your closed-source project that relies on OSS to do any heavy lifting for its functionality (whether there is a legal loophole for this or not) - without the blessing of the rights holder. in the case of supercollider, a volunteer project, this feels unlikely.

if you want more detailed and sound information on this, the lines forum might not be my first port of call. i’d try:
https://copyleft.org/guide/comprehensive-gpl-guidech10.html
https://lists.debian.org/debian-legal/2000/03/msg00122.html

etc.

9 Likes

To way simplify this as far as I understand it, to comply with GPL, you need to be able to provide the source code for the GPL’d packages that your project uses. If you edit these packages, you need to provide the source code for your edits (that is the “copyleft protection”). If they are intimately entertwined with the code you write, your project is effectively beholden to GPL to, and you need to release source code for the whole thing.

This is not legal advice and I am not a lawyer, but If you practice solid package management and are getting all the GPL’d pieces from RPMs, or NPM modules, and your installer grabs them as such, if it is something like a container image, I think that would follow the license. If you were to need to actively fix some bug or something in a particular GPL library, you would need to fork and put that library up in a repo somewhere, with the GPL license, and grab it like your other packages. Of course trying to contribute that fix back to the upstream package would be ideal.


Probably the best way to be able to have a “proprietary additions” type feature in your app would be to open the entire core of your app (GPL if you don’t want people to try to fork and sell it, MIT/BSD if you don’t care about that), and then have a third party store. VCV Rack is a great example of this architecture.

4 Likes

OSS software developers do get paid for their work. Some get paid quite well. For example, on the macro scale, the Mozilla Foundation (a California non-profit) in 2016 received $520,667 in revenue and spent $225,942 on “software development”.

If you wanna make money developing and distributing software, that’s rad! You don’t need to frame it as “the poor, tired and hungry OSS dev versus the humble middle class proprietary dev”.

Regarding the distribution law stuff, having been a technology expert working with lawyers auditing code for OSS compatible licenses, I wouldn’t worry much about distribution license until you actually have a proof-of-concept and a means to distribute your work. To supplement what Ezra said, until you get lawyers and accountants involved it’s more a matter of community involvement versus invoking the correct incantation to configure your application so it fits within some OSS license.

5 Likes

so I assumed this wouldn’t be possible bc:

  • either the open source core would reveal a backdoor to your payment system and/or users could freely share the paid binaries

  • the inclusion of proprietary plugins would violate GPL, since the plugin code is definitely not separate or independent

but I see that VCV rack is GPL licensed and it’s doing this. I can’t really tell how that’s happening - might need to buy something to find out.

on the ethical side of life, I like this (OSS core <- OSS DSP <- proprietary DSP) better than what I was thinking of earlier (OSS DSP -> proprietary core <- proprietary DSP), but it seems trickier from a legal standpoint.

I suppose VCV has the safety net in that none of their linked libraries are GPL (I think). so they aren’t going to sue themselves.

I am also rlly thinking about donationware stuff as a way to avoid all of this (idk if that works). or just building everything myself (which seems limiting).

feel free to move the convo too. lil more about general open source monetization stuff at this point

(OSS user, not programmer here).
an example of open source / proprietary software mix is Harrison’s DAW, Mixbus. Basically it is Ardour (open source DAW) with proprietary DSP integrated in channel strips/busses.
I’m not versed into the details, but GPL compliance seems pretty straightforward in their case (ie all source code is available, except the proprietary DSP which is a plugin), but perhaps there is an agreement between parties on top of that.

Or maybe just use a framework that allows closed source distribution of the compiled code (JUCE + Faust ?).

1 Like

mixbus is an interesting example,

i wish i knew more specifics, but superficially it seems like a) they have financed Ardour development to some extent, b) they might have a seperate license agreement since i can’t find any source disclosure.

some takeaways from that are that, 1) like Laz sez, relationships are key, 2) just because projects use same license doesn’t imply they have same philosophy.

IOW, “OSS” is a big category with many attitudes, it does not mean “anti-money” and i didn’t mean to imply otherwise. i’m one of those who prefers to look for ways to monetize without closed source. but it’s a complicated topic.

1 Like

Some Harrison employees develop new features for Ardour. Seems like a pretty sweet deal, get a salary at a cool pro audio company and attribution credits for the premier open source DAW in the world!

I pay (I think it’s like ~ $100 a year) for an annual subscription to Ardour, which brings in ~ $9500 a month to the company, shown on the side bar of the project’s forum. It’s clever for that fee, one gets access to builds for macOS. Despite having the necessary skills to build source code on macOS, I really don’t care to do that and it’s worth the money to download an installer.

I’m not sure how the partnership between Harrison and Ardour works for distribution of each version. I’d imagine Mixbus works with the fancy Harrison physical consoles?

2 Likes

for a lil bit of context this was a nice article to read a while back && kinda made me realize that I personally am probably in a different position than other folks in the open source audio world

There are many reasons why a person would not want to be paid for their open source work. They may already have a full-time job that they love, which enables them to contribute to open source in their spare time. They enjoy thinking of open source as a hobby or creative escape and don’t want to feel financially obligated to work on their projects. They get other benefits from contributing to open source, such as building their reputation or portfolio, learning a new skill, or feeling closer to a community.

For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month.

that second bit resonates pretty strong for me. I have to really limit my ambitions for projects & I wish I didn’t have to!

I want to share as much as I can, I want to be ambitious, I want to build off of proven foundational techniques and practices, but I need a way to reliably fund the time that I dedicate and I do not want to infringe upon the rights of others (via tricky partial-open-source models discussed above)

2 Likes

One thing I often think about is, I work for a small but somewhat profitable company that ship an IoT device and sell subscription-based access to a management interface and extra features for said device. There’s obviously some internally developed software on the device that’s not free software, but the device itself runs Linux and the entire software stack for the management interface is your standard open source web stack.

Internal tooling for the development team is all open source, and we’ve even talked about moving company-wide internal comms from Slack to Mattermost because we like to self-host. There’s a couple of internally-developed packages that have been put on Github under free licenses, and we are certainly encouraged to contribute fixes to projects we depend on where needed. We don’t make an open source product but it’s fair to say we’re an “open source-friendly” company.

Yet, to the best of my knowledge, we have never so much as considered donating so much as a single cent to any of these projects. We happily pay for Slack and other pieces of commercial software that support our business, but the product would quite simply not exist without a very, very big pile of open source code. And we don’t pay for it because it is not required.

I think this is the mindset that needs to change. Whether or not proprietary software is immoral to you is one thing, but you can’t argue that for things like libraries, servers, etc. it is intensely impractical compared to free/open source software. So we use stuff with no requirements to pay… but why does that mean that we feel like we don’t have to? It seems like a culture from a different time, that you only pay those who provide you with a service if they twist your arm to do so.

5 Likes

I’ve heard of this option before but I’ve never seen an example of it - Ardour has a really smart and honest approach

https://community.ardour.org/download_form

the issue is that in addition to building from source it’s also perfectly legal to distribute that compiled binaries. sure enough, I did find one but it’s on a sketchy website & I can realistically worry about it being malware or something. It may not be a super different situation than trying to get a cracked ableton.

there’s a video on how to build for free as well but it seems like it’s made in pretty good faith to the original devs

stuff 2 think abt

These are two different things. It sounds like you’re implying that because it’s possible to build Ardour from source on every platform this means the distribution model of charging for builds would not generate revenue because everyone is just going to this youtube video or warez site. Though the published numbers on the Ardour website (which we have to assume are true and in good faith) inform us that the company is generating ~ $114,000 a year from this economic model. That’s near the average annual salary for a senior software developer role in the bay area of California. wink wink it’s a market for talent if you’re looking…

I do not think this model would exclusively support the finances of a project as complicated and valuable as Ardour and it doesn’t. Ardour has multiple revenue sources and a wide community. This includes private support in the form of labor paid for by companies like Harris and SAE Institute.

Public grants would be cool too but I doin’t think a DAW in 2019 is exactly the kind of “tech for good, blah blah blah” where the funders are looking to park their money.

2 Likes

fwiw, I have an ardour license and I don’t even need / use it

So just a few thoughts to help along here. And this is not legal advice etc… but just some thoughts from me on a Saturday.

First: There’s lots of gpls not just one. The two big ones: Lgpl2 is a library gpl. If you modify the source to the lib you need to redistribute it but if you link the lib your code is fine. Gpl3 is the more recent gpl. It has the feature of being “viral”’or “contagious”; if you link gpl3 software in an application you distribute that application has to be gpl3 (or at least needs to make its source available - there’s a debate about whether it has to be gpl3 or just open source).

This means most companies can’t use gpl3 software. It also means if you write, say, a kick ass analog filter library that is gpl3, a software vendor can’t put it in their closed source synth.

Gpl3 is great for things like surge (a synth i work on) since it means if someone does take the source and modify it and sell it, they have to give that modified source away. If someone did that, I could then take their mods and put them in the free surge. So defacto the software is free forever and not integratable into closed source projects. Which was the intent.

So what has rack done? Well Andrew describes it well over in the rack community but short version is: he is the sole author of rack core so he distributes it under a dual license. You can get rack as gpl3 - which means if you make a derived work (a module) your work must be gpl3 (or maybe another open source license - like I said folks disagree on this). But since he is the Sole author and holds copyright, he can also license a separate (but identical) copy under a non gpl3 license to folks who want to make or sell closed source extensions. This is the same model Steinberg has used with vst3sdk. You can get it gpl3 and be opensource or you can cut a deal with Andrew (rack) or Steinberg (vst3sdk).

For avoidance of doubt I think this is a cool and clever model for music software!

Well run organizations which want to do a multi license model will either not take third part contributions (which is the rack model) or ask contributors to sign an agreement assigning copyright to the owning entity. That way the entity can continue to sell the software because the ownership of copyright is unambiguous,

In surge we take contributions broadly and have individual authors hold their copyright so it will basically be gpl3 forever. If we wanted to ungpl it every author would have to consent or someone would have to remove all the non-consenting authors contributions. Never gonna happen.

Compare this with mit or bsd licenses which are super open. If someone uses your code they don’t have to be open source at all. Apache2 is also very corporate friendly and a bit tighter than mit and bsd.

So if you want to write Open source software and make money you have to think about contributor management, multi licensing, and ownership as well as core license.

For music software specifically - where the end user wants the product but components can be intermixed - you probably want to avoid mit or bsd if you want to be paid and lean towards something more like gpl3 and an alternate license with clean copyright. That way the only person who can make a closed source version is the copyright holder and a person who uses your code would get contaged by gpl3.

Some foss folk will call this approach “weaponized gpl” and mean that in a pejorative sense. But i think it’s a smart model for a field as wierd as music sw.

Hope that helps!

5 Likes

Thanks for explaining all that, learned a lot from your post!

Also @andrew I think this answers the questions in your earlier comment on what I shared a lot better than I could hah

2 Likes

suuuuper great info thank u. for their position that model makes a lot of sense. does this mean VCV can’t link to or incorporate GPL libraries ? It doesn’t look like it does right now.


also, I’d looooove to hear @neauoire’s thoughts on community & the patreon/PWYW model (since it seems like it’s working out)

That is correct rack core cannot link to gpl3 libraries and does not. At runtime it can load binaries built with gpl code (which is why the surge rack modules can exist) but from rack core down needs to be either owned by rack or a non viral license like mit bsd Apache or lgpl

1 Like