[karmakaze]

The problem isn't really here. The problem is that everyone wants a permissive abusable license when AGPL would be just fine. If everyone here complaining just used AGPL then we wouldn't have this Amazon situation.

People want to have their cake and eat it too. They started with an MIT license because it gets more uptake then whine when the license terms are being followed.

But then it wouldn't be widely used. The solution to that is for everyone to use AGPL then the open-source playing field is level again.

[SpicyLemonZest]

Right, but leadership is needed to coordinate that change. The OSI needs to stand up and say "hey, the widespread use of permissive licenses is a threat to the open source community; please try to avoid them, and here's some ways you can accomplish your goals without a permissive license." Most open source projects aren't monetized, and most monetized projects won't be picked up by Amazon, so without a coordinated push permissive licenses are just the simplest way to go.

[Hello71]

the FSF have been saying that for longer than the OSI has existed. people mocked them for saying that they were idealistic and unreasonable.

[SpicyLemonZest]

The FSF takes the more extreme stance that general adoption just doesn't matter. If big companies ban libraries using their recommended viral licenses, that's not a problem they're looking to solve; it just means the people writing free software will have an advantage.

[edoceo]

And some donate to both. FSF is a big reason we chose GPLv3 - when at first I was thinking MIT.

[tango12]

This is true. We had to change our license from AGPL to Apache to make sure enterprise adoption was frictionless because there’s often a blanket ban on AGPL.

https://news.ycombinator.com/item?id=20064281

[karmakaze]

Hmm, wonder if there's something we can take away from this. Let's say the latest major release is AGPL (or newer dominant copyleft) and the previous major release is more enterprise friendly licensed with those offering paid support handling the security and maintenance of them. This means that the community can continue to develop and use the latest and greatest. Not perfect but it might work in some cases.

[galaxyLogic]

Sounds like an interesting idea. How about taking it even further and say what you say above but then also provide the latest and greatest release also as a commercial version. Then companies who want the latest will pay for it and OS community gets the latest with AGPL, while companies who prefer MIT license get a version that works but is not the latest or greatest.

That would be much like paying for support, getting the latest and greatest earlier than those who don't pay for it.

[karmakaze]

I wondered about combining it with dual licensing, but I don't even know how people do that today. Say if a whole community contributed to an AGPL project and it has a dual commercial license, who controls and profits from it?

[galaxyLogic]

Maybe all (registered) contributors would have to sign agreement that they give rights to publish also with commercial license to the corporation or non-profit that is in charge of the distribution. Would they be willing to do so? Well maybe they should get a cut of the profits.

That gets complicated managing all the payments, but I can see a single company using this model for their own benefit. Build momentum with the (two) OS licenses and get some income from the commercial license.

What could make this an attractive simple-to-manage model is that there would still be just one product, with different time-based releases of it, provided with a different license.

No need to fix bugs in the older releases, they are fixed in later versions. And everybody gets the fixes eventually but those who pay (or agree to AGPL) get them sooner.

[galaxyLogic]

"previous major release is more enterprise friendly ..."

Previous major release would not have the latest features but it would have the latest bug-fixes. That would be enterprise friendly.

[eitland]

As far as I can see this mught actually be a good idea if:

- you want to make your software as open as possible

- while still making money from it

It would require the manufacturer of the software to have some momentum but it sounds doable for some.

[ryukafalz]

I would like to suggest that companies have such blanket bans precisely because they want to be able to take advantage of free software in this way without contributing back. If you really don't care if they do or don't, fine, use a permissive license. But I think it's becoming clear that people do care about contributions, and that's part of what copyleft licenses are for.

[hendzen]

Mongodb already used AGPL prior to switching to the SSPL...

[eeZah7Ux]

The problem is that only MongoDB did it, not the majority of the FLOSS ecosystem.

[kemitchell]

That’s not what Mongo said. They called out specific issues with AGPLv3’s terms.

http://lists.opensource.org/pipermail/license-review_lists.o...

[jandrewrogers]

Most companies use open source because the permissiveness gives them optionality that they value highly, and will even invest resources in supporting, but don't expect to exercise in most cases. If you eliminate that optionality (e.g. AGPL) then it erodes the value proposition of open source for companies and thus their interest in supporting it. This is the reason many companies will not touch AGPL, it eliminates most of the value they expected to get from the transaction. And without company support, open source development would languish.

This is the challenge, and it doesn't have an easy answer. Without optionality, open source offers little to corporate users.

[karmakaze]

> eliminates most of the value

Is this really true or just perceived? How often is that optionality actually exercised? And I don't believe that most of the value is in it. The benefits to using good software that continues to be maintained by those using or supporting it is immediate.

[bartread]

Dual-licensing is an option too: you can either have AGPL or pay for some other license that allows commercial use without the need to open source everything else.

[TAForObvReasons]

AGPL is vulnerable to certain workarounds in the same way that GPL was. The CC class of non-commercial licenses might be more applicable, but that may harm adoption.

EDIT: honestly not sure why this is so heavily downvoted (-7 as of the edit), the whole point of SSPL and other licenses is to address the "workarounds" that Amazon and others have discovered in AGPL

[yarrel]

Please don't use the (awesome) CC licenses for software -

