4 ms·
> Profit isn't far removed from theft I definitely think there are unethical ways to profit - capitalism needs to be regulated for the good of the consumer/eco
by bbkane 2y ago
> Profit isn't far removed from theft
I definitely think there are unethical ways to profit - capitalism needs to be regulated for the good of the consumer/ecosystem/society.
However, I don't believe that a blanket comparison of any type of profit to theft can be useful or correct.
> so maybe this shouldn't feel so unfair
Do you think this company is unethical for writing closed source software and trying to sell it?
- tison 2y agoThis article is actually a translated one. In the original article[1], I talked about commercial open-source and how one can collaborate with the open-source community when running a software business. This section is moved to the second-to-last section in the posted blog, including: [QUOTE] When you read The Cathedral & the Bazaar, for its Chapter 4, The Magic Cauldron, it writes: > … the only rational reasons you might want them to be closed is if you want to sell the package to other people, or deny its use to competitors. [“Reasons for Closing Source”] > Open source makes it rather difficult to capture direct sale value from software. [“Why Sale Value is Problematic”] While the article focuses on when open-source is a good choice, these sentences imply that it’s reasonable to keep your commercial software private and proprietary. We follow it and run a business to sustain the engineering effort. We keep ScopeDB private and proprietary, while we actively get involved and contribute back to the open-source dependencies, open source common libraries when it’s suitable, and maintain the open-source twin to share the engineering experience. [QUOTE END] I wrote other blogs to analyze open-source factors within commercial software[2][3][4][5], and I have practiced them in several companies as well as earned merits in open-source projects. When you think about it, there are many developers working for their employers, and using open-source software in their $DAYJOB is a good motivation to contribute more (especially for distributed systems; individuals can seldomly need one). I know there is open-source developers who develop software that has nothing to do with their $DAYJOB. I'm maintaining projects that has nothing to do with my $DAYJOB also (check Apache Curator, the Java binding of Apache OpenDAL, and more). [1] https://www.tisonkun.org/2025/01/15/open-source-twin/ https://www.tisonkun.org/2025/01/15/open-source-twin/ (Need a translator) [2] https://www.tisonkun.org/2022/10/04/bait-and-switch-fauxpen-source-strategy/ https://www.tisonkun.org/2022/10/04/bait-and-switch-fauxpen-... [3] https://www.tisonkun.org/2023/08/12/bsl/ https://www.tisonkun.org/2023/08/12/bsl/ [4] https://www.tisonkun.org/2022/12/17/enterprise-choose-a-software-license/ https://www.tisonkun.org/2022/12/17/enterprise-choose-a-soft... [5] https://www.tisonkun.org/2023/02/15/business-source-license/ https://www.tisonkun.org/2023/02/15/business-source-license/
- tison 2y agoAnd contributing back is one of the approaches to maintaining open-source dependencies. I have described how to deal with OSS dependencies in [1] (yet to translate it :P). [1] https://www.tisonkun.org/2024/11/17/open-source-supply-chain-risk/#%E5%A6%82%E4%BD%95%E8%8E%B7%E5%BE%97%E6%9C%89%E7%BB%B4%E4%BF%9D%E7%9A%84%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%EF%BC%9F https://www.tisonkun.org/2024/11/17/open-source-supply-chain...