@To summarise a few things I’ve said over the last couple of decades:
I believe copyleft licenses are, at best, unhelpful, and often actively harmful if your goal is to empower users. A system that empowers users should be easy to modify and if modification comes with a bunch of conditions that you need to be a lawyer to fully understand then that’s another barrier. A successful Free Software system would be one where most users modify the software, but I’ve rarely seen examples where even 1% do. A license can only ever prevent people from doing things, it can’t make them participate in a community. When you give people a load of conditions to try to force them to do what you want then you begin your relationship with them on an adversarial footing. This immediately puts them in a mindset of trying to avoid compliance with the spirit of your intent, while sticking with the letter. This is not how I want a community to work.
A lot of F/OSS is a clone of some proprietary system but ignores the social aspects that shaped these things. Proprietary software has to have a strict divide between the program (the thing that they sell you), plugins (which third parties may be allowed to use to extend the program but which the end user may not be able to redistribute, may require an explicit license from the program vendor) and documents (which the user may create, modify, and distribute). In a Free Software system, a user should be able to extend the functionality in arbitrary ways and distribute the results. This is one aspect where copyleft licenses are actively harmful: if you actually build something like this, then every document the user creates must comply with the license and you can’t, for example, use it for anything shared under NDA. GCC has an explicit exemption for the output of the compiler, and that works only because there is an assumption that most users will not extend the program in ways that are specific to the user: from the choice of license, they start from a position that they cannot build something where users actually exercise the FSF’s Four Freedoms.
And this impacts the structure of software a lot. Proprietary software is all about building large monolithic entities so that users remain in your ecosystem. You can justify the cost for the next version by how long they spend using the program. If a program is just a tiny extension to a workflow, it’s hard to charge for it and it’s very hard to get people to buy a new version next year.
None of these concerns matter for community-driven software and most of them are actively counter to the goal of empowering end users.
The focus on licenses also ignores why most end users don’t exercise the freedom to modify the software:
- It is hard to understand these codebases even for experienced developers due to lack of documentation and complex structures.
- It is very hard to keep modifications working as upstream churns the code.
- If you make a change in anything that you use in a collaborative environment you need to make sure that all of your collaborators have the modified version, which is infeasible in most cases.
For Étoilé we had a few goals to try to address this. One was to replace the notion of monolithic programs with loosely coupled services which could be assembled to meet the same needs as existing programs, but could also be assembled in other ways. Our tentative rule was that no service should be more than 10,000 lines of code (excluding shared-library code used by other services), which is small enough that a single person can fully understand or rewrite it if it doesn’t meet their needs. A lot of services were expected to be tiny: tens to hundreds of lines of code, the kind of thing an end user could throw together in half an hour to solve a problem that they have this week. And, because they were self-contained and modular, they could be distributed to collaborators as additions to the system, rather than replacements for something they were using.
The other thing that we did was focus on exposing core functionality to higher-level languages. We had a JIT’d Smalltalk dialect that shared the same object model with the Objective-C core and we’re looking at using the same model in visual / dataflow UIs to enable people who don’t think that they are programmers (if you can write an Excel formula, you’re a programmer) to build services. The reflection support in the runtime meant that you could use high-level code to replace a method written in statically-compiled Objective-C, so you could have local modifications of a compiled service without needing to recompile it ( 
@neilNeil Brown might be able to tell you what your obligations are under various GPL variants if you do this, but the lawyers I spoke to gave conflicting replies).
By focusing on modularity and small, loosely coupled components, we aimed to build a humane system that could shape itself to user needs and be hard for corporations to capture. Company comes with a large monolithic service that you can’t modify? Well, it’s obviously less useful than the ones you can because your normal workflow involves modifying components. And the monolithic nature means it doesn’t interoperate well with your other services. Corporation decides to take a service that you use in a stupid direction? Fork it, they’re small and designed to be maintainable by a single person, so if a dozen of you all prefer the old version then it’s a negligible amount of work shared between all of you.
As long as your ecosystem cares more about licenses then architecture and builds monoliths, it can’t be the system that makes end users demand the ability to modify and redistribute modifications of the code, and that demand is the essential thing for making user-hostile proprietary software an anachronism.