No License Specified

[atnpgo]

The repository is public which implies an intent of being open-source but no license is specified making review of the code an issue.

This might however be intended, this page contains some additional information: https://choosealicense.com/no-permission/

[wolftune]

I vote strongly for AGPL, the one license that ensures any derivatives or even instances that anyone puts up must share the relevant source code with anyone to whom they give access.

[Immortalin]

The Apache/MIT license would be better as a GPL licensed JavaScript app would completely kill adoption.

[malhotrachetan]

Yes indeed! An Apache/MIT license would be great for extension building!

[wolftune]

Why would AGPL license reduce adoption? What adoption do you mean? ("completely kill" is hyperbole)

AGPL is compatible with extension building. Apache or MIT licensed extensions are fine to use with an AGPL app.

As long as everyone retains copyright to their contributions, there's no threat of proprietization (as there can be with AGPL projects that insist on a CLA from contributors that gives permission to relicense). AGPL without CLA ensures the project will always stay fully open.

[atnpgo]

Corporate/closed-source devs will often avoid looking at AGPL source code since it is seen as an unnecessary risk by some corporate departments. A more permissive license would increase the number of people who might look at the code and therefore possibly share back fixes/improvements. AGPL will force giving back at the cost of less potential people giving back.

Ultimately, it's a trade-off and it's up to the current owner to pick what they prefer.

[wolftune]

