4 ms·
Cool license [0]! [0]: https://github.com/billabear/billabear/blob/main/LICENSE.md https://github.com/billabear/billabear/blob/main/LICENSE.md
by lionkor 2y ago
Cool license [0]!
[0]: https://github.com/billabear/billabear/blob/main/LICENSE.md https://github.com/billabear/billabear/blob/main/LICENSE.md
- yamumsahoe 2y ago[flagged]
- notpushkin 2y agoFrom what I see it's basically BSL (and BSL was used until 4 months ago). It's neat that the new license is using “plain English” language, but were there any specific problems with BSL that prompted this change?
- hnbad 2y agoThe short answer is that FSL was designed as an evolution of BSL that doesn't allow for as much variance in what the license means in practice, i.e. it got rid of the "additional grants" and mandates a shorter, fixed expiration date. As I understand it, nothing FSL does couldn't be expressed in a modified BSL but having it as its own license makes it less ambiguous by not allowing for much variation beyond which specific license it converts to upon expiration.
- ezekg 2y agoTo add: the problem with the BUSL was that every variation of the BUSL was effectively its own license. The FSL reins that in so that a company's legal department could approve FSL full-scale, allowing all FSL projects to be used. The same full-scale approval could never happen for the BUSL due to the variances.
- fasteo 2y agohttps://fsl.software/ https://fsl.software/
- forkerenok 2y agoThanks for sharing! Got an answer to my question about updates there in the FAQ: > How exactly does the two years work? > The two year timeframe applies to each software version that is made available. Methods of making software available include pushing a Git commit, publishing a package to a repository, or mailing out a CD in a tin. For example, one could clone a repo, run git checkout `git rev-list -n 1 --before="2 years ago" master`, and—if LICENSE.md is FSL—use that version under MIT or Apache 2.0.
- phkahler 2y agoSo the key is to download the source for each version you use and record the date and the current license text. Also, use the oldest version you're comfortable with since it converts the soonest. I'm thinking for down the road when new releases are under a different (even commercial) license and the pull the source for old versions. Then cost starts to go up a lot. Not saying it will, but I hope the software is successful but that sometimes leads to bad things for customers.
- ezekg 2y agoOr just use git: git checkout `git rev-list -n 1 --before='2 years ago' master` and if the license is FSL, you're g2g.
- inktype 2y agoThanks. My initial reaction upon reading the submitted title was dismissive because I dislike when companies mimic the prestige of open source by saying "source available" while having a practically proprietary license. This is the first time I've seen FSL and it is quite nice. Surely "source available" is the wrong term to label the license with.
- ezekg 2y ago> Surely "source available" is the wrong term to label the license with. There's a new term coming very soon, "Fair Source." :) See: https://fair.io https://fair.io
- swyx 2y ago> mimic the prestige of open source by saying "source available" no, its just the correct term, we literally ask people who use the wrong license to change their terminology to "source available", lets not punish people who do it right from the get go
- inktype 2y agoYou misunderstood my comment; we probably agree. If something isn't open source, it shouldn't be labeled as open source. I'm saying that there ought to be a more descriptive term for this license to differentiate from the usual proprietary "source available" licenses. ezekg's comment gives an appropriately descriptive label, "Fair Source".
- foresto 2y ago> I dislike when companies mimic the prestige of open source by saying "source available" It can be a practical need, rather than a prestige grab. Some people can only sink time into developing their software if sales of that software pay their bills. The redistribution rights granted by an open-source license somewhat conflict with this, by allowing another party to appropriate their original work and use it to undercut them. (This is part of why a revenue model based on services, rather than sales, is often encouraged in open-source.) Meanwhile, the author might very much want to offer customers other rights granted by open-source licenses, like the ability to inspect the code, or to have it audited, or to modify it, or to build it from source as an assurance of what instructions are being executed. This is a situation where "source available" makes sense. Looking at it from the other direction, some potential customers will only accept software that grants the latter rights, but don't care about redistribution rights. "Source available" is a viable option for them as well. I wonder if it would be helpful to have a new, clearly defined term for a class of licenses granting inspection & modification rights without redistribution rights, and explicitly protecting users from additional restrictions like fees for source access. That could help make licensing of this kind easy to identify and understand, and if that meant wider acceptance, perhaps more developers would be willing to release their source code to users. (I do see "Fair Source" mentioned in another comment, but I haven't investigated to see if it aligns with what I'm describing.)