Hacker News Reader

> My understanding is that if I wanted to fork a piece of software, this licence would prevent me from doing so for two years. Then after those two years, I would essentially be stuck using an old version of the source and have to play catch-up with the devs, who would be able to use my work for free but I would not be allowed to use theirs.

The answer is a bit of yes, and a bit of no. If the project is actively maintained then that company that does so, has the first mover advantage. If that company slows down / does something dodgy, you can fork it that very moment. You can't commercially compete for two years which is correct, but it opens up that opportunity.

> Had this license not been used there would be nothing preventing me from forking the software.

Except potentially an even worse license or an open core model where the best bits are not public at all. I do not believe this to be a better model. You're right that in the hypothetical situation a project could be open source without any restrictions and the original developers can reap the benefits without any free-riders coming along. But our experience has shown that just appealing to the good in people doesn't work.

> All those examples you cited weren't using this licence, and probably would have had a much harder job creating their forks if this license was used.

I would argue that that is not the case. Xapian under a hypothetical FSL would long have been able to commercialize it. MariaDB had more options for commercialization than they do today because of the GPL limitations. That said, I'm not working there so I cannot say how much the GPL was a hindrance.

What are your thoughts on AGPL? Is it not good enough? Do you think (lets say it out loud because we all know what we are talking about) Amazon Web Services will have advantage over you if you picked AGPL as your license?

At the end of the day, I think your sales team has to earn its salary. It can't just phone it in like (I assume) Microsoft sales does with Microsoft SQL Server. Why isn't AGPL good enough?

Genuinely asking, what change does it need to make it better?

Edit: previously on hn https://news.ycombinator.com/item?id=34768668

> What are your thoughts on AGPL? Is it not good enough?

I'm generally not a fan of GPL based licensed because it means that you create a massive dis-balance between the original copyright holder (who can dual license for commercialization) and everybody else. It might be fine for Sentry or another SaaS business, but then you cannot even take pieces of code and use it in another project that cannot be GPL licensed because for instance it needs to go the app store etc.

GPL (and AGPL in particular) is considered such a tainted environment that many steer away from it entirely. AGPL also is from the v3 family of GPL licenses which have outright bans in many commercial environments. But GPL in general is a too complex topic to address in a HN comment for me.

> I'm generally not a fan of GPL based licensed because it means that you create a massive dis-balance between the original copyright holder (who can dual license for commercialization) and everybody else. It might be fine for Sentry or another SaaS business, but then you cannot even take pieces of code and use it in another project that cannot be GPL licensed because for instance it needs to go the app store etc.

> GPL (and AGPL in particular) is considered such a tainted environment that many steer away from it entirely. AGPL also is from the v3 family of GPL licenses which have outright bans in many commercial environments. But GPL in general is a too complex topic to address in a HN comment for me.

This is very helpful, thank you. I have no insider information about elastic or sentry. Everything I know about the whole thing is from comments such as from HN. What I am hearing from you is that you don't see big cloud providers such as AWS as a threat but rather as an insurance policy so as users you can feel relatively safe in picking a SaaS product knowing that in the future (two years from now?) if the vendor were to go tits up, you can still have someone else who will step in and fill the void. I thought your intention was to make it as difficult as possible for another SaaS provider to compete against you but... clearly not? I appreciate the thoughtfulness of all of this and the pain of SaaS customers because just having the source code isn't enough. Often times, I am simply not qualified to run something like sentry myself and it is a matter of either spending tens of thousands of dollars a year on a SaaS or spending hundreds of thousands of dollars on another dedicated employee.

That being said, what I am reading from your comment is that the problem with GPL at least from the perspective of the user is all about perception and not about substance.

From what I understand as a hobbyist, I can essentially disregard licenses altogether. I am not distributing anything. You could license flask as Oracle Evil License (not actual name of the license, just making it up) and it wouldn't matter as a hobbyist because all I am doing is learning about flask.

What I mean is AGPLv3 should be fine for companies who are not SaaS providers and those who are SaaS providers, should contribute back.

What makes you not a fan of GPL?

What about GPL projects without a CLA that have multiple copyright holders, so that none of them can dual license?

> Xapian under a hypothetical FSL would long have been able to commercialize it.

I feel like you still aren't understanding what I'm saying here. Suppose a hypothetical version of the Xapian devs existed that were willing to use the FSL, but didn't because it didn't exist at the time. I could email those people, and ask "can you give me an Apache licensed version of your code from two years ago". They would then give me a copy of that code. The license is just a written expression of what a developer is willing to do. The existence of this licence doesn't actually change what devs are willing to do. It doesn't solve any problems. Anyone not using this license can still release old versions of their software under a different licence. Likewise anyone using the licence can always stop using it for future revisions of their software. It doesn't enable you to do anything, and it doesn't provide much of a guarantee to users.

> Suppose a hypothetical version of the Xapian devs existed that were willing to use the FSL, but didn't because it didn't exist at the time. I could email those people, and ask "can you give me an Apache licensed version of your code from two years ago". They would then give me a copy of that code.

Just to be clear what happened at Xapian: a bunch of people built some software. It was open sourced under the GPL which prevented further adoption. Through some series of acquisitions the copyright holder ended up not caring about it and did not enable anyone to relicense it under another license. If that was FSL licensed to begin with, the moment the copyright holder no longer cared, it would have become available under a license again that enabled commercialization. The folks behind Xapian are unaware of the exact licensing status, but definitely cannot relicense: https://trac.xapian.org/wiki/FAQ/CommercialLicence

They for a while I believe tried to prevent further GPLification of the source.

