I have been watching the arrival of support requests for AOO knock-offs on Android and plain-old PCs with some dismay. Some of this damage is self-inflicted: The Apache OpenOffice source code compiles to binaries that describes themselves and support structures as offered by Apache OpenOffice. That and the permissive license allows cloners to do whatever they want without consequences or support burdens, while extracting support fees (and add-cancellation upgrades), and whatever benefits there are for installing malware/adware alongside.
I ponder this dilemma from time to time and this is how I propose to produce open-source code under permissive licenses. Not that anything I produce will appeal to parasites as valuable to clone. It is the practice that intrigues me along with my interest in having ways to establish trustworthy producer-adopter relationships. Here's my thinking about how I would manage in the face of parasitic cloning where it is up to me. It would be more difficult for an Apache Top-Level Project, though not impossible. It does mean that convenience binaries are not identical to what can be produced using the source distribution alone, and the difference is apparent. This does not prevent counterfeiting of a supported binary distribution. It does allow counterfeits to be detected. It doesn't prevent distribution of unaltered binaries within a parasitic installer. It doesn't prevent redistributions for a fee. With regard to end-users, unaltered binaries are of-course supported. Other derivatives are not. Adopters of other derivatives will be treated gently in their searches for support. - Dennis PRESERVING DISTRIBUTION PROVENANCE AND AUTHENTICITY 1. The code will compile as a working/reference/developer binary. It will not provide signed binaries or anything that, shared as binaries, will provide identification as some sort of authenticated and supported end-user distribution. It will not come with any support notification or automatic updates, and it is meant for developers and testing, not end-user support of any kind. 2. The source tree will contain placeholder resources that are extracted and then used in a default build. To obtain other than a default build, the extractions of the placeholders can be replaced and the signing and time-stamping build-steps included in a construction. The versions of those resources for "official" distributions are not open-sourced and are introduced privately in a working copy, just as private keys are applied privately. This would be true for me, and for anyone else who wants to make some sort of official distribution of their own, whether the public source code is modified or not. 3. With regard to the "source code is the release" mantra, this is not a problem. Anyone can compile, use, and adapt the source code and produce their own binaries as much as they like. They just won't appear to be mine, unless someone intentionally does that. And it still won't be signed by me (unless there is a signing-key compromise, triggering a disaster-recovery plan). 4. Customizations of resources that are not shared include logos, icons, notices, update-check protocol data, etc. There will be identification of the source-code release that is used and appropriate inclusion of support details. There may have to be supplements to localization, internationalization and accessibility provisions, and that will take some work. There will be enough information in the source code and the documentation of the default resources so anyone can know what steps to take in providing their own customization. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
