Hello, First of all, I'm CCing the debian-legal mailing list for opinions on the license issues. Debian-legal people: please ignore the building stuff at the end of the mail. On Tue, Jul 10, 2007 at 10:55:30PM +0200, Borut Razem wrote: >> In doc/readme, it says: >> License: >> SDCC is licensed under the GNU Public license (GPL) v2. Note >> that this license covers the code to the compiler and other >> executables, but explicitly does not cover any code or objects >> generated by sdcc. We have not yet decided on a license for the >> run time libraries, but it will not put any requirements on code >> linked against it. See: >> http://www.gnu.org/copyleft/gpl.html >> >> I suppose the link is about the fact that SDCC itself is licensed under >> the GPL (however, with the release of GPL3, this link no longer points >> to the license of the program, which is v2 only). >> > The majority of SDCC compiler code is covered by GPL "either version 2, or > (at your option) any later version." Ok, in that case the link is fine, as it points to the latest version of the GPL (which always fits "2 or later"). > The asxxxx and aslink, which are distibuted as a part of "sdcc siute" are > public domain software: > > The ASxxxx assemblers and the ASLINK relocating linker are > placed in the Public Domain. Publication or distribution of > these programs for non-commercial use is hereby granted with the > stipulation that the copyright notice be included with all > copies. That is a contradiction. Putting something in the Public Domain means disclaiming copyright on the work. If that is indeed what was intended, then there is no need to grant anything, since there is no copyright anymore, and no permission is needed from anyone. However, seeing what is granted, it is very doubtful if the intention is indeed to put it in the public domain. "non-commercial" is a serious restriction, which can (of course) only be placed on the work by the copyright holder. If the author wants this restriction, then he or she automatically doesn't want to put it in the Public Domain. Strictly speaking, the above does put the work in the Public Domain. If the statement legally is valid even if the intention is unclear, the stated restrictions are meaningless. I'd especially like input from debian-legal about this: With this statement, is the software indeed placed in the Public Domain? >> We need to know the license of the run-time libraries. I suppose it >> will be nice and free, but we can't distribute it if it is unclear like >> this. >> > The run-time library is the most problematic part: some sources are GPL, > some LGPL, some without license (see > http://sdcc.wiki.sourceforge.net/SDCC+Library+Licenses). We (sdcc > developers) are trying to make some order and to unify the sdcc run-time > license to one which permits to use the compiled library in closed source / > proprietary projects. Curretntly the most promising is GPL + Runtime > Extension, but we haven't got the agreement from all authors yet (see > http://sdcc.sourceforge.net/wiki/index.php?page=Library+License+Selection). Ok. I think that it is acceptable to ignore the problem for the moment then, and hope that it gets solved soon. (Strictly speaking, I suppose the run-time library can be considered GPL without extention, which may be unfortunate, but certainly free according to Debian.) >> Furthermore, we want to build the package from real source, which means >> regenerating configure and Makefile.in (where applicable). For this, we >> use the following commands: >> >> export AUTOMAKE=automake-1.10 >> export ACLOCAL=aclocal-1.10 >> autoreconf --force --install --symlink >> >> This gives some warnings (which I ignore, although you may want to fix >> the ones in your code) and the following errors: <---- snip errors ----> >> (although autoheader calls them warnings, they do prevent it from >> producing output). >> > You have to run configure and then make, as described in sdccman, chapter > 2.4.1 Building SDCC on Linux. Yes, I know that works, but we want to regenerate configure as well. Debian is committed to providing free software to its users. To the users, that means (among other things) they can change the software they get. To make any use of this ability, they need to be able to build the changed version. Debian (source) packages contain build rules which do that. When they make changes, they can simply run the build scripts to generate a new package which contains their changes. Nothing new so far I suppose. :-) However, there is a problem if we just run configure instead of regenerating it. If the user makes changes to configure.in, for example, then those changes aren't used if configure isn't regenerated. Given that we currently aren't able to regenerate it, I don't think we can expect users to figure out for themselves how to do it. I hope that explains the question. Thanks again, Bas Wijnen -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature