Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FSL: A License for the Bazaar, Not the Cathedral

lucumr.pocoo.org

Post reply on HN
Print view View original

21–30 of 201 posts

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

#21

Post by benj111 »

the_mitsuhiko wrote: post #14
qznc wrote: 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.

No.

If I write software I can release it how I want. I can release it as gpl. If someone approaches me wanting a closed source version I can do that.

If I submit a patch to the Linux kernel I can also give that patch to Microsoft to put in Windows.

The closed code isn't 'based on' Apache code. The copyright holders have released the older code as Apache.

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

#22

Post by James_K »

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 be forked and someone else will add the fixes that the devs weren't. But this is also potentially a negative as it inventiveness regularly breaking compatibility with old versions.

I don't see any benefit to the developer using this license except that it makes them feel like they are doing open source. A better approach would just be to accept public contributions under a closed, source-available licence. Or, better still, just offer separate personal and commercial licences.

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

#23

Post by the_mitsuhiko »

frognumber wrote: post #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 a…

> 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 post is not a “here are all the reasons for the license” but it narrows down on a very specific aspect of it. You can read the original announcement post for more context and you can also listen to a panel discussion about it with me, Chad from Sentry and Heather Meeker who helped us draft it: https://www.youtube.com/live/UB9fo7pnDzY?si=0HVI6FsR42Pn5yP2

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

#24

Post by bonzini »

the_mitsuhiko wrote: post #9
mananaysiempre wrote: post #7

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.

You can always clean-room reverse engineer it. Or you can look yourself for 0-days in the released version, and develop simultaneously the fix for the closed and the open source version. You just have to be creative.

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

#25

Post by the_mitsuhiko »

benj111 wrote: post #21
the_mitsuhiko wrote: post #14

Earlier quoted context omitted.

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

No. If I write software I can release it how I want. I can release it as gpl. If someone approaches me wanting a closed source version I can do that. If I submit a patch to the Linux kernel I can also give that patch to Microsoft to put in Windows. The closed code isn't 'based on' Apache code. The copyright holders have released the older code as Apache.

That is true in principle but not how the FSL functions. The FSL ceases to exists at the two year anniversary and turns into another license (eg: Apache 2). If it were to turn into GPL the before and after code pieces would not be compatible.

The original author would retain copyright and they alone could make that software available under another license (eg: dual licensing) but nobody else would be in that position.

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

#26

Post by James_K »

the_mitsuhiko wrote: post #23
frognumber wrote: post #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 a…

> 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 that is scared of allowing their work to be forked would decide to use a license that forces them to allow their work to be forked. They simply wouldn't. That's the exact thing they were scared of.

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

#27

Post by 0xDEF »

ic_fly2 wrote: 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…

>AWS, azure etc just eat their lunch and don’t help anybody

I know that AWS made a blatant hosted version of Elasticsearch without contributing back but the other examples are less damning.

Azure's MongoDB offering is just the MongoDB API on top of their own document-oriented storage and querying architecture. Their globally scalable Redis offering is most likely also their own implementation and only using the same API as Redis.

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

#28

Post by cowsandmilk »

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

I have no interest in contributing to a code base that where my contributions wouldn’t be open source for two more years. You’ll find naive developers out there, but my free time won’t be spent contributing and my company would never allow me to contribute.

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

#29

Post by the_mitsuhiko »

James_K wrote: post #26
the_mitsuhiko wrote: post #23

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…

> 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 MySQL to MariaDB, from OpenOffice to LibreOffice, many projects no longer live under the original leadership. There are also other cases such as Xapian which are stuck under a GPL license that prevented adoption, but the rights holder (I believe it was Orange) had no interest in the project but also no desire to relicense under something that would permit commercialization.

The point of the license is ensure that the commercial entity (us) that is funding the project, can do so without taking away the long term viability of the project even beyond the hypothetical future non-existence of that entity.

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

#30

Post by phkahler »

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.

Post reply on HN