Live data from Hacker News

FSL: A License for the Bazaar, Not the Cathedral

lucumr.pocoo.org

31–40 of 201 posts

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

#31

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 a…

Your comment, and this line in particular:

> 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.

finally gave me an answer to the question that bothered me for a while: how do we reconcile the goal of making FOSS available for everyone to run/tinker with/distribute freely with the issue of corporations leeching off community-created FOSS? Now the solution is clear to me: less focus on licenses, more focus on people interactions and actual contracts.

Instead of writing some code and throwing it to the MIT-license winds with little hope to gain anything in return it should be possible to create software cooperatives, i.e. real legal entities, with a simple premise: the code is free for non-commercial use; any person whose contribution was accepted is free to join the cooperative; any company that wants to use software stewarded by the cooperative has to pay for it, with said payment being shared among the members and/or saved for later. That would be an overkill for a tiny personal weekend FOSS project, but for serious products the overhead of formalizing the community would likely be totally worth it.

I'm pretty sure I'm not the first to come up with such an idea, I wonder if anyone has already implemented it in practice.

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

#32

Please stop using the Apache licenses. License compatibility is too important. Use MIT (my preference) or BSD if you want a "permissive" one and GPL or LGPL otherwise (v3+ preferred). Anything else is just making non-reusable code. Apache is the same org that actively harms one of the highest visibility open source projects by keeping "Open Office" around. Their licenses are similarly unwelcome IMO.

> GPL or LGPL otherwise (v3+ preferred).

I'm confused about your concern then if v3+ is preferred. Apache 2 is compatible with the GPL 3 family of licenses, it's just not compatible with the GPL 2 family of licenses. The only incompatibility of Apache 2 are GPLv2 licenses, but so is GPL 3.

Apache 2 has some benefits to the user over MIT, but the GPL incompatibility is why there are two flavors of FSL.

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

#33
post #26

Earlier quoted context omitted.

For what it's worth, your writing is confused. For instance: > There cannot be a limbo where the rights holder prevents the flourishing of a fork out of lack of interest or fear. The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule. But the really strange part about this is that it assumes a developer…

> The entire point of this license is to prevent forks of software. If that was the case, it would be a different license. The point of the license is to enable forks, but with some restrictions. There are many (once) Open Source software projects where the rights holder at one point made decisions that required a full community (or even commercial fork). The license does not want to take that opportunity away. From…

I feel like one of us is fundamentally misunderstanding this license. 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. Had this license not been used there would be nothing preventing me from forking the software.

My interpretation of this license is that it's effectively saying: "you can't do anything with this while we're working on it". Which is fair enough and has its benefits, but it's not open source as much as it is a promise to become open source if the licencor ever loses interest.

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. Xapian specifically highlights a flaw in your logic. The creators of Xapian wouldn't have used this license because they don't want to re-licence their software. The only people that would use this license are ones who were already willing to re-license their software. The existence of this license doesn't actually solve the problem because you can't force people to use this license any more than you could force them to use an open license.

*edit: it's worth pointing out that this really does basically kill any chance of a fork. Normally you could start a fork with a single dev and then grow it naturally, but with this license you need a team the size of the official team to put in two years of work, and to keep doing that in perpetuity.

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

#34

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 a…

> Richard

For the entire first paragraph, I had no idea who you were referring to; then I realized you were talking about Stallman!

The Richard I was imagining in my head was more Hendrix, not the various oddities and eccentricis of Stallman.

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

#35
I might be missing something here, but this doesn't seem compatible with the bazaar model at all. You say

> It also enables contributions by the community for the latest version and not old source code.

But you will not be able to accept such contributions without an additional license, because you yourself would be unable to use them for a Competing Use (running your service). This makes it much closer to a cathedral, with a "small bands of mages working in splendid isolation". Sure, your work will be publicly visible, but that's it.

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

#36
post #26

Earlier quoted context omitted.

> 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. The author of the post (me) was part of the group at Sentry that created that license. I can’t dispel your interpretation that my writing is “confused” but I can assure you that a lot of thought went into the license. That blog p…

For what it's worth, your writing is confused. For instance: > There cannot be a limbo where the rights holder prevents the flourishing of a fork out of lack of interest or fear. The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule. But the really strange part about this is that it assumes a developer…

> It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule.

What does that achieve? You can just use the two-year-old copy of the code.

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

#37
post #36
post #26

Earlier quoted context omitted.

For what it's worth, your writing is confused. For instance: > There cannot be a limbo where the rights holder prevents the flourishing of a fork out of lack of interest or fear. The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule. But the really strange part about this is that it assumes a developer…

> It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule. What does that achieve? You can just use the two-year-old copy of the code.

I suppose not much. So the licence does succeed in forcing software to go open source after two years, but before that, it still effectively forces the maintainers of forks to put in an equal amount of effort to the holder of the licence. This makes a fork much harder since it would require a development team equal in size to the official one two years to bring it up to date.

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

#38
post #33

Earlier quoted context omitted.

> The entire point of this license is to prevent forks of software. If that was the case, it would be a different license. The point of the license is to enable forks, but with some restrictions. There are many (once) Open Source software projects where the rights holder at one point made decisions that required a full community (or even commercial fork). The license does not want to take that opportunity away. From…

I feel like one of us is fundamentally misunderstanding this license. 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. Had thi…

> 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.

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

#39
post #22

So, essentially, this is a closed source or source available licence. Anyone trying to develop open source with this will be stuck two years behind the official release and so it won't be worth trying. I don't get how it solves that freeloader problem either. The one benefit I can see is that it forces software to stay relatively up to date as, if they don't make enough changes in a two year period, they will likely…

> Anyone trying to develop open source with this will be stuck two years behind the official release and so it won't be worth trying.

Only if you're a direct SaaS competitor. In that case, you'll have to diverge based on two year old code, which seems fair to me. (And you're always free to start your own project, if you want to compete...)

> I don't get how it solves that freeloader problem either.

Because freeloading competitors are stuck with two year old code, putting them at a disadvantage, or compelling then to invest in that old code (some of which might find its way into the original branch).

> I don't see any benefit to the developer using this license except that it makes them feel like they are doing open source.

Is there really a need for this amount of negativity/scepticism?

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

#40
post #26

Earlier quoted context omitted.

For what it's worth, your writing is confused. For instance: > There cannot be a limbo where the rights holder prevents the flourishing of a fork out of lack of interest or fear. The entire point of this license is to prevent forks of software. It makes it especially easy to do so by simply pushing small incompatible changes on a two-year schedule. But the really strange part about this is that it assumes a developer…

> The entire point of this license is to prevent forks of software. If that was the case, it would be a different license. The point of the license is to enable forks, but with some restrictions. There are many (once) Open Source software projects where the rights holder at one point made decisions that required a full community (or even commercial fork). The license does not want to take that opportunity away. From…

What about the GPL prevents adoption?
Post reply on HN