https://creativecommons.org/faq/#can-i-apply-a-creative-comm...

[AnaniasAnanas]

Would you mind elaborating on that? I am interested in a super-copyleft license for my next project and thought that AGPL was the "best" option out there. In what ways can it be bypassed?

[verisimilitudes]

Don't be fooled. I use the AGPLv3 for almost all of my software because it's the strongest copyleft license currently available. Apparently, the only reason the AGPLv3 and GPLv3 are different is because of public outrage from some groups, but there's no disadvantages to use the AGPLv3 over the GPLv3 and I recommend it.

What is your project? I'd like to know, if you're willing to tell.

[Reelin]

Check mongoDB's SSPL FAQ (https://www.mongodb.com/licensing/server-side-public-license...).

As far as I'm concerned, SSPL is superior to AGPL in that it catches all the bits that make your software actually work, forcing you to include them as part of the offering. I honestly don't understand the apparent objection to referring to a license with such a clause as open source - all it does is close a (major imo) loophole.

[ryukafalz]

From my reading of SSPL v1, it would seem extremely difficult to use in concert with other free software; it requires you to distribute all software[0] you're using to run your service under the SSPL. The trouble is, you can't do that if you're using any other software in your environment that's licensed under another copyleft license such as the GPL. Does this apply all the way down to the Linux kernel? Who knows!

SSPL v2 appears to be an attempt to correct this[1], by explicitly excluding system components and allowing other FSF/OSI approved licenses if you're unable to release something under the SSPL yourself. But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment.

The GPL and AGPL have been around longer and have much more of a community behind them, and both versions of the SSPL are incompatible with them. At least for the time being, I'm inclined to stick with the AGPL for network services, because I like having access to all the GPL/AGPL code out there. Maybe someday I'll take a look at SSPL v2; I wouldn't touch SSPL v1 with a 10-foot pole.

[0] "all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software" [1] http://lists.opensource.org/pipermail/license-review_lists.o...

[Reelin]

It seems there are indeed serious issues with SSPLv1 that I was unaware of. That being said, the loophole in the AGPL that they are attempting to address is also a serious issue. The rewording in v2

> “storage software and hosting software” changed to “host orchestration software”

seems to be fairly reasonable though, unless I've misunderstood things once again?

> But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment.

From the page you linked,

> If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0.

so it seems they really do just want to address the current loophole in the AGPL.

[ryukafalz]

>> “storage software and hosting software” changed to “host orchestration software”

>seems to be fairly reasonable though, unless I've misunderstood things once again?

It's better, though note that the terms in the list referenced there aren't strictly defined.

>> If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0.

>so it seems they really do just want to address the current loophole in the AGPL.

Sure, I'll give them the benefit of the doubt on that. But the fact that they haven't switched over by now signals to me that they're not yet confident in the newer version of the license; if they're not, I can't say I am either.

And it's worth noting that SSPL v2 was withdrawn from the OSI review process back in March: https://opensource.org/LicenseReview032019

[detaro]

> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.”

So I can't run a service for it on VPS at a hosting provider, because I can not share the source to the backup system, hypervisor and load-balancer they use? Are firmware-blobs in my kernel-drivers ok? That seems extremely open and far-reaching, to the point that one could argue that it clearly is intended to forbid offerings as a service, even if it pretends not to.

EDIT: after looking up details about the "comical debate" (quote article), that indeed appears to have been one of the arguments. Not surprising the article badmouths the OSI, but doesn't actually engage with or even dare mention their arguments.

[Reelin]

Upon rereading the bit you quoted, I agree that could be an issue. I had initially misinterpreted "all such that a user could run an instance of the service using the Service Source Code you make available" to mean it was limited to any essential supporting bits you had implemented that might have otherwise been made proprietary (much to the detriment of a user trying to actually use the source code you provided). It does seem to be overreaching, but I also maintain that the AGPL has a major loophole as things currently stand.

Edit: From the sibling comment, it seems that SSPLv2 tries to address this.

[imtringued]

Someone with more money than you can do a proprietary clean room reimplementation.

[vorg]

@AnaniasAnanas: And someone with less money than you can use your software source code "as a reference" when writing their own open source reimplementation. They won't put your name in the copyright notice because they didn't use any of your code, they only used your code "as a reference" when writing their own.

[AnaniasAnanas]

So I will force them to waste money compared to if I used a more permissive license? Sounds good. Plus I could offer proprietary licenses this way.

[kemitchell]

https://paritylicense.com/

[AnaniasAnanas]

That's cool and all but it does not seem any more copyleft than AGPL, in fact it seems even less copyleft than GPLv3 as it lacks the Tivoization/drm/etc clauses.

[boramalper]

I’m not sure if CC is meant for software either (except for CC0 perhaps).

For instance, does non-commercial mean (1) you cannot use [the output of] the program for any commercial purposes, or does it mean (2) you cannot sell the program itself (and its derivatives).

The difference is subtle but AGPL permits (1) whilst practically forbidding (2) by enforcing copyleft; hence it fits the OSS criteria whereas CC NC wouldn’t if both (1) and (2) are true.

[detaro]

Creative Commons themselves say that CC licenses (outside CC0) are not designed and not recommended for software.