HIGHLIGHTS:
LUNATICS PRODUCTION:
Shot reference footage of Ariel and I to help with animating in SU-1-B shot (of Georgiana and Tech).
IT:
Had our site surveyed by Nextlink for high-speed line-of-sight internet. Unfortunately, we need a very tall tower to get it here, so the pole won’t work, and we’ll have to make a different arrangment.
Rebuilt Lum (entertainment computer) with a new SSD.
DEVELOPMENT
Added “reset rigify” feature to ABX. Planning work on KitCAT. Moved naming code from ABX to KitCAT.
TRAINING
I spent time this month watching videos from conference presentations and tutorials to learn about free software multimedia projects.
CLEANING
Spent some time cleaning the library.
CONSTRUCTION:
Poured first concrete pier for buttress on west side of house.
Another Shot Finished
At one point, I was attempting to do a modification of my “multicam” approach to this sequence, but after reviewing it, I’ve decided it’ll be easier to finish it one shot at a time, so I’m working through them this week. So far, so good…
These are fairly ordinary character shots, and the render times and memory usage are pretty reasonable, so I’m just rendering them on my workstation as I finish them.
There are still a few flaws here and there, but of course, at some point I just have to call it “done”, and I’m getting to that point, now.
Jul 8, 2021 at 4:40 PM (Film Freedom)
ABX Changes & Updated Roadmap
After struggling for several weeks with using project file and folder context in ABX, I decided to give up on this, and replace it with a much-simpler explicit system.
It became increasingly clear to me that this was an awful lot of work to avoid just typing in the systematic names for my project files as scene properties. Also, I clearly didn’t need the support for any filetypes other than Blender.
These features more properly belong to KitCAT, which is in a more experimental stage, and so I have now relocated them into that project, and then updated the tests.
Going forward, ABX will use a much-simpler “abx_context” module that just looks up the ‘abx.yaml’ files in the project to get correct defaults for ‘render_profiles’ and other features that need to get default settings from the project source tree.
I’m still backing out the explicit “Lunatics Properties” code, which will be replaced with “Project Properties” — except now, this will basically just be a series of text fields and some other data to assist features like “Ink/Paint” (which needs to name scenes and EXR files) and “Render Profiles” which needs to correctly set the name and path for rendering animation.
The main thing is to avoid having to meticulously reset all the render settings and paths when switching between various previsualization configurations and final rendering — that should just be a drop-down switch. But to do that, I need to store slightly broken-down name elements.
I was using an elaborate system for figuring out the naming used in a given project from file names, folder paths, and YAML files in the project, but it isn’t really that hard to just explicitly type in what I want for a given file, and once set, it doesn’t have to be changed.
The first step of this code is checked into the ABX GitHub repo (version ‘0.2.7dev’ — the ‘dev’ meaning it’s in-development and not even really an ‘alpha’ yet, but it is currently working at the time I’m writing this). It’s probably pretty rough, though. Save often.
I don’t currently have any useful defaults for the naming system. Probably, I should do things like set the render name prefix to the current filename or scene name or something similar if it is not set explicitly.
Part of the motivation of making this change is to get busy implementing usable new features, instead of more “under the hood” work.
Jul 12, 2021 at 5:00 PM (Film Freedom)
Resource: Libre Graphics Meeting 2021 Online
One of the few nice things to fall out of the Pandemic is that more people have done virtual conferences, and so there are more online presentation videos. I’ve been particularly enjoying the presentations from the Libre Graphics Meeting 2021, which was held in May this year.
So far, my favorite discovery is Arkengheist 2.0’s collection of Kdenlive tutorials on YouTube.
These are pretty impressive tutorials. I’ve been using Kdenlive for a decade, but I learned several new tricks from this!
I’m also intrigued by the “UpStage” presentation — this is software I’d never heard of before, ostensibly for “live on-line theater”, though I wonder about possibilities for using it for presentations, teaching, or as a fast production workflow for recorded projects (i.e. not using it live, but as a fast way to produce a video).
Regarding the Audacity Controversy
You may have seen some of the kerfuffle regarding Audacity and “Telemetry” or the new “privacy statement”, and you might be wondering if it’s all over for Audacity. In short, no it isn’t, but this is a concern that we’re going to have to keep an eye on.
What happened
Recently (April 2021), the Audacity project was purchased. What this means specifically for a GPL program is that the trademark, name, website, and “official” builds are owned by “Muse Group“. They’ve also taken the more controversial step of asking for contributors to sign-over their rights to the code to that company.
Shortly after that, it was revealed that the project had introduced “telemetry” into the code. This created an uproar in the community, and they backed off. But two months later, they introduced a privacy statement that raised the issue again, as well as creating some serious licensing issues — in particular that the software should not be used by minors.
This has resulted in some somewhat overheated rhetoric and panicked responses from the community, as well as a number of hastily-created “forks” of the software (if you don’t know what that is, I’ll explain below).
The current telemetry code is not particularly troublesome in itself (not yet): it’s the kind of information you usually submit with a bug report, and could be very useful for improving the software. There is a legitimate value to that for users.
The privacy statement is more concerning.
Some others have suggested this is not such a serious problem and that this is not really anything to worry about, because the information collected is not more than you would normally submit voluntarily.
Personally, I think it’s a very disturbing message being sent by the company, and evidence that they either don’t understand or don’t respect the ethics and sensibilities of the open source community. That’s a problem.
However, in practical terms, the problem is easy to avoid, and no real long-term danger is presented.
What is a “fork”?
A “fork” is when someone copies the code from a project, makes changes to it, and then starts maintaining it as a separate project. Free-licensed open-source software makes this legal, although it tends to be viewed as a “nuclear option”, because it’s so drastic and it splits community resources and attention. Also the name gets changed, and that impacts the “brand image” of the package.
More often, the threat of a fork is adequate to keep project maintainers honest, and that may be true in this case.
The response
Will a fork happen with Audacity? It’s too early to tell, and the outcome will probably depend on how well the new owners of the Audacity project respond to the user’s concerns.
I am troubled by the wording of the maintainer’s response to this issue, back in May, in which he expresses “surprise” (which would indicate a very poor understanding of the community), and also seems to see this as a problem of poor communication, rather than of an ethical transgression.
But no improvement to the “messaging” would make collecting data on users okay, nor requiring them to agree to a privacy statement allowing them to do so.
However, the change to the reporting system, which does now provide adequate consent for the information being sent is back to community norms.
Unfortunately, the new privacy statement, released two months later, reverses this goodwill by reintroducing terms allowing for data collection, and as a result, also attempting to ban minors from using the software (so as to avoid getting in trouble with the GDPR in Europe, where their servers are based).
Restricting minors from opting in to telemetry might be legitimate, but restricting them from using the software is a probable violation of the GPL. This kind of subject has come up before — a restriction on any class of users from using the software is considered “non-free” and forbidden by licenses compliant with the “Free Software Definition” (‘A free program must offer the four freedoms to any would-be user that obtains a copy of the software”), the “Debian Free Software Guidelines” (“The license must not discriminate against any person or group of persons.”), and the “Open Source Definition” (“The license must not discriminate against any person or group of persons.” Obviously copied from the DFSG).
The Gnu GPL 2.0, in particular, does not allow placing any further restrictions on distribution or use:
Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted herein
And of course, an age-restriction would violate this. It’s less clear whether this means that the privacy statement’s restriction is simply nullified or whether it makes distributing the software at all a license violation for anyone including the restriction.
Why I’m not that worried
I’m personally not that worried, and this is why:
- I use Linux. The Audacity project does not produce the builds of Audacity that I use. They are created by package maintainers for Debian or Ubuntu. During this process, they have the option to build the software with or without the telemetry options. I don’t know what choice they will make, but it would be consistent with past practice that they choose “without” — or at least make it a configuration question during installation. This is something I will need to pay attention to, which is a nuisance, but not a serious problem.
- I am still on Audacity 2.3.3, due to that being the standard version in Ubuntu Studio 20.04. The telemetry features don’t show up until the 3.x version. Having said that, I was thinking about upgrading in order to use the new “unitary save format”, which sounds like a nice feature. But it’s not a rush, and I’m not forced into it.
- The builds that ARE affected are for Microsoft and Apple platforms. That’s concerning for those users. But is it more concerning that the things those operating systems do already? Both platforms incorporate “phone home” features, so users of those platforms are accustomed to that. It’s a different culture. One I don’t agree with, but then that’s why I exclusively use Linux and free software.
- Should I be unhappy with the choice that maintainers of Debian/Ubuntu versions of Audacity make when they package 3.x, I can always simply make my own build. Not my favorite option, but certainly possible. If I do I will include this with packages I host on the Film Freedom Project, or I could start a PPA on the Ubuntu project site. More than likely, though, someone much more tech savvy than me will do that before I do.
- Whatever the Audacity project does, the Audacity program is under the GPL, and will remain so, even if they were to start distributing new code under a new license. Furthermore, even with developers signing over the copyright to their contributions to the company, trying to change the license presents a considerable legal risk, because any third party code could be held to contradict the new license.
- If less severe measures are inadequate, the project will get forked. There are several forks already, though most will probably die out soon. I will have plenty of time to select one before I need to upgrade.
Why you should be skeptical of recent forks
Maintaining a software package is a big responsibility. Even people with development experience are unlikely to appreciate the commitment it represents. This likely means that forks of the software made in haste are likely to go away, just as fast.
Forks as such, aren’t really necessary. The source distribution of Audacity allows for it to be built with different options in the compile process, and it’s possible to turn these undesirable features off.
So what is it really called for are not full forks of the software, but just custom package builds of the software. This is somewhat less labor-intensive than maintaining a fork, and they are not at all uncommon (for example, GraphicAll maintains a fairly large collection of custom builds for Blender for multiple platforms, usually incorporate some experimental patches to the software).
So this is fine, then?
NO.
Users do not expect ordinary desktop applications to spontaneously send information to an outside server, and there are many possible privacy concerns with doing so, even if the data is limited to crash information.
And even though the project backed down after the uproar, the introduction of the new privacy statements seems to indicate they still either don’t understand or don’t respect the open source community’s values. That’s very troubling.
I hope they will learn from this mistake and reform. But if not, then it’s likely that some fork will be necessary in the future.
So it’s not okay. But we don’t have to put up with it. Just how much we have to do to deal with the problem remains to be seen.
Photos
This month, I did some cleaning in the office and library, particularly to make some room on my workbench.
I repaired our HTPC computer, “Lum”, by replacing the failed hard drive. This is for family use, but also where I plan to test the Lib-Ray player software I’m working on.
Also this month, I poured my very first concrete project. It’s a pier to support one of two “buttresses” we’re installing to replace the straight columns that are failing. Why we need this is a long story, but the scariest part was that I’ve never poured any concrete slab before. Honestly, the results are a little disappointing in appearance, but I think it’s going to do the job I need it to do.