This is such a niche case it's not really worth talking about, but the original devs still released it under GPL. The FSL is literally just the Apache license in this case. So you aren't arguing for the FSL, just that the original devs should have used Apache instead of GPL. That's just your opinion. If there was a version of the FSL that converted to GPL after two years, you'd have the exact same issue. The FSL portion of the licence is not relevant as no one was ever interested in releasing Xapian under a closed licence for a limited amount of time.

This isn't really a rebuttal to my wider point that FSL doesn't do anything you couldn't without it. There's nothing stopping you from just releasing old versions under a different license anyway, and no real reason to commit to doing so specifically for the next two years.

> If there was a version of the FSL that converted to GPL after two years

That would not work to begin with, and I already explained elsewhere in this comment thread why.

Look, I understand that you do not subscribe to this argument, there is very little I can do to convince you otherwise. I'm coming out of a community that embraces permissive licenses. The FSL plays that tune with a twist that is the exclusivity period.

> There's nothing stopping you from just releasing old versions under a different license anyway, and no real reason to commit to doing so specifically for the next two years.

There are lots of things that can be done, many other licenses can be forged. But some of these are depending on the goodwill of a future actor. All of this seems worse.

> I already explained elsewhere in this comment thread why.

Your explanation seemed to be predicated on the idea that you would have to stick to the terms of your own licence. This isn't true. A license only describes what other people can do. As the copyright holder, you can do whatever you want. For instance, you can offer a dual license, or offer different licenses to different people. An FSL-GPL is perfectly feasible.

> But some of these are depending on the goodwill of a future actor.

The FSL also depends on this. Someone releasing FSL code could easily switch to a different license at some point in the same way that someone who was releasing their past source code could decide to stop doing so. This would result in an almost identical situation in practice. The FSL still offers no difference from just releasing the source voluntarily, because it is just you agreeing to release the source voluntarily.

> This isn't true. A license only describes what other people can do. As the copyright holder, you can do whatever you want.

In the future. A copyright holder can’t change the artifact you are already holding.

> The FSL also depends on this. Someone releasing FSL code could easily switch to a different license at some point

Sure. At which point it no longer is FSL licensed. The code drop of today is fully open source two years from now. Nobody can take that away.

> In the future. A copyright holder can’t change the artifact you are already holding.

Yes, but you can literally just copy the GPL into the bottom of the FSL and you have a valid license.

> The code drop of today is fully open source two years from now. Nobody can take that away.

If you open-source the code-drop from two years ago, no one can take that away. There are two cases here:

If the code isn't FSLed and the dev decides to stop distributing source, a fork will have to be made using the outdated source that has previously been released under an open license.

If the code is FSLed and the dev decides to drop FSL, a fork will have to be made today using the old code, or can be made later using code that's just as out of date.

These aren't substantially different.

> My interpretation of this license is that it's effectively saying: "you can't do anything with this while we're working on it".

I disagree. It depends if you're forking it to use it, or if you're forking it to compete commercially against the authors.

The license does not prevent you from the former. You could fork it and do what you want with it to monitor your own non-competing software.

And if your goal is the latter – to fork the project to compete with the original authors – why do you feel you should be allowed to do that? Sentry is developed by employees on its payroll, not from community contributions (with a caveat that there are many parts that are fully permissive OSS, licensed under Apache 2 or MIT, and those projects do have some community contributions). And yes, the license is meant to discourage this competing use – for 2 years.

No license can prevent you from making alterations to your private copy of a piece of software.

> No license can prevent you from making alterations to your private copy of a piece of software.

The right to make alterations to someone else's intellectual property does not exist except as granted by licence or fair use exceptions.

Copyright is about copying. For instance, if I buy a book, I cannot distribute copies of that book. But I can write whatever I want in the book, change any of the text in it, provided I don't then copy the modified text. They own the copyright to the intellectual property, not the physical item you are given or the bits in your computer's RAM, which you are free to do as you please with.

> I disagree. It depends if you're forking it to use it, or if you're forking it to compete commercially against the authors.

The problem is that whilst the license attempts to define what "competes" means, it's not a good definition. Specifically:

  Competing Uses specifically include using the Software:
  1.  as a substitute for any of our products or services;
  2. in a way that exposes the APIs of the Software; and
  3. in a product or service that offers the same or substantially similar functionality to the Software.

(1) & (3) are highly subjective, and (2) attempts to assert a copyright claim over APIs (definitely doesn't work across most jurisdictions). No-one is going to seriously use this software with such a badly written and vague license.

(I suspect this is on purpose, and the actual motivation of the license author is to try and discourage anyone else from using / forking the software, whilst at the same time getting marketing cred for pretending to be "open". It's a source-available license. Others may come to different conclusions).

I'm not a lawyer, but here's my non-official interpretation:

1) If you host the software, and say "hey get your Sentry over here", that's basically a substitute.

2) Means use the work in such a way where you expose its APIs (i.e. the software is returning API responses). Note this is written as "using the software ... in a way that exposes the APIs of the software".

Perhaps this could be made more clear, but I believe this was written with the understanding that there is prior art on the copyrightability of APIs, not some feigned attempt to assert a copyright.

3) If you're building some kind of software observability platform that leverages Sentry.

If you're concerned about doing any 3 of those, then yes, perhaps you should not use the software. Overwhelmingly 99.99% of software people aren't doing anything remotely close to any of these clauses.

I'll also note that Sentry itself was licensed for 4+ years under BUSL using similar terminology (that was arguably far more vague). The inclusion of non-competitive language in the license did not stop users from using the software – because again, most people aren't competing.

You're welcome to make your own decision, of course. No one is forcing you to use anything.

If you follow the link to the actual license, it does list done explicitly permitted uses. So yes, it does seem that you can fork it and do something useful with the fork.

That something useful is restricted, which is the point of the license.

I think the intention here is reasonable and honest as presented by the big list. Whether the actual legal language matches that intention - who knows. I'm worried that it might not but IANAL.