IMO software licensing and patent litigations, all this nonsense of patenting a concept or workflow or some stupid idea someone had, hampers society tremendously.
David Beazley did an amazing and entertaining talk about software licensing litigations and what kind of things happen during this process: https://www.youtube.com/watch?v=RZ4Sn-Y7AP8
When I write any code, I take 2 options: 1) Don't share it publicly or 2) Completely release it as public domain. No need for MIT license or any of that crap. Here, just take the code and go win the world, I don't need any credit. Ask yourself how you've benefited from someone crediting you if at all it comes back to you. The world is a large place and just let it go. I am gonna die in 40 years and whatever I do will be totally irrelevant - if my name appears in COPYRIGHT 2020 MR. FERMI ENRICO. YOU MUST CREDIT ME. in some notice that a lawyer with thick glasses is scanning through after I am dead. What an amazing legacy that I am leaving behind.
Furthermore, we need have some respect for people that want to keep code private. Not everyone is interested in open sourcing their work - but somehow that's looked down upon. Why!? It is their work and respect it, there are so many people with pitch fork entitlement. Closed source is OK. They deserve it and hope they can be financially rewarded for the hard work. I see the open-source ecosystem as a double sword edge - we got some cool stuff out of it and everyone shares that base to build off of. But then there is also socialism of code - no one wants to improve it because its not their job, then the open source volunteers are blamed for the quality of their library where these guys are just doing it for fun in their free time - literally no right to get angry at them. Now, everyone is sharing the same shitty unmaintainable library 8 layers deep in their package.json file. The devs are overloaded, issues are piling up on Github and the dude in Shenzhen has already finished the project and his gadget is in prod.
We gotta be more agile lol.
The pitchfork entitlement, to my observation, is reactionary to the force of law backing something that should be an individual's responsibility if they want to keep it secret but not supported by the threat of government-sanctioned violence.
Contrast another industry where secrecy is key. A magician never reveals their secrets, and there's material value in being able to pull off a trick that nobody else can. But what's the ramification if somebody figures a trick out and publishes it? It certainly isn't a crime. The worst of person might face is sanction from a magician's guild.
Given that we have a world where somebody can be sued for taking apart a physical artifact that they own and discovering secrets of its implementation, sharing those secrets, and modifying the thing based on knowledge of those secrets, the pitchforks are somewhat understandable.
Often times reverse engineering is harder than building the damn thing in the first place.
Um, actually it can be. Many magic tricks can be both copyrighted and patented.
https://www.hollywoodreporter.com/thr-esq/teller-wins-lawsui...
I had a similar philosophy in my youth, and it still resonates with me. Hanging around Slashdot and doing oss development, I learned enough about IP law to understand that it's not as simple as we'd like.
There's actually a risk that your unlicensed code will be picked up by somebody in a jurisdiction with different IP laws than you're familiar with. They can copyright the code (did you say "free for any use or modification?), and issue C&D to anybody hosting your code online. You could find yourself in a very awkward position where you published it first but they've done so in a legally defensible manner. CC0 and MIT are prudent licenses -- not to ensure that you get credit, but to cover your own ass.
And that's good! Consistency is a very valuable quality of large codebases worked on by many engineers.
If I want to figure out how to write a unit test for a service call, find an existing example of that pattern and copy that. Resist the temptation to invent a new, very slightly better way of doing that.
There's a big corollary to this: if you find yourself doing something for the very first time in that particular codebase, take the time to do it well. Because everyone else will be copying your code for the future lifetime of the project.
I’ve felt that there is a potentially a role missing here: a kind of free-floating code librarian who is not attached to any particular team and could be called upon to perform basic research of existing patterns. Part of this role could be to maintain the kind of newbie-friendly documentation that tends to fall between the gaps of tool/infra/product teams. Maybe the job title could be “software informatician”.
I'm on board with this idea, as long as I don't have to learn Dewey Decimal Classification.
This article just wants to sound edgy.
> To steal, however, is to make that idea your own. Taking credit for someone else’s idea is borrowing; understanding an idea and weaving it into your own work, that’s what he meant by theft.
I have a rule, though: I never add code, unless I understand it 100%, and I often make tweaks to adjust it to my immediate needs.
One of my best thefts was a simple FIFO queue, from this book: https://www.objc.io/books/advanced-swift/
This is my adaptation: https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...
I really had to do almost nothing to improve it. I think I just extended its utility a bit.
Of course, these weren't your usual SO "academic sample" dudes.
```
# From https://stackoverflow.com/a/246128
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
```
So many sysadmins have rudimentary skills and simply copy what works.
I have seen some folks with huge repos of code snippets like that
DIR=$(dirname $(readlink -f $0))
I started using the longer one, and then I gave up on shell scripting on OS X for other reasons, and didn't go back. So yeah there is a lot of random cargo culting.
In Oil I hope to provide an even simpler method that's built in (and it also has readlink builtin to support this)
> A borrowed object still belongs to someone else; you copy a style and it still belongs to someone else. To steal, however, is to make that idea your own. Taking credit for someone else’s idea is borrowing; understanding an idea and weaving it into your own work, that’s what he meant by theft.
So the point is when you 'lift' some code from somewhere and use it, use it fully, own it, have mastery of it. Only then have you 'stolen' it and become yours.
https://www.vice.com/en_us/article/qj4pzd/how-we-assign-cred...
For me it just comes down to the license, I’d probably credit an artist for their work if I used it in a game but if the license doesn’t say that then there’s no onus to right?
If I like the stuff enough to use it in my project then The creator deserves some recognition, is there a reason not to?
I seem to prefer the former.
I think I can maybe count on 1 hand the times I've literally copied/pasted and left it as is. Usually it's copying some config file for a laravel package or something because there were some changes and I'm combining them on an upgrade or something.
It is important -- vital even -- to know how to find the right code, how to understand and test it, how to modify it.
And not just from stack overflow, but also from colleagues and even yourself.
If this were real, I would buy it.