All, I am working on creating ports for a few applications. I have created and submitted my first one just yesterday (libelf-0.8.9). I am now working on my second (dynamips-0.2.7), but have a few questions I'm hoping someone can answer (not all relating to just dynamips-0.2.7). 1) I have successfully created a variant of dynamips using pcap. The process was rather simple. However, I am debating the creation of a third variant. A third party developer has created a source code patch that extends a certain function of dynamips in a useful way. Is it appropriate to include such a third party modification as a variant to a port? 2) In the case above, the third party patch file is written to be applied from the directory above the source code (I think this would be called the work directory) and not from inside the dynamips-0.2.7 directory created when the tarball is extracted. The best I can figure is that the patching phase does apply the patch while in this source directory (dynamips-0.2.7) and not from the work directory. It is possible to make it apply the patch from the work directory so that I do not have to modify the third party patch file for this variant? 3) The third party patch is licensed under the GPLv2 license. Are there any general concerns that I should worry about in either case where I use the patch file as is or in the case where I modify it? 4) If I cannot patch from the work directory, is it considered OK to modify the third party patch file to support patching from inside the dynamips-0.2.7 directory? 5) What is the best practice to make sure that during all the steps I am only referencing libraries and dependencies from the macports system and not accidentally compiling against pre-installed system libraries? I have run "port -d install foo" and read through the output, but I want to double check that I am not missing anything. I realize the above questions may be somewhat basic, but I'm hoping that armed with the answers I can make some valuable contributions to the vast library of ports available. Thanks! -- Jonathan Strine PGP Key ID: 0x0A02201C
Hi Jonathan, On 02.09.2007, at 22:35, Jonathan Strine wrote:
All,
I am working on creating ports for a few applications. I have created and submitted my first one just yesterday (libelf-0.8.9). I am now working on my second (dynamips-0.2.7), but have a few questions I'm hoping someone can answer (not all relating to just dynamips-0.2.7).
1) I have successfully created a variant of dynamips using pcap. The process was rather simple. However, I am debating the creation of a third variant. A third party developer has created a source code patch that extends a certain function of dynamips in a useful way. Is it appropriate to include such a third party modification as a variant to a port?
Absolutely. If you find it useful and no is bashing you for that (e.g. because it breaks ports that depend on it), go ahead!
2) In the case above, the third party patch file is written to be applied from the directory above the source code (I think this would be called the work directory) and not from inside the dynamips-0.2.7 directory created when the tarball is extracted. The best I can figure is that the patching phase does apply the patch while in this source directory (dynamips-0.2.7) and not from the work directory. It is possible to make it apply the patch from the work directory so that I do not have to modify the third party patch file for this variant?
you could either modify the patch-directory via 'patch.dir $ {worksrcpath}/foo/bar/' or just create a new patch via diffing the original and the patches sources from the base dir;
3) The third party patch is licensed under the GPLv2 license. Are there any general concerns that I should worry about in either case where I use the patch file as is or in the case where I modify it?
No problems for us. It'll only hit the people who link against the new product. We will happily distribute GPLed code (as long as port itself is not mixed with it).
4) If I cannot patch from the work directory, is it considered OK to modify the third party patch file to support patching from inside the dynamips-0.2.7 directory?
yes, sure; GPLed code may be modified and distributed by us (see above).
5) What is the best practice to make sure that during all the steps I am only referencing libraries and dependencies from the macports system and not accidentally compiling against pre- installed system libraries? I have run "port -d install foo" and read through the output, but I want to double check that I am not missing anything.
It currently may be broke, but we do have 'trace' mode which can be activated with the '-t' switch. It'll tell you about all ports that your port touches during its build. For checking after you build it, I recommend a simple 'find' command like #> find work/destroot -type f | xargs otool -L 2>&1 | sort -u That'll tell you all libs that the files in destroot link against. Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ --- Markus W. Weissmann http://www.mweissmann.de/
Markus, Thank you very much for the answers, but I am left with one more question. Does the statement quoted below mean that as long as the patch *and* the base port (that is the main program, dynamips) are both GPL, then everything is OK? If I understand GPL correctly I cannot redistribute a patched version of of a non-GPL program (even if the patch is GPL) since that would "break" the license? Am I correct in the above? -- Jonathan Strine PGP Key ID: 0x0A02201C On Sep 2, 2007, at 6:03 PM, Weissmann Markus wrote:
We will happily distribute GPLed code (as long as port itself is not mixed with it).
On 03.09.2007, at 00:15, Jonathan Strine wrote:
Markus,
Thank you very much for the answers, but I am left with one more question. Does the statement quoted below mean that as long as the patch *and* the base port (that is the main program, dynamips) are both GPL, then everything is OK? If I understand GPL correctly I cannot redistribute a patched version of of a non-GPL program (even if the patch is GPL) since that would "break" the license?
Am I correct in the above?
well, the deal is that macports will only distribute the patch and the user will create the patched version on his machine only - so for macports everything should be just fine. The thing with GPLed code is, that it is viral, so everything you link against it (or mix with it) will get GPLed code, too. I'm not quite sure what if you do not own the original source (e.g. it is BSD licensed), but I assume that everyone will be happy as long as the viral effect of the GPL is kept and you distribute the source code along a binary. Long story short: MacPorts only makes the patch available and not the patched software, so there is no problem for us (as long we don't distribute packages). For the rest, a lawyer should be contacted or even better: Someone should ask the author of the patch why he/she is not playing nice and not using the license of the original code. -Markus --- Markus W. Weissmann http://www.mweissmann.de/
Weissmann Markus wrote:
2) In the case above, the third party patch file is written to be applied from the directory above the source code (I think this would be called the work directory) and not from inside the dynamips-0.2.7 directory created when the tarball is extracted. The best I can figure is that the patching phase does apply the patch while in this source directory (dynamips-0.2.7) and not from the work directory. It is possible to make it apply the patch from the work directory so that I do not have to modify the third party patch file for this variant?
you could either modify the patch-directory via 'patch.dir ${worksrcpath}/foo/bar/' or just create a new patch via diffing the original and the patches sources from the base dir;
There is also the possibility to use: patch.pre_args -p1 But I think this would apply to all patchfiles. Rainer
On 2007-09-03 00:27:44 +0200, Weissmann Markus wrote:
The thing with GPLed code is, that it is viral, so everything you link against it (or mix with it) will get GPLed code, too. I'm not quite sure what if you do not own the original source (e.g. it is BSD licensed), but I assume that everyone will be happy as long as the viral effect of the GPL is kept and you distribute the source code along a binary.
AFAIK, the BSD license allows you to create a derived work that would be distributed under the GPL. Owning the original source is necessary only if you want to change the license in an incompatible manner (e.g. you created a work which you distributed under the GPLv2 and you want to distribute a future version under the GPLv3+). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Vincent Lefevre wrote:
AFAIK, the BSD license allows you to create a derived work that would be distributed under the GPL. Owning the original source is necessary only if you want to change the license in an incompatible manner (e.g. you created a work which you distributed under the GPLv2 and you want to distribute a future version under the GPLv3+).
GPLv2 is not necessarily incompatible with GPLv3. GPL lets the original author choose how new versions apply to the software. See paragraph 9 of the GPLv2 [1]. --snip-- | Each version is given a distinguishing version number. If the Program | specifies a version number of this License which applies to it and "any | later version", you have the option of following the terms and conditions | either of that version or of any later version published by the Free | Software Foundation. --snap-- [1] http://www.gnu.org/licenses/gpl-2.0.html So if a software supplies the phrase "either version 2 of the License, or (at your option) any later version." then I think it can be used and redistributed under the Terms of GPLv3. IANAL, that's just how I understand it. Rainer
On 2007-09-04 00:38:15 +0200, Rainer Müller wrote:
GPLv2 is not necessarily incompatible with GPLv3.
It is.
GPL lets the original author choose how new versions apply to the software. See paragraph 9 of the GPLv2 [1].
--snip-- | Each version is given a distinguishing version number. If the Program | specifies a version number of this License which applies to it and "any | later version", you have the option of following the terms and conditions | either of that version or of any later version published by the Free | Software Foundation. --snap--
If you choose "or any later version", this is no longer GPLv2 (which means GPL version 2 only), but GPLv2+ (with the more-or-less official notation). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (4)
-
Jonathan Strine
-
Rainer Müller
-
Vincent Lefevre
-
Weissmann Markus