3 ms·

If it was a dangerous mode of thinking, then any request of support from the author is also a dangerous mode of thinking. After all, from the MIT license: 'THE

by II2II 5y ago

If it was a dangerous mode of thinking, then any request of support from the author is also a dangerous mode of thinking. After all, from the MIT license: 'THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED'. The author simply made a request, with the full realization that it was nothing more than a request given the license they had used. They are also far from the only only one to exhibit a similar attitude. I recall GNU being antagonistic about the distribution of Emacs under Windows in the past. Given their association with the GPL, that antagonism can be viewed as more of a statement than a request.

geofft 5y ago
Right - there's two parts of "open source" as the term is commonly used, open source as in the license, and open source as in the community. We look skeptically on companies whose "open source" involvement involves dumping code that works for them and not accepting contributions or responding to questions and not participating in upstream communities. We talk about being a good open source citizen because we have an analogy to the real world, where being a "good citizen" is more than merely following the law. We have opinions about codes of conduct (whether for or against) even though those don't affect the license at all. We talk about an open source sustainability crisis even though all the code that's been released so far isn't danger of disappearing. Maybe we need another term for it, but for now, the term as it is used in practice both refers to the licensing regime and the community and culture around it. The idea that projects have maintainers in the first place and aren't just released anonymously to the commons, and moreover that it's reasonable to contact the maintainer if you have a problem to report or an improvement to suggest, is a significant part of what defines the open source community, even though the term "maintainer" appears in no license (except the LaTeX one, which adds some obligations around non-maintainers marking modified copies which is called out in the DFSG as a compromise not to be encouraged). Frankly, it seems to me that the author in question just wants to stick by the license: they want to release the software and not be contacted about it by people who receive it from redistributors. That seems reasonable to me, in the abstract. The hard part is reconciling that with the norms of the community.
- jltsiren 5y ago
  There is no such thing as the open source community. There are many overlapping communities, with a great deal of variation in culture and norms. Research code is a good example of this, because the academia is full of niche groups with varying aims. In computer science, a lot of open source code is written for other researchers in the same subfield. Some degree of support is expected, as long as the request is related to research (and the original developer has not left the academia). Requests from people who just want to use the code feel awkward and out of scope. Many bioinformaticians write software for actual users. Inexperienced ones may read about a fancy new algorithm, find the implementation, and try to use it in their project. Confusion (and sometimes even conflict) ensues when they find that the proof-of-concept implementation from a CS researcher is not appropriate for real use. On the other hand, there are many unwritten rules about modifying and redistributing somebody else's code. Research is all about ideas, and building upon them without crediting the original authors clearly and visibly violates academic integrity.

by II2II 5y ago

geofft 5y ago

Right - there's two parts of "open source" as the term is commonly used, open source as in the license, and open source as in the community. We look skeptically on companies whose "open source" involvement involves dumping code that works for them and not accepting contributions or responding to questions and not participating in upstream communities. We talk about being a good open source citizen because we have an analogy to the real world, where being a "good citizen" is more than merely following the law. We have opinions about codes of conduct (whether for or against) even though those don't affect the license at all. We talk about an open source sustainability crisis even though all the code that's been released so far isn't danger of disappearing. Maybe we need another term for it, but for now, the term as it is used in practice both refers to the licensing regime and the community and culture around it. The idea that projects have maintainers in the first place and aren't just released anonymously to the commons, and moreover that it's reasonable to contact the maintainer if you have a problem to report or an improvement to suggest, is a significant part of what defines the open source community, even though the term "maintainer" appears in no license (except the LaTeX one, which adds some obligations around non-maintainers marking modified copies which is called out in the DFSG as a compromise not to be encouraged). Frankly, it seems to me that the author in question just wants to stick by the license: they want to release the software and not be contacted about it by people who receive it from redistributors. That seems reasonable to me, in the abstract. The hard part is reconciling that with the norms of the community.

jltsiren 5y ago
There is no such thing as the open source community. There are many overlapping communities, with a great deal of variation in culture and norms. Research code is a good example of this, because the academia is full of niche groups with varying aims. In computer science, a lot of open source code is written for other researchers in the same subfield. Some degree of support is expected, as long as the request is related to research (and the original developer has not left the academia). Requests from people who just want to use the code feel awkward and out of scope. Many bioinformaticians write software for actual users. Inexperienced ones may read about a fancy new algorithm, find the implementation, and try to use it in their project. Confusion (and sometimes even conflict) ensues when they find that the proof-of-concept implementation from a CS researcher is not appropriate for real use. On the other hand, there are many unwritten rules about modifying and redistributing somebody else's code. Research is all about ideas, and building upon them without crediting the original authors clearly and visibly violates academic integrity.