@atnpgo your framing is pretty good, thanks. Some added nuance: there at least exist people who will be more motivated to contribute to an AGPL project (but I can't say they are many or would make the difference), and if it happens that a proprietary derivative is made, that could dampen motivation for contributing dramatically. It could also lead to some contribution back from the proprietary derivative, but that's hard to say. If no proprietary derivative or threat of one were ever in the picture, then it's indeed true that AGPL wouldn't be needed.

It's also possible to switch an MIT/Apache project to then go forward under AGPL, but that can't change the previously-licensed code.

Overall, AGPL (with no CLA) ensures openness forever. MIT/Apache has no such assurance and (perhaps for that very reason?) happens to be the dominant licensing in the JavaScript universe.

[pkalogiros]

I agree 100%. Will be adding a license today! My intent is to have this be open, if somebody wants to fork it or clone it, they are free to do so.

However, first I need to put up an attribution page and honor any 3rd party code that has gone in this (the mp3 export, the lzma-wasm compression, the wavesurfer js plugin)

[penyuan]

Thanks @pkalogiros! Looking forward to it.

For what it's worth, I strongly agree with @wolftune that the AGPL is the better choice. I know I am just speaking for myself (though I have heard other developers say this, too!), but I would be hesitant to contribute to a project licensed under MIT/Apache/BSD and the like, because I don't want my contributions to possibly end up in proprietary software.

[sedubois]

@penyuan I am in the opposite situation, I would be interested to see if this software could help us edit our meditation audio sessions, but if it were AGPL I would have to say "too bad", move on and look somewhere else, as I have no control over the fact that the software I work on is closed-source, in turn meaning that I would be barred from making any potential contributions.

In that regard and according to my limited understanding of AGPL, it appears very restrictive.

[wolftune]

@sedubois in case this is what you were thinking about: AGPL says nothing about the products made with the software. So, for example, Inkscape is GPL but that says nothing about the licensing of artwork people make with Inkscape. If you are thinking about using AudioMass to edit proprietary audio, AGPL is completely irrelevant. It only applies if you are including the software code itself in a new product (such as some other software that itself does audio editing).

I may have a separate opinion that published meditation guides ought to be freely-licensed too, but that's not the same as requiring that via a software license. I know of no such license existing, I do not support the idea, and it wouldn't be Open Source. It would probably not even work at all in terms of copyright law because your edited meditation sessions would have ZERO of the copyrighted work of AudioMass.

[aethernet]

I’m with @sedubois on this one.

I’m building music instruments (app, web and plugins), some are open source, but some are not.

I would totally use some part of AudioMass and contribute to it if it has a MIT/Apache license, but not if it had a agpl. I might still use the soft for my personal needs, but not in my dev works.

@pkalogiros awesome works btw, this is very impressive!

(Btw I’ll totally borrow your docking / floating pattern no matter the license ;)

[pkalogiros]

Ok the majority has spoken - we will going with MIT. Any objections?

[wolftune]

@pkalogiros we can see indeed. It's always possible to relicense with AGPL after starting with MIT, though that can be more controversial. I hope people will both contribute and also not make proprietary derivatives. You can always express in a request (non-license) way that people please consider using a free/libre/open license for derivative works.

I do note that in the above comments supporting MIT there are at least two erroneous misunderstandings: (A) that the license would affect the audio files made with the software (it does not) and (B) that adoption of the software directly by users would be reduced with AGPL (there's no basis for that idea). But there are indeed some other perspectives that are just differences of opinion and value rather than being factually questionable.

[pkalogiros]

@wolftune Thanks for taking the time to explain this to me.

I scrolled up and read all the comments again.

The way I see it, is that MIT license might alienate people who want to contribute because their code might end up in proprietary closed applications. Even if they personally may not mind, they might be bound by employment contracts that prevents them to contribute to MIT licensed projects. They will however be able to use it themselves, and feel free to use pieces, or just be inspired in their own projects. (contribution may suffer, adoption is fine)

Now, a GPL based license ensures that the code and any modifications must be open source. The catch here is that people who want to adopt this as an editor, or use certain parts of it (eg some FX logic) in their software - might be scared away because they will need to open source all their contributions. Which likewise, might not be allowed to be used by their employer, or they might simply not feel comfortable enough to showcase their work for a variety of reasons. (contribution is fine, adoption may suffer).

I want to believe that there is good in people, and most people find joy in giving back to the community. That even if they take pieces and and build something closed on their own on top - they will come back and contribute in some way if they have the ability. So... I tend to think that users/devs may become contributors.

I am also not sure how big the delta of contributors would be, if we opt for AGPL. I am unsure how the project is going to evolve from a community stand point X months from now. Right now I have only received small (but important) one liner fixes, and miscellaneous things like a typo or a better read me, but nothing really to point that this could become a thriving project of its own. If I remain the prime driver, does it really matter?

So, I am really leaning towards MIT.

---

But.... there is a problem. Audiomass as it stands is a product, not a library.
It is more similar to VLC (GPL), Audacity (GPL), LibreOffice (MPL 2.0), Notepad++ (GPL), CKEditor (GPL) etc etc, than let's say tone.js or threejs.

The version that is hosted on audiomass.co has no ads, no trackers, it is not firing any requests to 3rd parties, and uses no cookies. After it loads html/css/js it is never communicating with the server again, with the exception of fetching the mp3/wav encoders as web-workers during export.
I can only compute visitors by running awk '/10.Jul.2020/ {print $1}' < /var/log/nginx/audiomass-access.log | sort | uniq | wc -l
And funny enough, when it got first featured and blew in popularity I had access logs off. Still, I am deleting logs older than a week, because I do not want to hold lists of the IPs of visitors. I am not in the business of data collection.

I only want to provide to people a useful tool, that comes with no strings attached, I hope we can all get behind that. And I tend to have a similar opinions about its source code, but...

.

What happens if somebody makes an identical fork - puts it on a page full of ads, trackers, "Know your location" alerts. And then throw ads on social media, or make a marketing push to draw attention to that terrible version?
Basically a 1-1 clone of the finished product, used to trick/track/exploit users or make profit while being identical to the original, is not ok.

A 1-1 clone used as an editing tool in a bigger project (say a podcast platform using it as an editor, or a music making platform using it as an editor) would be perfectly fine by my standards.

A standalone editor that has different features, or extends it in some useful ways would also be fine by my standards.

I understand the above sounds convoluted, or even naive. Basically... I am happy if audiomass is integrated in a product, rather than itself being the product if that makes sense. Bah, maybe I am getting this wrong. So in theory I am perfectly fine with MIT, as long as it is not just taking it as is and trying to sell it.

Another thing I am thinking, is that we can go for MIT, but create an extendable plugin system, where audio filters can be injected without required to be heavily coupled with the core. Each plugin could have its own license. For example - if you want to add BG noise cancellation but to not allow the code to be used for profit, that plugin can use (CC-BY-NC-ND) or similar, and it could be injected as a git module to be easily deactivated for compliance.

Opinions?

[wolftune]

@pkalogiros those are well-thought out points. At some deep level, the practical gets into what might even happen in the case of license violation. Truly malicious bad actors will ignore the legal requirements, but most people and companies will respect a license without needing to go all the way to taking legal action against violations.

With MIT, someone can totally put up a copy where they add all sorts of bad stuff like you say, and they don't need to reveal what their instance is doing, it can be a proprietary fork. With AGPL, they could still do some bad stuff if they keep it separate from the actual software. But they'd be required to reveal the code of whatever they are doing.

In practice, a really malicious entity won't be swayed by the license. But proprietary companies with normal legal status as entities, those are the ones who might end up wanting to make a fork while keeping things proprietary. However, if their business model is about ads, they could go ahead and release the full ad-based code as free software completely and still use it. AGPL doesn't block that, but it makes it harder for them to pretend that the only option is to use their version as-is.

AGPL doesn't block selling either. People could take it as is and put it behind a paywall. But AGPL has stronger requirements that they reveal the license. So, for example, sleazy but legal folks sell CD-ROMs with LibreOffice on it on eBay and call the item stuff like "great full word-processing, as good as Microsoft" and avoid saying LibreOffice and have just small text saying that the software is GPL etc (which most people don't know what that means). People get LibreOffice at the end of the day, but they are funding this stuff instead of the LibreOffice developers. That's unethical but legal.

In general, CC licenses are not written to be used for software code and shouldn't be suggested for that. Executable programs have their own different issues, warranty disclaimers etc.

Having said all that, the meta reason for AGPL is like a political statement in support of software freedom. But it's not worth it just to stop malicious actors. It probably makes more sense to focus on how you feel about a company making a noticeably improved version with some real feature or bug-fix improvements and never freeing that code for anyone else in order to do something like get people to use their site with paywalls and/or ads or as part of some larger paywall or ad-based service that this is just part of.

As I said earlier, you could start with MIT and maybe there's never any issues, and if you feel people are using the code in a way you don't like, you could switch to AGPL in order to keep all updates from then on unavailable to the forks that don't want to accept the AGPL terms.

I'm personally in the camp of wanting to see more AGPL stuff because I care more about stopping paywalls and ads and other anti-social things. But I do think it's a tactical decision case-by-case. There's something to be said for compatibility with the licenses of an ecosystem.

One last point is the signalling: if you make a believable commitment to keeping this free software on your end, that's something too. AGPL is a strong signal that you are removing your own capacity to take everyone's contributions and turn the project proprietary for your own ends. With MIT, a community project built over years can see the primary owners suddenly take the work in a proprietary direction and the only out the community has is to fork it separately if there's enough community to keep that going. Dan Ariely says, "it's easier to avoid temptation than to resist it". So, I like the idea of essentially saying, "I want this to be free software, so I'm locking it in as free software and throwing away the key so not even I can switch this to being proprietary", but that only works if there are multiple contributors all under AGPL. As long as you remain the dominant developer, it's all under your copyright anyway (though with AGPL you could go all the way to making it a GNU project and giving the copyright to the FSF, but that's a much deeper issue). You can also just make social commitments without using the license. You can emphasize no-paywalls and no-ads and why you care about that and still be MIT.

Sorry for the length, hope this is helpful and edifying. All in all, I care more about people understanding the value of software freedom and not misunderstanding these topics than I care about whether this particular software ends up AGPL or MIT.

[sedubois]

In case this is what you were thinking about: AGPL says nothing about the products made with the software

That is not what I was thinking about. If I need an editor to produce audio I can continue using my current one. I rather want to see if a tool like audiomass could help enhance our workflows by embedding it in our own web application and tuning it to our specific needs. That is a prerequisite to any possibility of contributing back.

I care more about people understanding the value of software freedom

I very much care about freedom, in software and otherwise. I my specific circumstances, that argument goes in favor of the MIT license.

I want to believe that there is good in people

This sums it up for me. Even though there are bad actors and I have no way to know their proportion, I believe more in an approach where people want to give back because it is in everyone's interest, rather than because they are forced to do so by a license (which in circumstances such as mine would actually lead to the opposite).

[wolftune]

give back because it is in everyone's interest, rather than because they are forced to do so by a license

Just want to be clear that this is a common misunderstanding of the GNU licenses and copyleft generally. Not a single one of these licenses requires giving back. They are not upstream licenses. They are downstream. They require that freedoms be passed on downstream for anyone who conveys the software to someone else. That is their behavior and their intention. Just like with MIT, contributing back upstream remains purely voluntary.

[trebmuh]

Hi there, is there a final decision on which licence is to be used?

[fpesari]

Hello,

the authors should not be forced to release their programs as FLOSS. However AudioMass claims to be "open source" in its about page and in its keywords, which are indexed by search engines. Since the only software which can call itself "open source" is software with a license conform to the Open Source Definition - in other words, released under a license approved by the Open Source Initiative, I ask that at the very least, if you don't want to adopt a libre license, you remove the references to "open source". This for the sake of truth, you are free to do whatever you want with your own code. Thank you 😄

[wolftune]

The discussion above made it clear that the author is happy to follow through on licensing, it seems it just hasn't happened yet.

I should emphasize that despite my own preference for AGPL, I think MIT is a fine enough license, and if the decision is to go with that, it's fine. I just wanted to disabuse people of the incorrect ideas some people brought up when discussing the significance of various licenses. That was not meant to be a strong argument against MIT.

[fpesari]

The discussion above made it clear that the author is happy to follow through on licensing, it seems it just hasn't happened yet.

I should emphasize that despite my own preference for AGPL, I think MIT is a fine enough license, and if the decision is to go with that, it's fine. I just wanted to disabuse people of the incorrect ideas some people brought up when discussing the significance of various licenses. That was not meant to be a strong argument against MIT.

I think the AGPLv3+ gives the most protection to both the author and all users. It's the best choice both for monetizing AudioMass (as the author can make sure nobody runs their own version without giving anything back) and for keeping it gratis.

The MIT license is great for things which are meant to be used by proprietary programs, else it's just a way to have someone take your project, lock it behind a server and give nothing back. I think the whole SSPL fiasco is, at its core, a reaction to what happened to a lot of permissively licensed code.

[Pythone]

Hello,

the authors should not be forced to release their programs as FLOSS. However AudioMass claims to be "open source" in its about page and in its keywords, which are indexed by search engines. Since the only software which can call itself "open source" is software with a license conform to the Open Source Definition - in other words, released under a license approved by the Open Source Initiative, I ask that at the very least, if you don't want to adopt a libre license, you remove the references to "open source". This for the sake of truth, you are free to do whatever you want with your own code. Thank you smile

I think he just did not care to put a license

[Pythone]

https://invidious.snopyta.org/watch?v=ySZBK0r4iuI

[TrueWill]

Just a +1 for adding a license. If you want to restrict commercial use, go with GPL or the more restrictive AGPL. If you don't, MIT is a popular choice. The licenses on your dependencies could dictate what licenses you can use, though.

Usual caveat: I'm not a lawyer.

[ash9002]

Hi all, any decision on the licence? I appreciate the complexities noted in the discussion above but just wondered if there's any update.

[odashi]

Hi all, thanks for creating this great tool.

Although I understand the backgrounds discussed on this issue, I'm really looking forward to seeing some licenses of this tool. This is currently the main blocker of applying AudioMass to my work, and some folks who are watching this issue may share the same problem.

Licensing is required for not only publicness of development, but also putting the statement of no warranty. Without well-written licenses we can't conclude who is actually responsible for defects caused by using the tool, and it may lead complicated (possibly legal) issues.

Well known licenses (MIT, (A)GPL, and any other FOSS licenses) have been reviewed for this topic for a long time, and applying something would be useful to protect the authors themselves.

[suterma]

Regarding

What happens if somebody makes an identical fork - puts it on a page full of ads, trackers,

Exactly this fear led me to the decision to licence my own "product", also a media player (https://replayer.app), with AGPL. It will at least legally force the bad actor to open-source their malicious stuff.

For libraries, I tend to go with MIT however, to allow for arbitrary use. I even have created 4 MIT-licensed libraries/packages by now, that I use for my own in said "product".