,
,
,
Repair and OwnershipRepair and Ownership is an ASK-Solutions project concerned with the question of what ownership means in practice. When you own something, to what extent should you be able to understand, use, maintain, repair, modify and continue using it without remaining dependent on permission, services or infrastructure provided by the original supplier?
Repair is an important and visible part of that question, but it is not the endpoint. A product can be technically fully functional yet become unusable because an account disappears, a server is shut down, software is no longer supported, a feature is placed behind a subscription or what was presented as a digital purchase turns out to be only a revocable licence. Repair and Ownership also examines these forms of dependency.
The name of the project is deliberately broader than Right to Repair. Repair is one of the clearest moments at which it becomes visible how much control an owner really has. Can you open the device? Is documentation available? Can you obtain parts? Can you access diagnostic data? Are you allowed and able to examine or replace the software? Can an independent repairer do the same things as the manufacturer or an authorised dealer?
But the same question begins before a repair is necessary and remains after something has been repaired. May you use a product differently from the way the manufacturer originally intended? Can you replace a component with a functionally suitable alternative? Can you install your own software? Can you retrieve and take your data elsewhere? Does a device remain usable when the manufacturer ends an online service? And can a feature that was present when you bought the product later be made dependent on new terms or continuing payment?
That is why Repair and Ownership appear together in the project name. The repair question is a practical test of ownership; the ownership question ultimately concerns the control that actually remains with the owner after purchase.
The history of Repair and Ownership goes back to before the current organised Right to Repair movement and even to before the US DMCA of 1998. The subjects were not necessarily described using the terms now associated with them, but the underlying questions were the same: who retains practical control after a sale, what knowledge remains available and how much power can a supplier retain through technology, contracts or regulation?
An early subject was something as simple as actually reading the terms of online services. With services such as Hotmail, we did not only look at what a service visibly offered, but also at what its terms said about messages, data and the rights the provider granted itself. The broader question was already recognisable: if you use a service to store personal information or communicate, how much control over that information do you still retain yourself?
During the same period, the relationship with physical products was also changing. Televisions, radios, central-heating systems and other equipment had often been supplied with schematics, service manuals or other technical information, or such information had been relatively easy to obtain. Increasingly, that knowledge moved into closed service networks run by manufacturers, dealers and authorised engineers. The owner still possessed the device, but the knowledge needed to understand and maintain it independently was becoming less readily available.
With software and digital media, the distinction between legal ownership, practical use and technical control became even more visible. The DMCA and related discussions about digital access controls demonstrated that a technical restriction could become more than merely a security mechanism: circumventing a digital lock could itself become legally problematic, even when the underlying action served a legitimate purpose.
Further proposals in the United States sought to embed copy-protection requirements even more deeply into computers and other digital devices. Discussions around proposals such as the Security Systems Standards and Certification Act and the later Consumer Broadband and Digital Television Promotion Act even raised the question of whether general-purpose computers and other digital equipment should be technically required to enforce restrictions determined by rights holders.
For Repair and Ownership, this touches on a fundamental distinction. A computer is valuable precisely because its owner can use it for new and unforeseen purposes. When hardware or software is designed so that an external party determines in advance what information may be processed, which programs may run or which data may be copied, control shifts away from the owner towards whoever controls the technical lock.
A clear example arose around Adobe’s protected e-books. Digital restrictions could block copying, printing and text-to-speech. The latter was not merely a matter of convenience: people with a visual or motor impairment could depend on screen readers and accessibility software other than the facilities Adobe itself made available.
In 2001, Russian programmer Dmitry Sklyarov was arrested in the United States because of his work on software capable of removing restrictions from Adobe e-books. The resulting discussion therefore concerned more than copyright or unauthorised distribution of books. The same technology could allow a legitimate user to read a purchased book using different software, make a backup copy, use it under Linux or use text-to-speech software that actually suited the user’s needs.
This illustrates a recurring principle within Repair and Ownership: a security mechanism may serve a legitimate purpose, but the existence of that purpose does not automatically make every restriction placed on the owner desirable or responsible. Security, copyright and protection against misuse must be weighed against accessibility, research, interoperability, repair, preservation and ordinary use.
The problems surrounding digital locks and accessibility do not stand alone. A recurring question within Repair and Ownership is what happens when a single supplier attempts to control not only a program or file format, but an entire ecosystem: the programming language, development tools, runtime, user interface, distribution and sometimes even the choice of operating systems on which applications can be executed.
Adobe, and before it Macromedia, provide an important historical example. An increasingly complete application environment developed around Flash and ActionScript. Flex added a more extensive component and application model, while Adobe AIR allowed applications from that ecosystem to run outside the browser as standalone desktop software.
This provided developers with many capabilities within that environment, but that is not the same as freedom. A developer who invested substantially in an application written in ActionScript, Flex or AIR simultaneously invested in a runtime, component model and tools whose future development was controlled by Adobe. An application could therefore become strongly tied to Adobe even when its actual purpose had nothing to do with Adobe itself.
AIR was explicitly promoted as a cross-platform environment. That suggests that an application becomes less dependent on a particular operating system. In practice, however, a new dependency was inserted between the application and the operating system: the Adobe runtime had to exist for that platform.
Particularly at first, desktop support largely meant Windows and Macintosh. Linux support came later, but depended on Adobe’s own binary runtime and did not automatically function across every distribution and system configuration. That support was then discontinued again; AIR 2.6 remained the final official Linux release. No comparable AIR runtime was ever made available for several other Unix systems on which mature graphical and programming environments had already existed for many years.
A supposedly platform-independent application could therefore bind its user once again to a limited set of platforms. If Adobe did not support an operating system or ended that support, a user might have to preserve an old runtime or operating system, move to another platform or abandon the application altogether. The choice of operating system then no longer rested solely with the user and developer, but partly with the supplier of the intermediary layer.
This matters because cross-platform applications were not a new problem at the time. Several much older architectures already existed that could separate software from one particular operating system without making a single supplier the sole gatekeeper of the runtime.
Java provided a broad example. Java was used not only on Windows and Macintosh, but also on Linux, Solaris, HP-UX, SCO OpenServer, UnixWare and other systems. Different system vendors and implementers could provide a Java environment for their platform. The programming language and execution model therefore did not depend exclusively on the willingness of one company to release one particular closed binary for every supported machine.
Java also offered several approaches to graphical interfaces. AWT made substantial use of the operating system’s native controls. Swing largely used its own components, but connected them to an explicit Java Accessibility API. SWT later adopted another model in which a single Java API used the native widgets of each operating system wherever possible.
An important architectural distinction therefore already existed. Cross-platform did not have to mean that an application detached itself completely from the facilities of the underlying system. A graphical toolkit could use native components or employ a separate accessibility layer to communicate that something was a button, text field or menu, what state it was in and which actions were possible.
Java was not limited to conventional desktop applications either. A Java applet packaged as a JAR could be loaded from a web page and executed within the browser environment. The browser page could act as the distribution and integration layer while the software itself ran inside the Java runtime.
Java Web Start applied a related idea outside the browser. Through a small JNLP file, a website could specify which program files and Java version an application required. The application could be retrieved, cached locally and then run as a standalone application. The web could therefore be used for distribution and updates without requiring the application to remain dependent on the original web page every time it was used.
On feature phones, a similar model acquired major practical importance. Java ME and MIDP made it possible to run applications as MIDlets on highly constrained mobile devices. A small JAD file could describe the required JAR, after which the phone installed the program. Most of the software then remained local and only current or changing data needed to be retrieved over the mobile network.
This distinction is important to Repair and Ownership. Mobile bandwidth, memory and storage were extremely limited at the time. Installing a program in advance and retrieving only small amounts of information during use was therefore not an artificially introduced dependency. It was a reasonable technical solution to real limitations in the available hardware and networks.
A network dependency is therefore not automatically an infringement of ownership. The relevant question is why that dependency exists. Is it necessary to create a usable system within the technical possibilities of the time, or is a technically avoidable dependency added in order to enforce control, advertising, licence enforcement or continuing payment?
Later mobile development also shows that the principles behind Java did not simply disappear. Android did not use an ordinary Java SE runtime, but it was built on the Linux kernel and historically exposed much of its application API through the Java programming language. A new mobile environment therefore did not need to be built on Adobe’s closed ecosystem in order to become a large application platform.
Java was not the first example either. Tcl originated on Unix at the end of the 1980s as an extensible programming and scripting language that could be embedded in other applications. Shortly afterwards, Tk was developed as a graphical toolkit for Unix and X11 systems.
In the following years Tcl and Tk were also ported to Windows and Macintosh. An environment that had originated in the Unix world thereby developed into a genuinely cross-platform model for graphical desktop software. Much of the application itself could remain unchanged while the environment could be made available for different systems and could be further modified or ported from source code.
This is precisely what makes Tcl/Tk relevant in comparison with AIR. By the time Adobe introduced its own cross-platform desktop environment on top of Flash and ActionScript, the underlying concept had already existed for many years. AIR did not invent cross-platform desktop software; it brought an existing idea into an Adobe-controlled runtime and made the availability of that runtime itself a new dependency.
The same applies to interactive graphical applications in and around the web. Flash did not exist in a technical vacuum. JavaScript, later standardised as ECMAScript, was not merely a language for changing a few elements of an HTML page. The language could be executed in different host environments and existed as a programming language independently of HTML.
SVG provides an important example. An SVG document could exist independently, had its own document structure, graphical objects and events, and could be programmed using ECMAScript. This made it possible to build interactive graphical applications in which JavaScript directly controlled the behaviour of the graphical environment.
Here too, the history should not be simplified retrospectively into the idea that Flash required a plug-in while open technology worked directly in every browser. Initially, that was not the case. SVG could require a separate viewer or browser plug-in, and Java applications also used a browser runtime. When an SVG viewer executed the associated ECMAScript, that JavaScript was likewise running inside additional software.
The relevant difference therefore did not lie in the existence of a plug-in. A plug-in can be one implementation of a publicly described standard that other parties are also able to implement. Architecturally, that is very different from a plug-in that forms the required execution environment for an application platform controlled by the same single supplier.
This is where another fundamental problem with the Adobe architecture became visible. Flash, ActionScript, Flex and AIR applications could draw and handle a large part of their user interface themselves. AIR could even replace the operating system’s normal window controls with a completely custom interface.
For a sighted user, a drawn button may look exactly like a native button. For a screen reader or other assistive technology, the difference can be enormous. A native control is not merely an image: the operating system knows that it is a button, knows its name and state, knows where the focus is and knows what action can be performed.
When an application builds its own graphical world, that semantic information has to be exposed again, correctly, to assistive technology. If that does not happen, an application may appear fully functional to a sighted user while someone who depends on a screen reader, keyboard navigation, magnification or adapted input is left with little or no usable interface.
Adobe thereby persisted with a problem for which other architectures already offered solutions. AWT could use native elements, Swing had a separate Accessibility API and SWT could connect to operating-system facilities through native widgets. That does not mean that every Java application was automatically accessible. It does demonstrate that bypassing existing accessibility facilities was not an unavoidable price of a cross-platform interface.
Dependency on such a closed ecosystem therefore operates at several levels simultaneously. A developer can become locked into a programming language, toolkit, development environment and runtime whose future is controlled by one supplier. An end user can become dependent on that same runtime and on the operating systems for which the supplier chooses to provide it. Someone who needs assistive technology can additionally become dependent on whether the developer has rebuilt sufficient accessibility inside that separate interface world.
Economic circumstances matter as well. When newer versions of an application work only on newer hardware or a limited range of supported operating systems, migration is not merely a technical choice for the user. The required hardware, licence or service must also be affordable. A platform can therefore exclude users who still possess technically usable equipment but cannot or do not want to participate in the replacement cycle imposed by the supplier.
For Repair and Ownership, accessibility and economic accessibility are therefore not separate social additions to a technical subject. They relate directly to how much practical control a user has over their own equipment and software. A product that is usable only by people able to follow the supplier’s chosen hardware, software, physical interaction model and payment structure effectively excludes part of its user base from practical ownership.
With closed platforms, technical quality is not the only factor that matters. A supplier with a sufficiently large marketing budget, distribution agreements, bundling arrangements and commercial support can turn its own solution into the obvious point of reference. Once almost every user already has a particular runtime and increasing numbers of developers build for it, the cost of not participating becomes progressively higher for everyone else.
This creates a self-reinforcing effect. Wide distribution makes a platform attractive to developers. More applications make the platform more important to users. That in turn makes it more attractive for browser developers, manufacturers and other distributors to include it again. The resulting dominance can easily be mistaken for evidence that the chosen technology was technically necessary or self-evidently the best solution.
Even the historical direction of comparison can then change. Existing or parallel solutions are retrospectively described as alternatives to the dominant product. This creates the impression that the dominant product first defined the category and that other solutions appeared later to replace it.
This is not limited to Flash. Graphics applications such as GIMP and Paint Shop Pro are now easily described as alternatives to Photoshop. GIMP did appear later than Photoshop, but it has developed as an independent project alongside Photoshop since the mid-1990s. Paint Shop Pro even appeared in the same year as Photoshop. The fact that users may later rediscover such software because of Adobe’s pricing, licensing terms or other restrictions does not make those programs historically new replacements that appeared afterwards.
With AIR, the reversal is even clearer. Cross-platform graphical desktop applications had already existed for many years through environments including Tcl/Tk and Java. Yet a new implementation controlled much more tightly by a single supplier could be presented as a new step towards platform-independent applications. The high visibility of the new product could thereby push the much older technical landscape into the background.
For Repair and Ownership, this matters because market dominance says nothing about how much freedom a technology leaves to other parties. A platform may offer impressive functionality, be widely used and commercially very successful while simultaneously giving developers, users and independent implementers fewer possibilities to keep the technology available, modify it or continue it outside the original supplier.
Java, Tcl/Tk, SVG, ECMAScript and other existing environments were not perfect themselves. Implementations differed, support could be incomplete, licences changed and open standards could also be implemented badly or accessibly poorly. The relevant distinction is not that one technical alternative solved every problem.
The more important question is where the decisive dependency lies. Can another party implement the runtime or viewer? Can software be ported to another system? Can a user choose another implementation? Can an application continue to be maintained when the original supplier stops? Can a developer continue without starting again from scratch? Can someone with a disability keep using their existing assistive technology? And can someone with limited financial resources continue using serviceable equipment instead of being forced into replacement by software?
A closed ecosystem can concentrate power with one supplier across all of these points at once. For Repair and Ownership, that is a direct ownership question. Ownership concerns not only files or hardware for which someone has paid. It also concerns the ability to continue using, understanding, maintaining and modifying that technology when the original supplier makes different commercial or technical choices.
As devices became increasingly connected to software and networks, ownership became less dependent on the physical construction of a product alone. A camera, baby monitor, lamp, television, car or household appliance may technically belong to its owner while important functions remain dependent on an account, an app, a server, a subscription or permission from the supplier.
This creates a different kind of lifespan. A mechanical component can wear out and be replaced. An online service, by contrast, can disappear through a single policy decision. A manufacturer may cease trading, an acquisition may occur, licensing agreements may change or a new software version may impose different terms. The physical device may remain capable of functioning for many years while an external dependency determines whether it can actually still be used.
Repair and Ownership therefore looks beyond the question of whether something works today. What also matters is what happens when the supplier no longer wants, is no longer able or is no longer permitted to provide the service tomorrow. Can the device then continue to function locally? Can another party take over the required service? Is the protocol documented? Can you export the data? Can the software be replaced? Or does a purchased object effectively become electronic waste as soon as an external server disappears?
Digital distribution has also made the word buy less straightforward. With a physical CD, DVD, book or device, the copy will normally continue to exist when the shop closes or the manufacturer loses a licensing agreement. With digital purchases, however, the word “buy” may conceal a licence under which access remains dependent on an account, platform or agreement between companies to which the user is not a party.
The distinction becomes visible when a provider announces that media previously offered as purchased will disappear from users’ libraries because a licensing agreement has changed. The mere fact that such an announcement can be made raises a simple question: what exactly did the user buy?
A revocable licence is not legally the same as rental or loan, but in practical terms it can differ greatly from traditional ownership. If another party can unilaterally determine how long access continues, the user’s position resembles ordinary buying and permanent possession far less closely.
The fact that this issue is now more widely recognised can also be seen in legislation requiring sellers of digital goods to make it clearer when terms such as “buy” or “purchase” actually refer to a licence that can be withdrawn under certain circumstances. For Repair and Ownership, this is not a new question, but a modern manifestation of a much older one.
A similar shift is taking place with physical products. Modern equipment can contain hardware that is fully present and technically operational while software determines whether the owner is actually permitted to use it. Manufacturers can thereby activate features after purchase for a limited period, connect them to an account or sell them separately as digital services.
If a manufacturer wants to offer different versions of a product, an owner should be able to make a genuine choice between products with different capabilities. A simpler version can contain less hardware and therefore require fewer raw materials, less production, less weight and less energy. A different situation arises when the same additional hardware is present in every product but the owner may use it only after making an additional payment or taking out a subscription.
In that situation, it is misleading simply to describe the non-activated version as cheaper. The owner may pay less at that particular moment for access to the feature, but the hardware has already been designed, manufactured, installed and transported. The raw materials and energy have therefore already been consumed even if the owner is never able to use the component. Depending on the type of hardware, its presence may also add weight, occupy space, increase complexity or consume additional energy during the life of the product.
For Repair and Ownership, the relevant question is therefore not only whether a feature is sold as optional, but also where that choice is made technically. A genuinely simpler product without the relevant hardware is something different from a fully equipped product whose components are disabled in software. In the latter case, the user physically owns more of the device than they are actually permitted to use, while the manufacturer retains practical control over access to part of the purchased object.
More intrusive still is the situation in which a feature that was normally available at the time of purchase later becomes dependent on additional payment because of a software change, new terms or a changed business model. In that case, the manufacturer is not merely changing what it will sell in the future; the practical properties of something someone already owns are being restricted after the fact.
Interoperability is also part of practical ownership. This is not merely a question of whether different devices happen to use different technologies. A much sharper ownership question arises when equipment fundamentally uses the same standards and could technically work together, but a supplier or network operator deliberately introduces an additional deviation so that only selected equipment will function.
This was visible, for example, during the transition to digital television. Television, decoder and Conditional Access technology could be technically compatible while a network operator nevertheless added an artificial restriction. This could be done in remarkably simple ways: interpreting or inverting a bit differently, presenting a signal on a different pin of an interface, requiring the serial number of a receiver to be registered in advance on the network, or introducing other small protocol deviations. Channels or services could sometimes even switch between a standard signal and a modified variant. The consumer was then not facing a genuinely necessary technical incompatibility, but a compatibility boundary that had deliberately been introduced.
The practical result was that someone could own high-quality equipment with a suitable Common Interface or another standardised connection and still be forced to use a receiver supplied by the network operator. The smartcard or other access mechanism could not be used directly in the owner’s equipment even though that equipment had been designed for precisely that purpose. The signal first had to pass through the operator’s limited decoder and then, for example, through SCART, S-Video or composite into a much better television or installation. It was therefore not the technical standard but the network operator that determined which equipment the owner could actually use.
This distinction is important to Repair and Ownership. An open standard or physically compatible connector means little when a party deliberately adds an unnecessary deviation in order to exclude alternative equipment. Interoperability therefore concerns not only connectors and protocols, but also whether those standards may actually be used without artificial access conditions.
The same ownership question later reappears with chargers, printer components, diagnostic equipment, smart-home protocols, accessories and software formats. When a product can technically interoperate with alternatives but software, registration, cryptographic keys or other artificial restrictions prevent it from doing so, the owner retains less practical control over the product than the physical purchase suggests.
Ownership and preservation do not concern hardware alone. Early browser games already demonstrated that digital software could disappear completely from users’ reach even when there was no central game server that was later simply switched off. An important example was games and interactive applications created using Macromedia Director and run in the browser through the Shockwave Player, later Adobe Shockwave Player.
Shockwave also worked with extensions known as Xtras. A Director production could depend on particular Xtras for graphics, sound, 3D or other functions. These extensions did not all need to be installed on the computer in advance: a Shockwave production could specify which Xtras it required and have them downloaded when needed. A game therefore did not necessarily consist of one standalone file that could simply be preserved. Running it later might also require the correct Shockwave version, the required Xtras and other parts of the original environment.
There was another issue as well. Some browser games were deliberately published in such a way that saving the game file from the browser cache or website and then opening it locally on the computer was not sufficient. The file could still physically exist, but the application had been designed to function correctly only when loaded from the intended website environment. A user could therefore possess a copy of the actual game file while still lacking an independently usable copy.
When the provider subsequently removed the game from the website, what disappeared was not necessarily a server continuously running the game world. Access disappeared because the publication itself had been removed, required components such as Xtras were no longer available, or the software had deliberately been made dependent on the original web environment. At the same time, that web environment was itself part of the business model: advertisements could be displayed around the game for as long as the user played through the website. An independently usable local copy would break that dependency.
This makes it an important early example for Repair and Ownership. A digital work could be executed entirely on the user’s own computer and still be distributed in such a way that the user could not retain an independently usable copy. The technical ability to run software locally did not therefore automatically mean that the user had the practical ability to preserve it and use it again later.
Flash games and other browser technologies later encountered related problems, but the Director/Shockwave model demonstrates at an early stage that digital impermanence does not arise only when a modern cloud server is shut down. Software can also disappear because distribution, extensions and the execution environment have deliberately been tied together in such a way that a locally preserved file is not sufficient by itself.
The same questions also extend to privacy and control over data. During the years in which large-scale electronic communication, centralised patient records and European rules on the retention of communications data were emerging, it became increasingly visible that technical systems determine not only what a user can do, but also what organisations can collect, retain, combine and retrieve about that user.
This is not the same subject as repairing a device, but the underlying question of control is related. Who determines what a technical system does? Which information is available to the user themselves? Which information instead goes to others? Which choices are technically necessary and which arise from policy, contracts or design decisions?
Ownership thereby comes close to responsibility. Greater control means not only greater freedom to change a system, but also a responsibility to consider security, the privacy of others, consequences for other people and the circumstances in which a modification is used.
The current Right to Repair movement overlaps with an important part of Repair and Ownership. Access to parts, tools, schematics, diagnostic functions, firmware and repair information is essential if owners and independent repairers are genuinely to be able to maintain products.
The modern organised movement around digital electronics gained increasing visibility from the 2010s onwards, and the discussion became widely recognisable around smartphones, laptops and other consumer electronics. The same issues now arise explicitly with vehicles, agricultural machinery, household appliances, cameras and many other products.
Repair and Ownership did not arise from that movement, however, and it is not identical to it. The project asks a broader question. A device can be highly repairable and still provide little practical control if its owner is not permitted to install their own software, remains dependent on a cloud account, can lose features remotely or can access purchased digital content only for as long as a third party continues to grant permission.
Right to Repair is therefore an important part of the ownership question, but it is not the entire ownership question.
For Repair and Ownership, practical ownership does not mean that every technical restriction is automatically wrong or that every owner should be able to change everything without knowledge, responsibility or consequences. A braking system, medical installation, high-voltage device or security system imposes different requirements from a desk lamp or media player.
Safety, liability, the privacy of others, interoperability and legal requirements can impose legitimate boundaries. The important distinction is whether a restriction is necessary and explainable, or is primarily used to enforce dependency, exclude competition or retain control over a product after it has been sold.
Freedom and responsibility therefore belong together. Genuine control requires access to knowledge and possibilities, but also sufficient understanding to make deliberate choices and accept their consequences.
Repair and Ownership is a project of ASK-Solutions. The project gives practical form to questions that have been important within the foundation from the beginning: what freedom and ownership mean, how knowledge can affect power and dependency, what responsibilities accompany independence and how much control people and organisations should be able to retain over the systems in their lives.
Technology makes these questions particularly visible. A technical system forces abstract concepts into concrete choices. Is documentation available or secret? Can a component be replaced or only paired by the manufacturer? Does a device work without an internet connection? Who holds the key that determines which software is allowed to run? Can someone investigate a fault? Who decides when a product is no longer supported?
Other ASK-Solutions projects can encounter parts of the same questions from their own objectives and practical form. Bōzuki, for example, explores in practice what it means to understand, modify and document a complex vehicle. At locations where ASK-Solutions implements the shareable work model of the project The Owl’s Nest, repair, investigation and knowledge transfer can take practical form. Free-software projects such as Nocterra demonstrate in another field why access to source code, transferability and independence from a single supplier can matter.
Those projects are not parts of Repair and Ownership. From their own project objectives, however, they can provide concrete situations in which the same questions concerning knowledge, dependency, repair and ownership become visible.
Repair and Ownership is an ongoing project. The underlying questions change alongside technology, legislation, contractual forms and business models. Where restrictions once appeared, for example, as missing schematics or closed service networks, they may now also be embedded in firmware, accounts, cloud platforms, cryptographic keys, digital licences and subscriptions.
ASK-Solutions follows such developments, discusses and documents examples, supports initiatives concerning user rights and repair where appropriate, and uses practical projects to investigate what technical control means in concrete situations.
Copyright © 2026, ASK-Solutions
