4 ms·
I think a little bit differently about that: There are some duties that apply to people that are open sourcing stuff: * Don't lie about what it does. * Don't
by PhilKunz 4y ago
I think a little bit differently about that:
There are some duties that apply to people that are open sourcing stuff:
* Don't lie about what it does.
* Don't hack people by smuggling some nasty code into minor version updates.
* Don't leave people vulnerable to third party exposure by not taking care of your private keys.
I am an Open Source dev myself, having about 300 modules on npm. I use it as reputation credit for actually getting jobs that pay good money.
If you are an Open Source dev, you are a "Code Influencer". You have to be straight about what you do. It is the same for normal influencers when they have to declare any paid promotion stuff.
- capableweb 4y ago> There are some duties that apply to people that are open sourcing stuff: No, zero duties. The express purpose of Open Source is that I can release code for free to world, and it's your responsibility to figure out if it's what you need. Adding some arbitrary "duties" that people must fulfill to release open source, is something else, and should not be called just "Open Source" as that already has a definition. If you get hit by any of those points you list, then you're the one responsible for that. > If you are an Open Source dev, you are a "Code Influencer". That's mixing up terms. Open Source developers are developers who release Open Source code, that's it. People who try to "influence" the ecosystem one way or another, could be called "code influencers" I guess, but please don't mix them together. One doesn't imply the other.
- PhilKunz 4y agoSo how is a normal influencer then an actual influencer, and not just a person "releasing" content "for free to (the) world"?
- capableweb 4y agoI couldn't care less about the definition of what an "influencer" is or not. What we're talking about here is releasing code as FOSS. Just because I add a MIT license to code I publish publicly, doesn't mean I want to be some "influencer" or whatever. It just implies (rather explicitly) exactly what it says in the license text, nothing more, nothing less.
- saagarjha 4y agoNope, you never have zero duties, as much as you would like to be a jerk to people. Just like putting salmonella in your free cookies will get the police to show up at your door real quick, releasing open source code with malicious behavior, or lying about what you’re doing, or just straight up being a rude person is not really acceptable, open source maintainer or not. There are appropriate consequences for all of these, and not all of them involve the legal system.
- capableweb 4y agoPurposefully poising people without disclosing that, is illegal. Yes. Purposefully infecting computers with viruses without disclosing that, is probably illegal too. Yes. Publishing code that on purpose infects computers with virus but disclosing that, is probably not illegal. Publishing code without any disclosures at all, which happens to infect people, is probably not illegal either. You don't have to download random code from GitHub and run it. No one is forcing you to. And if you do so, you're responsible for your own actions. Lying about what you're doing or being rude is shitty, and the ecosystem should not support that, I agree with that. But throwing in a MIT license together with some code you publish, doesn't simply that you won't lie or that you won't be rude. It just says that you can use that code if you want to. What you're looking for if you're looking for promises of not being lied to, is something closer to a Code of Conduct or Contributing Guidelines. It's outside the scope of (most) licenses.
- saagarjha 4y agoRight, there's levels of consequences here. You're very focused on what's illegal. Some of the things I mentioned are illegal and you would probably be sued/go to jail for them. Some probably aren't illegal or may even be explicitly legal (NO WARRANTY, etc.) but there are still consequences to doing it. You'll often only get the chance to get people to try your published code that happens to infect them once, and after that they will not only avoid your software but also get people to do the same. They may even be upset that your software did this, because despite there being no legal agreement in place between you and the person that downloaded your software to prevent this, they do have a social expectation that you're not being negligent, or misrepresenting your code. Nothing stops them from calling you a jerk.
- orlp 4y ago>> * Don't lie about what it does. >> * Don't hack people by smuggling some nasty code into minor version updates. >> * Don't leave people vulnerable to third party exposure by not taking care of your private keys. > > If you get hit by any of those points you list, then you're the one responsible for that. If someone on the street hands you a free sample, say a candy bar, is it then your responsibility to check that the candy bar: 1. contains no razor blades (malicious behavior), and 2. contains no peanuts because of your allergy even though the packaging says it doesn't (lying about what it is)? Obviously not, anyone handing those out violating those assumptions is an asshole and in most jurisdictions a criminal. It is not the responsibility of the acceptor to check these things, our society expects (and enforces through the law) that people are honest and non-malicious. Even if the sample is free. The exact same applies to source code you distribute. It would not be reasonable to analyze every free candy bar for hidden razor blades by meticulously taking it apart, nor do a spectral analysis for peanut traces in exactly the same way it is not reasonable for people to verify every line of code.
- thesuperbigfrog 4y ago>> It is not the responsibility of the acceptor to check these things, our society expects (and enforces through the law) that people are honest and non-malicious. Even if the sample is free. >> The exact same applies to source code you distribute. It would not be reasonable to analyze every free candy bar for hidden razor blades by meticulously taking it apart, nor do a spectral analysis for peanut traces in exactly the same way it is not reasonable for people to verify every line of code. That is not what the licenses say. Most FLOSS licenses have a clause like this: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. If the author explicitly disclaims all responsibilty about the released software, then all responsibilty falls on the user.
- threatofrain 4y agoI'd say that your rules apply to everyone whether or not they are part of an open source community. Being a closed source dev doesn't make malware morally acceptable. Lying is a complicated thing as everyone does it, but no matter the context, you can't be surprised if you face social consequences for deceiving people. And allowing people to use your stuff for wrongdoing is also going to affect your reputation, in the same way that someone using your Facebook account for bad shit is going to come back to you. A more interesting discussion would be on the relationship between a volunteer organization and its volunteers, as this post is probably in response to a recognized community contributor.
- Lio 4y agoSorry but there are no extra duties implied by open source other than what's in the licence. Licences usually explicitly say that there is no support and no implied duties other than those guaranteed by law. Open source/free software existed long before nebulous[1] terms like "influencer" came into fashion. All it means is that you get the source code and some limited rights to modify, distribute and run the code. The rest is on you. If you don't like the licence, don't use the software. If you don't trust the author or group behind it, don't use the software. If you don't think the project is well run or not, don't use the software. If you don't like the politics of the people involved, don't use the software. If the website "smells funny", don't use the software. If you can't tell if the software is safe or not... you guessed it, don't use the software. If you drink from puddles then it's up to you to decide if the water is clean or not. 1. i.e. there is no definition in law to what this means.
- Paianni 4y agoSo everyone should reject all proprietary software outright (at least for internet-connected devices) and become fluent in programming languages to determine good from evil?
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- MereInterest 4y agoYou're describing things that are legal requirements and legal duties. The parent is arguing that there is a moral requirement and a moral duty to uphold.
- capableweb 4y agoThose "moral requirements & duties" usually go into a "Code of Conduct" or "Contributor Guidelines" instead of in the license of the project, as they are separate from the distribution, usage and modification of the code. And rightly so. The community seems to constantly mix "open source" the distribution model with the "open/community" development model that some projects adhere to. We would all be better off by being more precise with what words we use to describe all of these things, and what our expectations are. Just like what Hickey did here.
- matheusmoreira 4y agoThose are all nice things to do when managing a project but they are definitely not obligations. Some of us open source developers don't even work as professional software developers. I for one reserve the right to simply abandon a project once I decide it's served its purpose. I often start projects to make tools for my own personal use, to learn something by trying to reinvent a better wheel or just to prove to myself that I'm not insane for imagining different ways to do things. Fear of inadvertently creating responsibility for myself, such as responsibility to polish, maintain or even finish projects, has led me to not actually publish lots of software I've written. One such project actually made it to HN once. It's really nice when other people see your project, I'm happy even with criticism because it means I can learn something. However, I really don't want this to turn into an unpaid duty. I try to do things properly when I'm programming but at the same time I have increasingly limited free time and attention. For example, I wrote a user space driver for my laptop's keyboard LEDs: https://github.com/matheusmoreira/ite-829x https://github.com/matheusmoreira/ite-829x I just wanted to turn them off because they default to bright blue lights. Then I thought it'd be interesting to add some application-specific color schemes. While reverse engineering it, I discovered some insane functionality. The Windows driver would intercept all keystrokes and send signals to the keyboard to light up the keys when they're pressed. Why not do it in hardware? I started documenting those features but it was just so insane I decided it was better to just stop. I really don't want to feel pressured to finish that, especially since I'm not going to use it. Then it turned out I actually had users, and one person created an issue asking for help with the somewhat cryptic user interface I came up with. I realized in horror the issue was created months ago and I didn't even see it. I tried to help as much as I could but still.
- CuriousSkeptic 4y agoI recognise myself so much in this post. > I realized in horror the issue was created months ago and I didn't even see it. I even had one issue opened for three years before I found my self with some extra time for the project. Was quite surprised, but delighted, when the submitter responded with a thank you, and “worth the wait” just minutes after resolving it. I guess what I’m saying is, don’t let the pressure take you down to much. Most people are probably both patient and grateful.