What do you know, it turns out the professional software developers I work with are actually scientists and academics!!
It's not about computers and "You don't put science on your name if you're a real science"
He prefers the name informatics.
Having flashbacks to when a close friend was getting an MS in Political Science, and spent the first semester in a class devoted to whether or not political science is a science.
I've yet to find a classification I really like but this is an interesting take. I still tend to like CIS (Computing and Information Sciences). The problem with CS is it focuses on computation and puts state as second class. The problem with IS is it focuses on state and puts computing as second class. To me, both are equally important.
I have studied informatics, but don't call myself an informatic, because I am not doing any research.
I call myself a programmer, because I am not doing engineering either.
"Computer science is no more about computers than astronomy is about telescopes." - Edsger W. Dijkstra [0], [1].
This also lead to a strange naming now we have data science as well where it is called "Data videnskab" which is just a literal translation of the English term.
[0]: https://dl.acm.org/doi/10.1145/365719.366510 (sadly behind a wall)
Computerwissenschaften (literally computer science) exists, too, but it's the less common word.
Perhaps because no one had any idea about how it would be pronounced?
The average software developer doesn't even know much math.
Right now, "software engineer" basically means "has a computer, -perhaps- knows a little bit about what goes on under the hood".
Well, I know stupid amounts of math compared to the average developer I've encountered, since I studied math in grad school. Other than basic graph traversal, I only remember one or two times I've gotten to actually use much of it.
There isn't a standard license that show that someone is proficient in security, or accessibility, or even in how computer hardware or networking work at a basic level.
So all we're doing is diluting the term "engineer", so as to not mean anything.
The only thing the term "software engineer" practically means is: they have a computer. It's meaningless, just a vanity title meant to sound better than "developer".
Readable code is often simple code, as well. This also has practical benefits. Kernighan's law[0] states:
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
Dijkstra says it this way:
> The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.[1]
Knuth has a well-documented preference for "re-editable" code over reusable code. Being "re-editable" implies that the code must be readable and understandable (i.e. communicate its intention well to any future editors), if not simple.
I know that I have sometimes had difficulty debugging overly clever code. I am not inclined to disagree with the giants on this one.
---
[0]: https://www.defprogramming.com/q/188353f216dd/
[1]: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/E...
I believe they are referring to what the degree currently known as Computer Science should be called.
Incidentally, I don't think I know any SWEs who actually majored in software engineering. I know one who didn't even bother to graduate high school and therefore has no academic credential whatsoever, a couple of music majors, a few math majors, and a lot of "computer science" majors, but I can't think of anyone who actually got a "software engineering" bachelor's degree. Hell, I even know one guy with a JD. I think I know 1 or 2 who have master's degrees in "software engineering," but that's it.
I am not a lawyer, just a hardcore open-source advocate in a former life.
> 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.
From a non-academic's point of view I might include a brief disclaimer in the README too, explaining the context for the code and why it's in the state it's in, but there's no obligation to hold the user's hand. To be frank, anybody nitpicking or criticizing code released under these circumstances with the expectation that the author do something about it can go fuck themselves.
Competitive advantage, on the other hand, is a perfectly valid reason to hold code back. There may also be some cost in academia to opening an attack surface for any sort of criticism, even irrelevant criticism made in obvious bad faith. Based on what I've heard about academia, this wouldn't surprise me.
It is explicitly the point of the license that the code is not for those purposes, because it's shitty code that should not be reused in any real code base.
More often than not, they are more than willing to help.
That's not theoretical; I know many people who were or would be embarrassed to ask.
Explicitly posting things is helpful.
I would expect that anyone wanting to actually publish their code should publish the code with a "proper" license after the reviewing process is done and the relevant paper is published.
Indeed, also there're things like "By reading this sentence, You have agreed to the terms and conditions of this License.". That can't hold up in court! How can I know in advance what the rest of the conditions say before agreeing to them?
Then again, I am not a lawyer either.
Certainly don't clean it up unless you're going to repeat the experiment with the cleaned up code.
And, yeah. I've found some significant mistakes in research code -- authors have always been grateful that I saved them from the public embarrassment.
Supplying bad code is a lot more valuable than supplying no code.
Also in my experience, reviewers won't actually review your code, even though they like it a lot when you supply it.
https://matt.might.net/articles/crapl/
> I'm not a lawyer, so I doubt I've written the CRAPL in such a way that it would hold up well in court.
Please do release your code, but please use a standard open source license. As for which one, look to what your peers use.
Using this license would actually make me suspect that your results aren't even valid and I don't trust many experiments that don't release source code.
You cannot change the past, but as a copyright holder, you can always set a new license for future releases.
Thus, OP, if you're uncertain, I definitely was when I started out, go with a restrive license as recommended here (GPL). That, together with publishing the code online (e.g. GitHub, Gitlab, ...) as well as a with your article, will give you some protection against plagiarism. Anyone who use include parts of your code for their research code, will have to share theirs code the same. If you later on feel like you want to relax the license, you can always change it to, say, MIT.
If only to help people who simply can't read academic papers because it's not a language their brain is wired to parse, but who can read code and will understand your ideas via that medium.
[EDIT]: to go further, I have - more than once - run research code under a debugger (or printf-instrumented it, whichever) to finally be able to get an actual intuitive grasp of the idea presented in the paper.
Once you stare at the actual variables while the code runs, my experience is it speaks to you in a way no equation ever will.
Use standard and well understood licenses e.g. GPL for code and CC for documentation. The world does not need more license fragmentation.
Eg:
You are permitted to use the Program to validate scientific claims
submitted for peer review, under the condition that You keep
modifications to the Program confidential until those claims have
been published.
In this particular case, however, there's very little risk of actual law suits happening. There is some, but the real goal of the license is not to protect anyone's ass in court (except for the obvious "no warranty" part at the end), but to clearly communicate intent. Don't forget that this is something GPL and MIT also do besides their obvious "will likely stand up in court" qualities. In fact I think that communicating intent is the key goal of GPL and MIT, and also the key goal of CRAPL.
From this perspective, IMO the only problem in this license is
By reading this sentence, You have agreed to the terms and
conditions of this License.
Again, this is not how a license work. You can express your intents, ideas and desires in a README file and in many other ways.
The license is nothing more than a contract that provides rights to the recipient under certain conditions. Standing up in court is its real power and only purpose.
That's why we should prefer licenses that stood up in court and have been written by lawyers rather than developers or scientists.
Plenty of contracts aren't even written down. When you buy a loaf of bread at the bakery, you make an oral contract about that transaction.
The idea that contracts, or licenses, need to be written in dull legalese and be pretty much impenetrable to be useful or "valid" or whatever, is absolutely bonkers. Lawyers like you to think that but it's not true. It's an urban legend.
If you need to make sure that you can defend your rights in court, then sure, you're probably going to need some legalese (but even then there's little harm in also including some intent - it's just not very common). Clearly that's not the goal here. No scientist is gonna sue another scientist who asked for support and got angry about not getting any even though the code was CRAPL licensed.
That's a well known fact. And it's besides the point.
> Lawyers like you to think that but it's not true.
Is that a conspiracy theory? Writing long, detailed contracts on a persistent medium is safer: it lowers the risk of he-said-she-said scenarios and ambiguities.
That is meant to save you tons of legal expenses.
> No scientist is gonna sue another scientist
Then there is no need for such license in the first place. Just a readme file.
Incidentally, I've seen people violate the Java "no realtime" clause.
Plus, the usual "no warranty" is strong enough to protect the authors anyways.
You must be fun at parties :)
The only thing I would add is a description of the build environment and an example of how to use it.
4) You recognize that any request for support for the Program will be discarded with extreme prejudice.
I think that should be a "may" rather than a "will." If I find out someone is using my obscure academic code, and they ask for help, I'd be pretty pumped to help them (on easy requests at least).
> 4) You recognize that any request for support for the Program will be discarded with extreme prejudice.
There is no way I'd even make a request for support.
Why does he think that but presumably not the same about the paper itself and the “equations”, plots, etc. contained within?
It’s really not that hard to write pretty good code for prototypes. In fact, I can only assume that he and other professors never allowed or encouraged “proof of concept” code to be submitted as course homework or projects.
Moreover you are not being paid for writing reasonable programs you're paid for doing science. Nobody would submit "prototype" papers, because they are the currency of academic work. There is lots of time spend on polishing a paper before submission, but doing that for code is generally not appreciated because nobody will see this on your CV.
If code is a large part of your scientific work, then it's just as important as someone who does optics keeping their optics table organized and designed well. If one is embarrassed by that, then too bad. Embarrassment is how we learn.
Lastly, you're describing problems with the academic world as if they are excuses. They're reasons but most people know the academic world is not perfect, especially with what is prioritized and essentially gamified.
I'm actually a strong supporter of open science, release my code OSS (and actually clean it up) and data (when possible). But just saying it's easy and there is no cost, is just setting the wrong expectations. Generally unless you enjoy it, spending significant time on your code is not smart for your career. Hopefully things are changing, but it is a slow process.
Funny that you talk about optics I know some of the most productive people in my field and their optical tables are an absolute mess (as is their code btw). They don't work at universities though.
I understand the realities and have even been a part of PowerPoint development where slides are emailed back and forth. Sometimes one just has to go with things like that. But I have also seen the reality of stubbornness. I have tried introducing source code control to scientists or even stuff like wikis, all supported and already up and running by IT and used by other groups. Scientists and engineers, especially those with PhDs, can a bit rejective and set in their ways. I have been told flat out by different people that they wouldn’t use tools like a wiki or that Python and C was all they ever needed. I have even noticed physicists saying “codes” for software instead of “code”. It’s fairly rampant, and I have seen it in research papers, published books, and in industry in person. I have never seen that use of “codes” anywhere else. That alone is evidence of a certain amount of culture and institutionalization of doing things incorrectly but viewed as acceptable within the field.
I have written code in some research contexts. I get the constraints. One just needs to take it seriously. But organization, in general, often takes a back seat in basically any field. The only way to change things like this are like anything, which is to push against culture.
If you want to set expectations, this can simply be done in a README. Putting this in a license makes no sense. Copyright licenses grant exceptions to copyright law. If you're adding something else to it, you're muddying the water, not making it better.
FWIW I basically did this: My thesis numbers were run on a branch based on the unstable version of an upstream project that was going through a major refactoring. I took a tarball of the VCS tree at that point in time and posted it online. Over the years 3-4 people have asked for the tarball; nobody has ever come back to me with any more questions. I can only assume they gave up trying to make it work in despair.
I think I tried to build it a couple of years ago, and it wouldn't even build because gcc has gotten a lot more strict than it used to be (and the upstream project has -Werror, so any warnings break the compilation).
I think it's definitely worth doing, but I think you need to be realistic about how much impact that kind of "publishing" is really going to have.
> "Generally, academic software is stapled together on a tight deadline; an expert user has to coerce it into running; and it's not pretty code. Academic code is about 'proof of concept.'"
This is brilliant!
edit: it seems that, aside from that great snippet from the text, the license itself isn't so great. another comment [1] has a great analysis of the actual license and suggests using a superior solution (copying the preamble part yet still using MIT/(A)GPL).
relevant section from MIT license:
"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."
Matt Might has a solution for this that I love: Don't clean & organize! Release it under the CRAPL[0], making explicit what everyone understands, viz.:
"Generally, academic software is stapled together on a tight deadline; an expert user has to coerce it into running; and it's not pretty code. Academic code is about 'proof of concept.'"
[0] https://matt.might.net/articles/crapl/