On Sat, Nov 5, 2011 at 7:27 AM, Ross Gardler <rgard...@opendirective.com> wrote: > In order to graduate there can be no license incompatible code in SVN. The > solution below is ok only as an interim solution. >
This statement conflicts with what I thought Robert had told us previously. My impression from that discussion was that the license of what was in the *release* was what mattered. But using GPL build tools was itself not a problem, unless that triggered a dependency in the release. Remember, there are no pure Apache 2,0 licensed operating systems. So every application Apache releases, if it goes beyond the facilities of the programming language, will have some platform dependencies. For C/C++ the programming language gives us memory allocation and file I/O. That's it. Everything else we do will require the use of system header files and libraries, system build tools, etc. At that point it is not a question so much of license but of developer notification, of developer convenience and of build reproducibility: 1) We need to make sure that the developer is explicitly made aware of any additional licenses that govern the use of their work 2) If we have a choice between requiring the developer to download 20 pieces of code manually from 20 different web sites, and giving them an easier way to do this, while still requiring explicit notification per above, then we should be convenient. As far as I can tell, being hard to use does not advance any Apache licensing or other goal. 3) Relying on code hosted externally from our SVN puts us at risk of that code being lost, of it changing URL's the original author dying, etc. The web decays. Our SVN does not. Even for our own ability to reproduce a year-old build in order to patch it for a security patch, it is necessary that we can reassemble all the sources, including build tools under GPL, in a coherent, consistent form. So I think, just form the engineering perspective, that this recommends storing all non-platform build dependencies in SVN, regardless of license. So I'd like to push back on Ross's assertion a little, and see what principles are really at stake, and explore what else might be possible., -Rob > Sent from my mobile device (so please excuse typos) > > On 4 Nov 2011, at 15:38, Oliver-Rainer Wittmann <orwittm...@googlemail.com> > wrote: > >> Hi, >> >> our build tool dmake is licensed under GPL. >> Thus, it can not be part of our source releases. >> But, we can use it for building - as we are using the gcc compiler. >> >> Thus, I will move the dmake source folder from .../ooo/trunk/main/ to new >> folder .../ooo/buildtools/ in order to assure that everything under >> .../ooo/trunk/ can become part of our source release. >> >> In order to get our bootstrap process still working it needs some adaption: >> I am planning to introduce a configure option in order to provide manually >> the path to the source folder of the build tool dmake - something like >> with-dmake=<$PATH to dmake folder>. If this option is not used, the default >> path ../../buildtools/dmake/ - relative from folder main - will be taken. >> The configure will then check, if this folder exists - the manual given one >> or the default. The bootstrap process will then work with this path to >> create the build tool dmake. >> >> Any objections? >> >> >> Best regards, Oliver. >
