On Sun, Dec 14, 2014 at 1:37 PM, Dennis E. Hamilton <[email protected]> wrote: > 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. > >
My impression is that Firefox does something similar. I think I read someplace that their source code distribution lacks the Firefox branding. It is more of a "white label" product, functionally the same as Firefox, but without the branding. But still, I don't think that really solves the problems that we face. Correct be if I'm wrong, but we're not really seeing someone doing their own compile of AOO from source code and using that to spread malware, right? We're seeing people take our binaries directly and bundle that with installers that spread the malware, or put up websites that charge and then point to AOO's binaries directly. In the end, the real harm here is done to the users. So I wonder whether the best we can do is make it easy for them to raise complaints with those who can take action, e.g, payment processors associated with credit cards or telephone networks, or even consumer authorities. -Rob > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
