Live data from Hacker News

FSL: A License for the Bazaar, Not the Cathedral

lucumr.pocoo.org

11–20 of 201 posts

Re: FSL: A License for the Bazaar, Not the Cathedral

#12

I don’t think it’s reasonable to call it a “two-year exclusivity period”—it’s more like a two-year dead man’s switch. As long as the original SaaS is relevant you are never competing with it, because you won’t be able to reuse any security fixes that the original developer made. Unless, of course, you are Amazon or Oracle, and can afford an independent security team. I don’t know how I feel about this. Or, okay, righ…

> because you won’t be able to reuse any security fixes that the original developer made You are, just not in a competing commercial service. For that you would have to wait for two years. Which is precisely the point. In a non commercial, self hosted setting you're free to incorporate these patches.

That’s why I said “competing” and not “using”, yes.

It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored.

(Consequently, the original developer is not competing against old versions of their own software the same way as Microsoft used to be competing against old versions of Office or Apple is now competing against older Macbooks.)

Re: FSL: A License for the Bazaar, Not the Cathedral

#13
I like it.

I totally get the problem projects like mongo, redis and sentry face. AWS, azure etc just eat their lunch and don’t help anybody. That will kill open source in the long run.

This still gives me access to inspect the code, contribute fixes I might want, self host if I feel like it or pay someone for the SaaS if I don’t, knowing the money goes to someone who contributes to the project.

And if the original authors bork the product and after two years it becomes clear they won’t fix their ways, I can fork the old product code I liked and develop it into the product I want. Heck if I’m right and my idea is better than the original I’ll eat their lunch too.

Re: FSL: A License for the Bazaar, Not the Cathedral

#14
post #11

Doesn't the license conflict with itself? The "not-yet-Apache-licensed" code is obviously derived from the "now-Apache-licensed" code, thus it must be "Apache-licensed" too.

No, but that challenge would exist if it was GPL which is why a hypothetical FSL-GPL would not be possible.

Re: FSL: A License for the Bazaar, Not the Cathedral

#15
post #11

Doesn't the license conflict with itself? The "not-yet-Apache-licensed" code is obviously derived from the "now-Apache-licensed" code, thus it must be "Apache-licensed" too.

Apache 2 is not copyleft: derived works of Apache-licensed software can be distributed under more restrictive terms as long as all the acknowledgments, etc., required by the original are still in place.

Re: FSL: A License for the Bazaar, Not the Cathedral

#16
It's very hard for me to take anything which starts with CatB seriously. It was very charismatic, beating up a strawman which didn't exist, and zero of it played out as expected. Eric Raymond is mostly gone, as everything he's touched has failed. Open-source has started to realize Richard was right about ethics, as the two movements have increasingly converged. Richard, for his part, is still marginalized, socially awkward, and everything seems to be playing out by the playbook he wrote in the nineties.

This writing is just as confused. The author is missing the basic points of a license: A license is like a constitution for an ecosystem for how people will interact, a check-and-balance on the monopoly power of the license-holder, and a community contract. The FSL is looked at through none of those lenses. The attempts at empathy with the opposing viewpoints clearly don't express an understanding of those viewpoints. The reasoning is just bad.

Even taken at face value, a license which does not set up an ecosystem of equals is a cathedral license, not a bazaar one. The citation is weird.

Analyses needed for licensing:

- Who will contribute, and why?

- What ecosystem is being set up? One of equals? One with a central party?

- Why will my customers give me money? Does this preserve my ability to make money?

... and so on. Those require deeper dives. "If you build it, they will come" doesn't work. If you want contributions, for example (not everyone does), you want to do a deep dive on the needs, wants, and motivations of potential contributors. An ecosystem of equals (bazaar) will bring in more contributors, but also more competitors.

I'll give a personal example:

In my professional work, I use 100% open-source, largely to mitigate for the risk of what happens when the cloud vendor disappears. FSL mitigates that risk, while BUSL doesn't.

The license seems non-crazy, though, and a huge step up from BUSL. What's concerning, though, is that it's completely unclear that the author understands why this license makes sense, so it's liable to be misused. It feels more accidentally-stumbled-upon.

Re: FSL: A License for the Bazaar, Not the Cathedral

#17

Earlier quoted context omitted.

Yes, they could put extra paragraphs that become valid after 2 years, that would be OK. But the way it is written, it changes existing license! Effectively making a new release! You can not do that in EU, what if user does not agree with the new licence? It is quite illegal in most EU countries! You can not swap licenses like that! Many scammers do that, and there are strong pro-consumer laws to prevent that! What is…

> But the way it is written, it changes existing license! You can not do that in EU, what if user does not agree with the new licence? It is quite illegal in most EU countries! It is not illegal as the license terms are available from the start. The text of the license effectively changes. If you do not agree with what the license looks like after two years, you should not enter into that agreement in year zero. > Ma…

Ok, imagine following scenario:

- You started using product

- One year latter ASF stops existing, apache.org returns 404 or viagra ads.

- Two years latter, original FSL gets terminated, your new license for that software are 404 errors or viagra ads. You now have no license and should stop distribution!

Think what you want, software under FSL is on my ban list.

Re: FSL: A License for the Bazaar, Not the Cathedral

#18
post #13

I like it. I totally get the problem projects like mongo, redis and sentry face. AWS, azure etc just eat their lunch and don’t help anybody. That will kill open source in the long run. This still gives me access to inspect the code, contribute fixes I might want, self host if I feel like it or pay someone for the SaaS if I don’t, knowing the money goes to someone who contributes to the project. And if the original au…

What we have now is exactly what would have happened if the AT&T vs BSD lawsuit had come to a conclusion before Linux kernel came into the scene.

Big iron UNIX would keep going and cherry picking from the BSDs as it had done until the lawsuit took place.

It is no surprise that all new FOSS OSes for IoT, none of them embrace copyleft licenses.

Re: FSL: A License for the Bazaar, Not the Cathedral

#19

Earlier quoted context omitted.

> because you won’t be able to reuse any security fixes that the original developer made You are, just not in a competing commercial service. For that you would have to wait for two years. Which is precisely the point. In a non commercial, self hosted setting you're free to incorporate these patches.

That’s why I said “competing” and not “using”, yes. It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings…

> It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored.

I give you an analogy from the real world: MySQL was bought by Sun and then merged into Oracle. The original developers didn’t even like that direction and forked the project and build MariaDB. Some of the code they took was even older than the latest release. There can always be situations where a project withers for years and you get stuck with a license that impedes commercial revitalization. The FSL doesn’t come with that risk.

Re: FSL: A License for the Bazaar, Not the Cathedral

#20

Earlier quoted context omitted.

> But the way it is written, it changes existing license! You can not do that in EU, what if user does not agree with the new licence? It is quite illegal in most EU countries! It is not illegal as the license terms are available from the start. The text of the license effectively changes. If you do not agree with what the license looks like after two years, you should not enter into that agreement in year zero. > Ma…

Ok, imagine following scenario: - You started using product - One year latter ASF stops existing, apache.org returns 404 or viagra ads. - Two years latter, original FSL gets terminated, your new license for that software are 404 errors or viagra ads. You now have no license and should stop distribution! Think what you want, software under FSL is on my ban list.

That’s a purely hypothetical situation. Even in that case a court would very likely uphold the license just by the name. For what it’s worth plenty of software is only referencing a license by name or reference and I’m sure you are using that software as if that license were there in hardcopy.

More importantly if you want to make a fork you can always retain that license the moment you fork, not the moment the license swaps. In fact you probably would want to start collecting contributions under Apache 2 straightaway.

Post reply on HN