The conversation

matheusmoreiraHNSource author
Lessons learnedExperience excerpt · English

Free software licenses say the user gets the source code

… Free software licenses say the user gets the source code. They're about empowering the user , in this case me , with the ability use and modify the software as I see fit. If I customize something for my personal use, then I'm the only user of the fork and license terms are fulfilled. People would only get to demand source code from me if I started distributing compiled executables to other users. > You've got no need to campaign for the solutions if they get rejected. I used to feel that need. Caused me significant anxiety. I thought upstreaming patches was the Right Thing to do. Mercifully I've been cured of this misconception. > There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there. I have no problem with that. My point is getting involved with upstream is often more trouble than it's worth. Let them do their thing. Just pull from them and rebase your changes. Enjoy life. People should think twice before trying to cram their unsolicited code down other people's throats. …

Original discussion15,000 lines of verified cryptography now in Python158 source comments · at import
2

What was this responding to?

Parent context · original excerpt

KA
kamray23HN

Eh, most of the time you do have to publish it. MIT/BSD/Apache allows you not to, but most big projects are using LGPL or another share-alike license. With those, if you're making a project that you do publish (e.g. a commercial product that uses that library/language/etc.) you do kinda legally have to share that modified source code. It's of course different if you're scripting for your own sake, but the moment you publish anything using them you also have to publish your modified versions of libraries and other stuff. I do agree with the "fork and make it better for you", but I also think it's common courtesy to throw up issues for the bugs or missing features you encounter, as well as pull requests. If for no other reason then as "prototypes" or "quick fixes" that others can cherry-pick into their own forks. They may get rejected, they may get closed, but you still don't have to sit t…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 2

Direct replies available in this import. Original-language excerpts.

KA
kant2002HN

Usually better start with small scale fixing typos and improving docs. That’s great canary for me. If it’s accepted within day or so, that’s project which I willing to learn. I would say you can select projects for your value and you would be fine contributing there. Eventually people will learn you and will trust you more

Full original
KA
kamray23HN

That is exactly why I said that that only comes in once you publish something. The legal argument isn't as strong as the moral one is for me anyway, I never publish anything. I think making a PR isn't forcing code on someone, they're not obligated by anything to read and consider it, but if they do want to they can. I'll make one, and then I'll stop responding, because that's where my personal moral obligation ends. Whoever wants the code can now easily discover it, whoever doesn't can throw it away as they like. Including the upstream maintainer.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.