cygx
In this case, willing to proceed with what he was planning to do, that is, moving from Windows to Linux against Microsoft's wishes.
edit: And you're right that this implies "balking at Microsoft's proposal". Personally, I did read the sentence as intended ("they wanted him to balk (= stop his plans), but he did not"), but I can see how the phrasing can be misleading...
1: to refuse abruptly
2: to stop short and refuse to proceed
Per Cambridge Dictionary, it means:
to be unwilling to do something or to allow something to happen
So "He did not balk" can be read as "He did not stop" / "He was willing to let things proceed"
> which would still be a GPL codebase
If the GPL-licensed parts have become so insignificant that they can easily be replaced, it effectively no longer would be.
> The Office concludes that, given current generally available technology, prompts alone do not provide sufficient human control to make users of an AI system the authors of the output. Prompts essentially function as instructions that convey unprotectible ideas. While highly detailed prompts could contain the user’s desired expressive elements, at present they do not control how the AI system processes them in generating the output.
As you pointed out yourself, there's always the option to create a fork that does allow AI contributions, which may eventually force a re-assessment of the policy if the gap in utility grows too large.
There's a human authorship requirement for copyright protections. In context of AI, cf Stephen Thaler v. Perlmutter, eg. at [1].
[1] https://en.wikisource.org/wiki/Thaler_v._Perlmutter,_Respons...
Hit my knee in the right spot, and I'll kick my leg, no choice about it. Scream at me to LIFT MY EFFING LEG (in a language I do understand), and I may or may not do so. Write the same thing on a piece of paper, and I generally won't (unless there is some very specific context).
With AI systems, we have the benefit that the distinction between such pathways is in principle under our control.
There's overlap and edge cases, though: Maybe you have a program that summarizes texts. One could argue that's no different from a passive filter. But can you then ask questions about the text? That's unquestionably AI.
And just to clarify, personally, I would not describe JangaFX as a game company myself (as you pointed out, they aren't in the game business per se, but the visual effects business) - I'm just trying to clarify why the claim isn't completely outlandish.
On the contrary! I gave examples where source files get generated. This happens in one of two places: Either when the maintainer publishes a new version, or every time an end user builds the package.
I'm arguing for the former, you're arguing for the latter. There are pros and cons to either approach. Some cons for the latter:
First, the build process becomes more brittle, as every end user now has to install the necessary tools. In case of the project containing RELAX NG schemas I alluded to, this would require a recent version of Perl, a Java runtime, and the Trang utility written in Java. The alternative? Just shipping a single XML file.
Second, the build process often doesn't become more, but less auditable: Instead of just reviewing the source files that actually get compiled, you now have to track down how they get generated, and review all the scripts that do so.
I still like the idea of shipping tarballs that include generated files instead of pulling input files from source control. As mentioned, the first thing that came to mind to make things easier to audit is to stick their contents into a community-controlled VCS.
Generated HTML files are potentially easier to audit than the scripts/toolchains used to generate them on an end user's machine if you do not pre-generate them.
Off the top of my head, other things I've done is committing RELAX NG *.rnc files, but shipping *.rng files, or generating C header files for various types of data (think `xxd -i` in case of binary files, but also just large chunks of plain text that gets wrapped into a C string).
Yes, that would be an option.
As to your question, you generally want to version control input files, but distribute the generated artifacts. Some possible scenarios would be documentation, data tables in source or binary form, generated code including maybe even configure scripts if you cannot avoid it (though if I had to 'vendor' 3rdparty code that uses autotools, I think I probably would just unpack a tarball and commit the relevant artifacts).
First, I'm uncomfortable with making a package creator's VCS provider part of the language's module infrastructure.
Second, not all files under version control necessarily belong in a tarball, and not all files in a tarball necessarily need to be under version control.
However, the point that there should be an easy way to track changes in your dependencies is well taken. One possible approach would be that publishing a packge boils down to importing the files that normally would go in your tarball into a community-controlled VCS.
Who should decide when to enforce the notability rules, and when to skirt them?
I rather think people will vote with their feet once more
Maybe, maybe not - they've stuck around for a quarter century already...
Such approaches rarely scale: When the Eternal September rolls in, you tighten the reins or get swept away...
As far as I'm aware, there are no articles in the press about Odin, no academic papers, no non-self-published books, no conference talks, not anything that rises to the standard required by Wikipedia for inclusion of a topic.
It is an encyclopedia of topics that meet its standards of notability (ie there exists "significant coverage in reliable sources that are independent of the subject"[1]).
But how do you moderate? Do you establish your own ministry of truth? Only allow contributors with a university email address (shoutout to the arXiv)?
Wikipedia decided to externalize part of the vetting process by placing formal restrictions on the sources you're allowed to collect information from.
Sadly, there currently aren't any such sources for Odin.