38 ms·
So the maintainers should be legally required to maintain the software, for free, forever, just because you depend on it? That is an insane level of entitlement
by chlorion 4y ago
So the maintainers should be legally required to maintain the software, for free, forever, just because you depend on it? That is an insane level of entitlement.
So long as it's their software they can change the license of new versions as they desire. If they decide to change the license and you depend on the software, you can maintain a fork of the project. I'm sure you don't like that answer, but this is exactly why open source licenses offer no warranty or promise of support, and you willingly decided to rely on some software with such a license. You can't just pretend like this aspect of the license doesn't exist because it's inconvenient for you.
If you want guaranteed support for any software, hire someone, or do it yourself!
I think a lot of the controversy surrounding these situations is that people aren't educated about what open/free software really is, or the ideals behind it, or don't care and just want free stuff from other people.
The idea is that you can use source code, modify it and create derived works from it if you desire (normally with attribution or whatever), and with the GPL there is an additional restriction that derived works must also be GPL'd. Free software does not imply that people want to work for you for free and doesn't imply that they intend on supporting the project at all.
- ChrisMarshallNY 4y ago> So the maintainers should be legally required to maintain the software, for free, forever, just because you depend on it? That is an insane level of entitlement. I didn’t get that, at all, from the GP. They just said that it’s not (in their opinion) fair to build up a user base that becomes dependent, then use that dependency as leverage. That’s basically the Sackler Family method. I release a bunch of code, as MIT. If someone wants to use it, fork it, sell it, whatever. Just don’t expect me to be on the hook for maintaining it, or guaranteeing it. If I want to drastically change it, or even do something evil, like have it phone home, I could do that (I won’t). I could also change the license, going forward, as these folks did. I’m under no obligation to maintain my stuff for any reason, other than I use it, myself, so I want it to be good. That said, I consider myself to be an excellent steward, of really good software, that no one (except Yours Truly) uses. That’s fine with me, but I take great care of my stuff, anyway. If I sign a contract, then that’s a different matter.
- croes 4y agoWhat percentage of the user base is really affected by the license change?
- knocte 4y ago> They just said that it’s not (in their opinion) fair to build up a user base that becomes dependent, then use that dependency as leverage. And saying this doesn't make any sense. Because being opensource means lack of vendor lock-in. There's no "dependency". As soon as a new license is adopted, the users of the previous version can still use that previous version because it is still opensource, and create a fork out of it.
- naasking 4y ago> As soon as a new license is adopted, the users of the previous version can still use that previous version Can they technically? If nobody stored a copy of the code, and the copyright owner decides to change the license, any subsequent copies are under the terms of the new license no?
- croes 4y agoThey can still use the library and even decompile it if necessary.
- ChrisMarshallNY 4y agoIf I use a service like GitHub, then it’s child’s play to get previous versions. But that’s beside the point. If someone releases software without storing the whole build in configuration management, then I don’t feel particularly sorry for them.
- naasking 4y ago> If I use a service like GitHub, then it’s child’s play to get previous versions. And they could delete the repository. Even if they had a repository, as the copyright holders they could change the license retroactively. This is not a problem with a technical solution that I can see.
- naasking 4y ago> So the maintainers should be legally required to maintain the software, for free, forever, just because you depend on it? No, but I can see the following as not being unreasonable: 1. They can't retroactively change the terms of using the previous versions or accessing it's code. 2. They should maybe start their new commercial version under a different name. They built a reputation on an open source brand, and they had other people promote them because of that open source status. I'm not sure the commercial version should get to start from the brand reputation that the open source version's name automatically conveys. This i think is a big part of the bait and switch the OP was referring to and it seems like a somewhat reasonable compromise. I'm not saying these apply fully to this situation, but as maybe just general guidelines if moving from an open source model to a commercial model.
- Semaphor 4y ago> 1. They can't retroactively change the terms of using the previous versions or accessing it's code. They already can’t do that.
- UltraViolence 4y agoWhen they started this project they should've asked themselves if they wanted to be reimbursed for their effort. If so, they should've started a company and sold the software commercially, releasing the code as an aside. Instead they bait users into believing this is a hobby project by some smart engineers who do this in their spare time to produce software that's a boon to all Mankind. Afterwards they start complaining this company or that company is making money off their effort and start making avaricious changes to the license. I myself have released several open-source projects, but don't intend charging for them. OTOH users can't expect me to add features or functionality (I do guarantee that security errors will be fixed in short order). I'm also working on commercial software, asking myself beforehand if I wanted to release it as free software or make money from it. Considering the effort I decided to do the latter.