I don't know if you're "wrong", but I do feel differently about this.
I've written a ton of open source code and I never cared what people do with it, both "good" or "bad". I only want my code to be "useful". Not just to the people I agree with, but to anyone who needs to use a computer.
Of course, I'd rather people use my code to feed the poor than build weapons, but it's just a preference. My conviction is that my code is _freed_ from me and my individual preferences and shared for everyone to use.
I don't think my code is "stolen", if someone uses it to make themselves rich.
And in that case, use MIT license or something like that for your code, and all is good. If I use AGPL, on the other hand, AI companies should not be allowed to train on that and then use the result of that training while ignoring the license.
> Not just to the people I agree with, but to anyone who needs to use a computer.
Why not say "... but to the people I disagree with"?
Would you be OK knowing your code is used to cause more harm than good? Would you still continue working on a hypothetical OSS which had no users, other than, say, a totalitarian government in the middle east which executes homosexuals? Would you be OK with your software being a critical directly involved piece of code for example tracking, de-anonymizing and profiling them?
As for me that's a risk I'm willing to accept in return for the freedom of the code.
I'm not going to deliberately write code that's LIKELY to do more harm than good, but crippling the potential positive impact just because of some largely hypothetical risk? That feels almost selfish, what would I really be trying to avoid, personally running into a feel-bad outcome?
I think it would be most interesting to find ways to restrict bad usage without crippling the positive impact.
Douglas Crockford[0] tried this with JSON. Now, strictly speaking, this does not satisfy the definition of Open Source (it merely is open source, lowercase). But after 10 years of working on Open Source, I came to the conclusion that Open Source is not the absolute social good we delude ourselves into thinking.
Sure, it's usually better than closed source because the freedoms mean people tend to have more control and it's harder for anyone (including large corporations) to restrict those freedoms. But I think it's a local optimum and we should start looking into better alternatives.
Android, for example, is nominally Open Source but in reality the source is only published by google periodically[1], making any true cooperation between the paid devs and the community difficult. And good luck getting this to actually run on a physical device without giving up things like Google Play or banking apps or your warranty.
There's always ways to fuck people over and there always will be but we should look into further ways to limit and reduce them.
> Open Source is not the absolute social good we delude ourselves into thinking.
Historically the term "Open Source" was specifically developed to divorce the movement from the "social good" ideas that were promoted by Free Software.
That's where I stand. I don't do Open Source to make the world better. I do Open Source because I believe that makes my software better.
I'm not an activist. I'm an engineer. Nothing wrong with activism, all the power to the people doing it, but the licensing I chose for my code doesn't take it into account.
I agree with the GP. While I wouldn’t be happy about such uses, I see the use as detached from the software as-is, given (assuming) that it isn’t purpose-built for the bad uses. If the software is only being used for nefarious purposes, then clearly you have built the wrong thing, not applied the wrong license. The totalitarian government wouldn’t care about your license anyway.
The one thing I do care about is attribution — though maybe actually not in the nefarious cases.
> The totalitarian government wouldn’t care about your license anyway.
I see this a lot and while being technically correct, I think it ignores the costs for them.
In practice such a government doesn't need to have laws and courts either but usually does because the appearance of justice.
Breaking international laws such as copyright also has costs for them. Nobody will probably care about one small project but large scale violations could (or at least should) lead to sanctions.
Similarly, if they want to offer their product in other countries, now they run the risk of having to pay fines.
Finally, see my sibling comment but a lot of people act like Open Source is an absolute good just because it's Open Source. By being explicit about our views about right and wrong, we draw attention to this delusion.
It’s fine to use whatever license you think is right. That includes the choice of using a permissive license. Restrictions are generally an impediment for adoption, due to their legal risk, even for morally immaculate users. I think that not placing usage restrictions on open source is just as natural as not placing usage restrictions on published research papers.
Tragedy of the commons. If all software had (compatible) clauses about permitted usage, then the choice would be to rewrite it inhouse or accept the restrictions. When there are alternatives (copyleft or permissive) which are not significantly worse, those will get used instead, even if taken in isolation, the restricted software was a bigger social good.
If you think you'll ever want to use third-party tools to process that markup, or if some of your private files will transform into public files at some point, then yes, considering popularity makes a lot of sense.
If they're just text files you edit raw that will never interact with anything else but your text editor, then of course popularity doesn't matter at all. But in my experience, my use cases tend to expand over time.
The article even talks about org mode's interoperability, mainly about the fact that pandoc supports it. And then bizarrely ignores the fact that it has much less ecosystem support than Markdown. So this is very much a subject the article itself brings up, and something that therefore also deserves to be critiqued.
OP here. I stuck with orgmode all these years /because/ of the interoperability.
If I'm writing in Org, I can tangle / detangle between other plaintext sources, including source code. As well as export to collaborate.
The proposition is "yes, and", not "either / or".
It's /fine/ to switch to the popular "team" standard and stay there when needed. Several of my workplace documents, including wiki entries start off as local org-mode drafts. Once I'm okay to share, I export to markdown or draft wiki page and solicit comments. After that, if the document is for shared maintenance, I let my org-text alone, and switch to the "team" format.
This is perfectly fine.
That and the many kinds of markdown. I've been bitten enough by having to look up yet another poorly maintained document on how to markdown for /this/ particular app or website or utility, that I'd rather pandoc translate between my (sane, well documented, fully extensible) org text and whatever I need to share with others, than learn edge cases of various markdowns.
Sure, but I think it's safe to say Markdown has more interoperability, no?
Yes you can always use pandoc, but conversion usually brings quirks of its own. And more generally, the less conversion steps you need, the better.
If you just stick to vanilla markup, you don't encounter incompatibilities. The "many kinds of markdown" isn't an issue if you're not using platform-specific extensions in the first place. Which, usually, you're not, unless you need to do something very specific to that application.
Yes, more interoperability at the cost of capability.
Also, yes, conversion is quirky. That is why Org works until it does, and then I trade off being stymied by markdown's more plain-ness, in favour of collaborating with others.
And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak" (like, front-matter or table of contents or footnotes or some such thing), and everyone ends up doing their own thing.
Perhaps the trouble with markdown is it's /too/ plain. So yes, lots of people can do lots of lowest common denominator stuff, but it does not extend to individuals wanting "just one thing" which also adds up to a lot of people.
Edit: a real-life example... I typically run code from org-mode for interactive testing and debugging --- the kind of stuff we write small throwaway scripts for.
In this one project, I made it so that /I/ or anyone else using org-mode could do it from org, for local development, and anyone else could just use the script as-is... including the CI pipeline.
> Yes, more interoperability at the cost of capability.
Well, then why aren't you using LaTeX? Isn't that more capable?
> And with vanilla markup, the trouble is that many applications /do not/ use just vanilla markup. People /invariably/ want "one key tweak"
And, that's going to be true as someone adopts it outside of Emacs, right?
Surely, someone will decide that the way Org Mode is doing something is wrong, right? They're going to do something like say, "Hey, why don't we permit Markdown style headings, too?" or something similar.
Or are you suggesting Org Mode military police? Felony markup possession?
There's nothing special about Org Mode that makes it immune to the problems you're describing. They will happen immediately upon wider adoption.
And if you somehow do stop it, well, it's tech. If you don't have a patent on it then someone will fork the idea and you'd have Borg Mode directly competing with you anyways.
A Unix novice came to Master Foo and said: “I am confused. Is it not the Unix way that every program should concentrate on one thing and do it well?”
Master Foo nodded.
The novice continued: “Isn't it also the Unix way that the wheel should not be reinvented?”
Master Foo nodded again.
“Why, then, are there several tools with similar capabilities in text processing: sed, awk and Perl? With which one can I best practice the Unix way?”
Master Foo asked the novice: “If you have a text file, what tool would you use to produce a copy with a few words in it replaced by strings of your choosing?”
The novice frowned and said: “Perl's regexps would be excessive for so simple a task. I do not know awk, and I have been writing sed scripts in the last few weeks. As I have some experience with sed, at the moment I would prefer it. But if the job only needed to be done once rather than repeatedly, a text editor would suffice.”
Master Foo nodded and replied: “When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep.”
Okay. You didn't seem to understand that that was a rhetorical question, because you didn't seem to take the next step of reflection.
So, what does your comment to me say if used in response to your own org mode vs markdown comment you made in the post I responded to? You said org mode's capabilities are the reason why you don't want markdown.
You keep making this argument that org mode is just better, but you can immediately find a counterargument yourself to your own point.
Now, it's perfectly fine that that represents how you feel about the software. You can hold whatever opinion you want. But, you're not just trying to explain your opinion. You're trying to convince people that org mode is better. You understand why you're not being very persuasive in your argument, right? You've argued in a way that the only people who will agree with you are those that already hold the same opinion as you.
Org mode's capabilities are the reason why I don't want markdown for me.
Markdown's popularity is the reason why I switch to it for other people (team / colleagues).
LaTeX is too much for day to day use. Its purpose is precision typesetting. That is a lot of work with LaTeX. I don't need to do precision typesetting on a day-to-day basis. But I've used it to format documents for people when they ask me to. Then it's worth the pain. Besides, LaTeX has none of the organisational capabilities enabled by orgmode, for my daily-drive uses.
There is a reason a Physicist---who daily-drives LaTeX, for their publishing work---went through all the trouble to build a note taking system from scratch.
So, once again, utility is contextual, and I refer back to Master Foo's lesson every time I have a problem.
Ahem. When I started with Markdown, I was regularly experiencing all the issues mentioned for years. The most popular format was Word (doc). Perhaps I should have stuck with that?
No? I’m pushing back against advocacy for broader adoption of org mode beyond personal file markup though, which is what I feel like this piece is arguing.
> note that this is not about Emacs at all. This is about Org mode syntax and its advantages even when used outside of Emacs.
One of the advantages of "going with the flow" when you can is that you benefit from numbers. You're a market of one, but by "going with the flow" the total market is huge.
Even if for me personally 185V mains power would be better, I can't buy gear for 185V, none of the electricians around here know how to work with it, the cables and sockets and everything else are defined around the prevailing systems at 220-250V here.
Maybe in my kitchen a 520mm dishwasher would be great, but alas dishwashers you can buy here are 600mm or 450mm ("slimeline") models, so 520mm isn't available.
With my poor hearing 14-bit PCM would be absolutely fine, but Sony's "Compact Disc" used 16-bit so that's what everybody uses and records by default.
If you work with Markdown, there are a lot of existing tools which are ready to use. There are tools for Org Mode, but maybe not as many.
There's definitely a sliding scale here. Refusing to use Twitter because it's full of Nazis is very different from refusing to conform to society's expectation that you wear clothes outside for example. There are people willing to spend most of their lives in jail because they refuse to wear clothes but almost all of us don't think that's a principle we care about enough to prioritise (also some of us get cold).
I think this is moving the goal post. Cloudflare isn't challenging the need to restrict access to some websites, it is challenging who has the right to decide. Quoting the tweet:
> We believe Italy, like all countries, has a right to regulate the content on networks inside its borders. But they must do so following the Rule of Law and principles of Due Process.
I live in Italy, I'm a citizen. I don't feel any safer having the internet regulated by a bunch of bureaucrats than I do state actors and bots.
Bureaucrats are a problem, but they're eventually accountable to the people. Companies are accountable to shareholders located in another country, who don't give a damn about whatever so long as the money keeps coming. I choose bureaucrats against businessmen anytime.
What he's saying is that the grandparent (top-rated as of this writing) comment claiming that agribusinesses are hiding the benefits of "community gardens, local food, farmers markets, grass fed, free range..." because they don't make money off of them is unfounded.
I personally don't have any insight into the situation and I definitely don't want to defend big businesses, I'm just explaining what you're replying to.
You're not wrong, however the issue is that it's not always easy to detect if a PR includes proof that the change works. It requires that the reviewer interrupts what they're doing, switch context completely and look at the PR.
If you consider that reviewer bandwidth is very limited in most projects AND that the volume of low-effort-AI-assisted PR has grown incredibly over the past year, now we have a spam problem.
Some of my engineers refuse to review a patch if they detect that it's AI-assisted. They're wrong, but I understand their pain.
I don't think we're talking about merely "AI-assisted" PRs here. We're talking about PRs where the submitter has not read the code, doesn't understand it, and can't be bothered to describe what they did and why.
As a reviewer with limited bandwidth, I really don't see why I should spend any effort on those.
"We're talking about PRs where the submitter has not read the code, doesn't understand it, and can't be bothered to describe what they did and why."
IME, "AI" PRs are categorically that kind of PR. I find, and others around me in my org have agreed, that if you actually do all that you describe, the actual net time savings of AI are often (for a mid-level dev or above) either net 0 or negative.
I personally have used the phrase "baptized the AI out of it" describing my own PRs... Where I may have initially used AI to generate a bunch of the code, looked at it and went "huh neat that actually looks pretty right, this is almost done." Then I generate unit tests. Then I fix the unit tests to not be shit. Then i find bugs in the AI-generated code. Then upon pondering the code a bit, or maybe while fixing the bugs, I find the abstractions it created are clunky, so I refactor it a bit... and by the time I'm done there's not a lot of AI left in the PR, it's all me.
I am genuinely interested: everybody here says that they removed the copyright headers. But when I browse through the Spegel sources, they do not contain a copyright header...
To me it's the Spegel author's fault: there should be a copyright header in every single file, such that Microsoft would have to keep it.
It's in the LICENSE file. With a MIT license, you assign a copyright to the project, or to a certain set of files. The Spegel license attributes copyright to "the Spegel authors", while Peerd attributes it to "Microsoft Corporation".
If some of the peerd code was lifted from Spegel, it's blatant stealing. Code attribution is the only thing a MIT license asks people to honor, and Microsoft couldn't even do that.
Can’t help but feel no matter what they’d done there would be some route of thought that leads them to wronging the author other than just paying and using the code as is. I don’t know why a corporation would do that though as they likely have their own changes and direction they want for it and working with an unknown 3rd party on that could be a nightmare.
From the authors reaction they chose the wrong license for the project.
> If some of the peerd code was lifted from Spegel, it's blatant stealing.
Could we say "it's incorrect attribution"?
> and Microsoft couldn't even do that.
Did you consider it may have been done by an engineer who, in good faith, thought they were giving proper credit by adding it to the README? Would you want that engineer fired because of the bad attribution?
It's not like Microsoft is making millions out of this. Sure, they should fix the attribution. It's a mistake.
Most startups/small companies I've seen rely heavily on open source and fail to honour every single licence. This is bad and nobody cares. Here, Microsoft mentioned the project in the README (which is not enough, but not nothing), and I'm pretty sure that they can fix it if someone opens an issue. But overall, companies like Microsoft do honour licences a lot better than startups in my experience.
BigTech is evil for many reasons, but maybe we could consider that this is just an honest mistake.
Of course it was a mistake. In fact, as of 20 minutes ago, the mistake appears to be sorted out, with both the main license file and the offending files sporting new copyright headers.
But corporations hiding behind their workers is a no-go. Corporations get to enjoy their successes, and it's fair to hold them accountable for their failures. Least Microsoft can do is a bit of public comms work detailing what they will do to ensure these mistakes are not repeated in the future.
Microsoft does credit the authors on their README. Maybe it's not exactly the right way to do it, but they do it.
Now if it's not the right way to do it, what about opening a PR and asking to change it? Instead of writing a blog post to complain about them?
Now maybe those engineers thought they did well, will get issues internally because of the bad publicity for Microsoft, and next time they want to use an open source project their legal department will be even more of a pain in the ass because if they aren't, then random people on the Internet use that to do bad publicity for the company.
Why not assuming that they are in good faith here? There are enough reasons to hate Microsoft other than this one.
The question is who does the copyright belong to in this repository. It is both original author and Microsoft (because they took authors code and modified it). So the License file should mention both.
I am not convinced that the main LICENSE file should mention both. I feel like somewhere, in the project, there should be a copy of the original license.
When you depend on a third-party, you don't add their copyright in your main LICENSE file.
In case of deps, the dependency comes with its own LICENSE file.
In this case the code is essentially forked, integrated and intermingled, so that is why it should be in the LICENSE file.
If it was file or two, it would be fine to add a comment pointing to the license file in the repo, if it was a directory, or to copy it verbatim to that file. It all the copied code was in a directory then having it in directory would be fine.
In this case it looks like they took the original code and heavily modified it, so the simplest way to solve it is one LICENSE with both notices.
I don't read anything suggesting that in the MIT licence. I don't see why they couldn't say "the fork came with its own LICENSE file, which we moved in this subfolder, and now the root LICENSE file is the one of our new project".
The question is, "If I look at this repo, who owns the copyright?"
Sure, you could move the original LICENSE into a directory. Still, if the files are intermingled, you should have a prominent notice that says, " Hey, these files have mixed copyright ownership."
TAS: Tool-Assisted-Speedrun. A kind of speedrunning, where control inputs aren't given by humans, but are carefully pre-programmed into a bot that will replay them. This allows to do things that would otherwise be veeeeery difficult (and sometimes impossible) for humans.
GDQ: Games Done Quick, the name of the Youtube channel.
OoT: Ocarina of Time, a beloved Zelda game from the 90s.
ACE: Arbitrary Code Execution. A vulnerability that lets you run whatever you want. You can use it to skip huge parts of the game, therefore achieving the fast speedrun
You get better at it the more you do it, and naturally with experience you'll notice it takes less and less time.
That being said, I agree with you, it does take a lot of time. To me, the switch occurred when I stopped considering this time "wasted" and instead consider it fulfilling. I actively look for the time I'll spend cooking each day, I believe it's a good use of my time and I don't try to rush through it.
> To me, the switch occurred when I stopped considering this time "wasted" and instead consider it fulfilling.
This is how it works for me also. We involved our children from a very early age, so they can also perform basic tasks like watch a pan or cut soft things into pieces (with only a little supervision), which frees up even more time.
- Using butter for pasta is something that is typically reserved for people with upset stomach (understand diarrhea). It's not scientific at all, but just something that is commonly done.
- Fettucine Alfredo[1] is a real italian dish invented in Rome. It's made with butter and cheese. It was originally popular in the touristy areas, targeting foreigners, but over time I notice it slowly appearing in "real" restaurants.
- "Pasta Fresca" (tagliatelle, raviolis, tortellinis, etc) is often served with butter-based sauces (like a lot of the traditional northern cuisine).
A simplistic way to think about it is that butter is a rich luxurious ingredient used in the North, whereas the South is more likely to use Olive oil.
Note that other fats can be used, it's not just olive oil:
- Carbonara / Alla Gricia will use the animal fat from the _guanciale_ (the cured pig meat) and avoid using any oil or butter
- Cacio e pepe will use neither and use the cheese itself as fat for the sauce. It's a simple pasta, but it's difficult to get right, since parmesan/pecorino are diffcult to emulsify.
[1]: https://en.wikipedia.org/wiki/Fettuccine_Alfredo
The main reason for tagliatelle/pappardelle is to get "fresh" pasta. "Pasta Fresca" or "Pasta all'uovo" is made of different ingredients than spaghetti. It's usually soft wheat and eggs versus hard wheat (durum wheat, semolina) and water.
I agree that finding the right pairing of pasta and sauce does make a difference, but I would also say not to overthink it. Most italians will use whatever's available in the pantry, even if it's sub-optimal.
I've written a ton of open source code and I never cared what people do with it, both "good" or "bad". I only want my code to be "useful". Not just to the people I agree with, but to anyone who needs to use a computer.
Of course, I'd rather people use my code to feed the poor than build weapons, but it's just a preference. My conviction is that my code is _freed_ from me and my individual preferences and shared for everyone to use.
I don't think my code is "stolen", if someone uses it to make themselves rich.
reply