Perhaps you could change copyright law to require either public source code or source code escrow before software could be eligible for copyright protection. Plus some default rights, like right to modification, rebuild and reinstallation for individuals.
What has 2023 do to with anything? The four essential freedoms for software were written more than thirty years ago and today are more relevant than ever: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
To answer your question: any government mandated software, or software used, or bought, or promoted by, or paid for by the government should be free software.
Something made by the military to be consumed by only them probably doesn't need to be open sourced. Same thing as if you write a program for yourself that only you use. Once something is intended to be consumed by the public, it should absolutely be open sourced. Voting machine software, tax filing software, etc.
I agree though, I just don't think it's an absolute rule. Voting machines and other stuff that the public uses probably should be.
Yes, if someone is after you specifically it won’t help, but you avoid automated stuff.
- All taxpayer funded sw should be open source
- what about defense?
- yes
- why?
- because it's taxpayer funded
Software that is used internally and not distributed need not be free software. That was not my point.
That said, I do work in defense now (writing software for a defense partner that finances the research of my lab) and the contract requires that all our production be published under an open source license. Only the data is secret, and we don't really get to see most of it.
As for the law, any software no longer for sale, or older than 10 years old should lose all copyright/IP protection, which ever happens first. Anyone should be able to write/support a Windows XP,7 or 8 clone at this point, along with Office, Exchange, etc. up to 2012
--- Warning --
Strong message (rant) to follow
Uppity programmers calling themselves software "engineers" act in almost totally the opposite manner of a true engineering discipline. They hold "legacy" in contempt, and break things in the name of "progress" or "safety" at odds with their stated goals. They ignore the lessons of history, and keep re-inventing the same things every decade or two.
You can still plug a BC-232 radio manufactured in the late 1940s into the wall and receive broadcast signals.
You're effectively prohibited from running a web browser or telephone from 10 years ago because of planned obsolesce. This needs to stop!
But, but, but it is for your own security. /s
If the difference between python 2 and 3 is so small that a program can be easily ported, then WHY did there need to be a difference at all?
It may be from a pure economic perspective focused on a business that can socialize externalities. Sometimes new developments reduces development time. On the other hand, the externalities of that is that a modern computer performs worse running equivalent tasks today in the browser than a native app 15 years ago on hardware from that time. Lucky for businesses that they aren't held responsible for the ewaste they helped produce.
If 90% of apps necessary for normal life are only available as poor web versions it drives obsolescence no matter what the remaining 10% do.
Web apps is better than native as they are automatically running the latest version, platform independent (windows, mac, linux, android, ios), in some sense more secure. Instead of asking people to write more native apps, I think we should rather ask them to write more quality web apps if they don't need native capabilities.
E2A: Also, try running Figma on an older device. It's basically unusable. No native version, and a native version would be much better.
As an example, see Atom vs VSCode. We thought building a code editor with electron will lead to something slow like Atom, but m$ later proved that it is possible to build something fast. Perhaps not as simple as native, but it can be done.
yes.
one of the changes (and in my experience, the most problematic change) was the removal of the keyword "print"
it was a poor choice at the start to treat "print" like a keyword. it is a simple, breaking change to remove it, easily automated (ps: just add brackets), and now the language is more consistent and flexible.
The only reason to keep it is to not "touch" things. but it is easily mitigated, so that isnt a good enough reason imo. I much prefer a consistent language.
otherwise I'd stick with PHP.
By a python programmer, sure.
By another programmer, ok.
By your grandpa that just wants to run that python script to organize his stamp collection that has worked for decades? No.
For something as popular as python there will be thousands such people. Stuff that will simply NOT get fixed.
But that cost is easily ignored by the original developers.
There was a breaking change in Python, followed by a breaking change in WX_Windows, so while you can, in theory, run WikidPad under Linux today, few of the dialog boxes work, effectively disabling the program. 8(
Python2-3 transition COULD have been made easier, but it wasn't. The community places far too little emphasis on backwards compatibility.
This is because there's a myth: pushing a free upgrade across the internet is zero cost
This is not true, and can't be true. The cost of manufacturing software has effectively fallen to zero. This is not the same as the cost of implementation.
--- Tangent/Analogy ---
When you get a large machine tool, there are physical installation requirements that can delay its use by up to a year. Sometimes the floor needs to be removed and replaced with a better foundation. Power, cooling, air, vacuum, networking and other connections need to be made. These may require updates to infrastructure.
Once sited, machines have to be precision leveled, and there is always some form of break in period as differences are found and accounted for in their use.
Users have to be trained to allow them to work with/around any UI or performance changes that might effect production.
---
In a very similar fashion, software requires infrastructure (dependencies, operating system support, bug fixes, user training) and new executables carry new bugs to be worked around, performance changes, etc.
Security fixes should strive to minimize changes, but to me it is entirely unacceptable that they are necessary, especially at the rate currently required.
Security should be the job of the Operating System, not the application, network, users, especially NOT the users.
Software security updates should happen about as often as automobile recalls. They should be costly to the manufacturer and infrequent.
The reason for that is that software is much easier to change than hardware. You cannot expect every person in the world to update their radio equipment every couple years - it's too expensive - but it's somewhat reasonable to expect people to install new software, especially if it can be done for free over the internet.
It's just economics at play.
The cost to manufacture an executable is effectively zero, so its easy to incorrectly assume that means there are no costs.
The cost to integrate an executable is NEVER zero, there are always costs.
Windows is far, FAR less reliable on Wednesday morning because of "Patch Tuesday", this is a substantial and real cost.
The same is true for any system that implements "security patches" and feature "upgrades".
But even if this would destroy your business model, that doesn't mean it would not be a good idea for society as a whole. Business models become obsolete all the time. If there is enough demand for your software, you will be able to fund the development of it even without might-as-well-be-perpetual exclusive control.
What I am trying to say is that both things are very different in details where it matters, so I think this is a rather flawed analogy.
Maybe a closer analogy would be landowners who rent out land. Should a person who bought land 10 years ago be able to generate revenue from renting it to a farmer?
In that case, the value of land is created entirely by property law.
A farmer has the exclusive right to land from the existing fixed supply that the entire world has available to it. He didn't create it and no one else can use it. Whereas a software developer makes something new. Nobody else was deprived of anything pre-existing. Less justification for taking code from a developer than land from a farmer.
Python 2 still exists. Those programmes will break if you try and run them on Python 3, but that's not the same.
Can't? Like physical objects can't be repaired when the parts are no longer sold?
There is always a way to repair, just a matter of how difficult it is. Having the sourcee to the application itself is the first difficulty barrier. Source to dependencies would also be helpful, yes.
Btw, Python 2 did not go away unless you mean it went away from the default package archives of some Linux distributions - but even there it's not (yet) gone for all of them. The Python 2 sources are still the same as they have always been and while you might need older versions of a few more dependencies, if your really need to have Python 2 you can get it.
I love the idea of source code escrow as a requirement for copyright protection. If it were up to me, a DRM free copy of every work would need to be submitted to the copyright office for full copyright protection and that agency would publish and make available every work at copyright.gov automatically the moment the copyright on that work lapsed (ideally something that should happen in less than 10 years) while the works still protected would display a countdown clock showing the time until it's released to the public domain along with a list of reachable contacts for the copyright holders so people know who to contact if they don't want to wait.
That's the entire deal. It's better for everyone, better for art, and better for tech when information and culture is freed and people can incorporate it into their own works as well as learn from and build on what came before them.
Copyright only protected those works for a limited time to encourage the creation of new works by making financial success possible but not perpetual.
In a world where we can publish globally in an instant and at near zero cost, seven years or so is plenty of time to make investment worthwhile, no matter if that investment is in time, talent, or R&D. It's not as if the copyright owner (which for commercial works is almost never the same person as the creator) can't make money on something just because it's in the public domain either.
EDIT: appartently there was a ruling in the Court of Justice of European Union on this
https://www.lexology.com/library/detail.aspx?g=f5b1193c-f423...
1. Software would become entirely non-copyrightable
2. Software that infringes on a patent claim would be prima facie evidence of the claim's invalidity
3. Distributing any software in a way that would violate the AGPLv3 would be illegal (with the exception that if you had access to binaries but not the full corresponding source for a program prior to this change, you could still freely distribute everything you do have afterwards), and both upstream authors and downstream recipients would have standing to sue over it
If your plan is to change copyright law, then just require all software be GPL licensed.
I don't think right-to-repair for commercially supported software makes sense. If you care about the right to modify and rebuild, put source access into the contract. But you have a commercial relationship, so the vendor is supposed to listen to your feature and bugfix requests. If they're unwilling to consider source access or feature/bugifx requests, don't buy from them, it sounds like they don't care about your business.
2. Mandate release of software developed using public funds under AGPL (e.g. government portals) or GPL, with obvious exception carved out for defense projects
3. Mandate implementation of manual overrides that allow owners to flash unsigned firmware/software on their devices, similar to Android phones
4. Legalize and ban EULA prohibitions against reverse engineering
5. Legalize and ban EULA prohibitions against unauthorized changes, carve out exceptions where strictly necessary (e.g. medical equipment and equipment critical to public safety, online games?)
The Garmin Connect cookie banner was broken. It kept showing up on all reloads despite acceptance. In the end the add blocker fixed the problem by entirely removing the cookie banner.
I would say that is the first level of right to repair for software.
Nir is there licenses for specific purposes, such as companies wanting to create their own franchise or a content creator wanting to use said copyright once in their work (even if you got permission you can be liable).
You repair physical stuff because parts wear out. Software doesn't wear out.
In my opinion, it would be better to set a support window where a company must provide updates to fix flaws or security issues based on the type of device. OSes could be 5 years, safety recalls for vehicles are already covered. I'm not sure any action is really necessary on this.
I don't expect the manufacturer to do the maintenance work indefinitely, but don't understand why perfectly good hardware should be turned into e-waste after a short number of years despite there being people who are willing to do all the work.
I can imagine a future in which a company has to guarantee a certain time frame for security updates and, once that time span ends, allow third party access. This would at the very least involve unlocking the bootloader so that reimplantations can be installed.
This should absolutely be banned. Either release the source code, or build the code yourself.
There is no need to throw away a perfectly good scanner, which you can still get repaired, simply because the company prefers to sell you a new one.