Re: ia64 port
On Thursday 25 May 2000, at 23 h 40, the keyboard of Joey Hess
<[EMAIL PROTECTED]> wrote:
> SourceForge now has 3 ia64 boxes, and they are letting people submit
> proposals to get access to them to port stuff.
You have to a registered user of SourceForge. Not a big deal but I prefer to
mention it.
> I suggest we submit a proposal to port Debian base. ;-) What do people think?
And there is a legal problem first. What do people on debian-legal think of the
agreement you have to sign:
OPEN-SOURCE CLICKWRAP IPLA
Intel would like to invite you to participate in Intel's efforts
to prepare software targeted for the Linux
operating system running on the Intel(R) Itanium(tm) processor by
providing you access to software created
by Intel and its licensors and related documentation and
materials (the "Intel Software") and Intel supplied
equipment ("Intel Equipment") under the following terms and
conditions:
1. To the extent that you are using software that is not supplied
by Intel and/or its licensors such as the Linux
operating system and the GCC compiler, this Agreement has no
effect on your rights and your use of that
software is subject to the applicable license such as the Gnu
General Public License or other applicable
license.
2. This license to use the Intel Software and Intel Equipment is
being provided to you royalty-free, in
consideration of your adherence to the other terms and conditions
of this license. You may distribute
software that you create ("Your Software") using this equipment
through any distribution scheme you wish to
use, including distributing Your Software under an open source
license agreement such as the Gnu General
Public License or distributing binaries of Your Software for a
fee and subject to a different license.
3. You may modify portions of the Intel Software provided by
Intel as sample source code and incorporate
such sample source or modified portions thereof into your
programs and may distribute Your Software
incorporating sample source code or modifications thereof under
any license agreement of your choosing.
You may not reverse engineer, decompile, license or disassemble
portions of any Intel Software provided in
object code form.
4. Since the Intel Equipment that you are using is pre-release
hardware and incorporates pre-release software
and is configured to permit multiple people to test code on the
equipment, this equipment will not generate
reliable benchmarking data. I understand that no reliable
benchmarking data can be generated on the Intel
Equipment. Therefore, you agree that you will not disclose
publicly or share with any third party any
benchmarks generated using the Intel Equpment and/or Intel
Software.
5. The Intel Software provided in binary form contains
confidential information of Intel regarding technical
aspects of the Itanium processor. You must use the same degree of
care to protect this confidential
information of Intel that you use to protect your own
confidential information, but no less than a reasonable
degree of care. You must restrict access to the Intel Software
provided in binary form to your employees who
have executed written agreements with you obligating them to
protect confidential information as required
under this paragraph. The obligations of this paragraph do not
apply to any information that is or becomes
published by Intel without restriction, or otherwise becomes
rightfully available to the public other than by
breach of confidentiality obligation to Intel.
6. THE SOFTWARE AND EQUIPMENT IS PROVIDED BY INTEL AND ANY
EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND
NON-INFRINGEMENT ARE
DISCLAIMED. IN NO EVENT SHALL INTEL BE LIABLE FOR ANY DIRECT,
INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THE SOFTWARE,
EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
7. You may provide to Intel additional feedback regarding the
Intel Software and/or the Intel Equipment,
including suggested
Re: ia64 port
I think the license is basically pretty good, but clause 5 is a showstopper. Given Intel's track record on trying to prevent disclosure of advanced features of their CPUs, such as the infamous "Appendix H" mess with the Pentium, anyone who agreed to this sort of a confidentiality clause might be effectively prohibited from working on any Open Source software which might have some relationship to the confidential areas. Of course, since you -- by definition -- do not find out the scope of the confidential material until after you sign the license agreement, you have no way of knowing what range of Open Source projects you might be prohibited from working on in the future. A reasonable inference would be that the Linux kernel, video software, multimedia software, and possibly mathematical computation software could all touch on one or more areas which are relevant to the confidential materials. If someone did agree to this clause and then contributed to an Open Source project with relevance to the confidential materials, then it seems likely that the Open Source project would be potentially poisoned by the breach, and in theory others who innocently acquire knowledge of the confidential materials without knowing of their confidential nature could also be contaminated to the point where they would be unable to continue with the project in any meaningful way. In general, I think it would be inconsistent with Debian's stated purpose and policy to undertake any action which relies upon information which is explicitly stated to be confidential, and that it is the essence of the Open Source concept to rely only upon openly documented public interfaces to hardware or upon those interfaces which can be forced into the public domain through reverse engineering. Put more simply, if Intel wants Open Source operating systems and software to run on their CPU, then they are going to have to document how their CPU works. If the only advantage to getting this confidential information is early access to the hardware, since they are eventually going to be selling their chips to the public, then it is not worth it. -- Mike On 2000-05-26 at 09:15 +0200, Stephane Bortzmeyer wrote: > And there is a legal problem first. What do people on debian-legal think of > the agreement you have to sign: > > OPEN-SOURCE CLICKWRAP IPLA * * * > 5. The Intel Software provided in binary form contains > confidential information of Intel regarding technical > aspects of the Itanium processor. You must use the same degree > of care to protect this confidential > information of Intel that you use to protect your own > confidential information, but no less than a reasonable > degree of care. You must restrict access to the Intel Software > provided in binary form to your employees who > have executed written agreements with you obligating them to > protect confidential information as required > under this paragraph. The obligations of this paragraph do not > apply to any information that is or becomes > published by Intel without restriction, or otherwise becomes > rightfully available to the public other than by > breach of confidentiality obligation to Intel.
Re: ia64 port
Mike Bilow wrote: > I think the license is basically pretty good, but clause 5 is a > showstopper. Clause 5: 5. The Intel Software provided in binary form contains confidential information of Intel regarding technical aspects of the Itanium processor. You must use the same degree of care to protect this confidential information of Intel that you use to protect your own confidential information, but no less than a reasonable degree of care. You must restrict access to the Intel Software provided in binary form to your employees who have executed written agreements with you obligating them to protect confidential information as required under this paragraph. The obligations of this paragraph do not apply to any information that is or becomes published by Intel without restriction, or otherwise becomes rightfully available to the public other than by breach of confidentiality obligation to Intel. Hm, as I read this, said confidential information is all contained in some binaries. If you don't look in the binaries, and you don't distribute the binaries, or distribute code linked to the binaries, have you not complied with all their obligations without infecting yourself? -- see shy jo
Re: stance on QPL 2 / GPL/LGPL license usage
On Thu, May 25, 2000 at 02:35:30AM -0700, Joseph Carter wrote: > On Thu, May 25, 2000 at 01:59:10AM -0700, Ivan E. Moore II wrote: > > What is the current stance on programs that bind to qt 2.x which is using > > the QPL 2.0 license and are GPL'd or LGPL'd? > > Qt 2.0 with LGPL, no problem > Qt 2.0 with GPL, problem > > Same stance, has never changed. The GPL does not allow linking with Qt > 2.0. The people who write GPL apps using Qt 2.0 know this by now. KDE > knows it, that's for damned sure. Those authors who care have added the > necessary permissions. KDE hasn't and won't because then they'd have to > give up being able to use GPL'd code. ok...unixODBC say's this: * All programs are GPL. * * All libs are LGPL so..based on what your saying, the libs could go into main, but the programs would be non-free...(or just not distributed)... and the source could go into mainsince the interreaction of the gpl and qpl is in the .deb form...and not the source form. that sound logical? Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: ia64 port
I think this is dangerous. In the worst case, confidential information could be contained in the mere existence of the binaries. For example, suppose Intel has invented a new and secret floating point unit, the "xo4" array processor. Intel gives you a program called "xo4.exe" which they tell you will dramatically improve floating point performance when you run it over your source code, and after doing so you will have to link to the "xo4.dll" file which they also supply. I can easily foresee a number of secret capabilities which the CPU might possess which would be revealed by the existence of binaries, especially as these binaries will likely have to be documented to be useful. For example, suppose that you get a binary called "powerpc.exe" and they bluntly tell you that this enables hardware emulation of the PowerPC CPU, but that the existence of this capability is a strict secret. As I said earlier, given the "Appendix H" strangeness where Intel tried to make a trade secret out of the "VME" bit, anything is possible. It would be really hard to make something like WINE work, to cite an obvious example, if you are prohibited from using the "VME" bit because you are not allowed to disclose its existence. -- Mike On 2000-05-26 at 02:20 -0700, Joey Hess wrote: > Hm, as I read this, said confidential information is all contained in some > binaries. > > If you don't look in the binaries, and you don't distribute the binaries, or > distribute code linked to the binaries, have you not complied with all their > obligations without infecting yourself?
Re: stance on QPL 2 / GPL/LGPL license usage
On Fri, May 26, 2000 at 02:22:41AM -0700, Ivan E. Moore II wrote: > > > What is the current stance on programs that bind to qt 2.x which is using > > > the QPL 2.0 license and are GPL'd or LGPL'd? > > > > Qt 2.0 with LGPL, no problem > > Qt 2.0 with GPL, problem > > > > Same stance, has never changed. The GPL does not allow linking with Qt > > 2.0. The people who write GPL apps using Qt 2.0 know this by now. KDE > > knows it, that's for damned sure. Those authors who care have added the > > necessary permissions. KDE hasn't and won't because then they'd have to > > give up being able to use GPL'd code. > > ok...unixODBC say's this: > >* All programs are GPL. * >* All libs are LGPL > > so..based on what your saying, the libs could go into main, but the programs > would be non-free...(or just not distributed)... Since I have no idea what the HELL you're talking about, I can only assume you're talking about mixing GPL and LGPL licenses. If you are, I suggest reading the LGPL sometime. > and the source could go into mainsince the interreaction of the gpl and > qpl is in the .deb form...and not the source form. > > that sound logical? Not without the slightest clue what you're talking about, no. -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 C'mere, come smell the door. -- Tracey Luke
Re: stance on QPL 2 / GPL/LGPL license usage
On Fri, May 26, 2000 at 03:40:27AM -0700, Joseph Carter wrote: > On Fri, May 26, 2000 at 02:22:41AM -0700, Ivan E. Moore II wrote: > > > > What is the current stance on programs that bind to qt 2.x which is > > > > using > > > > the QPL 2.0 license and are GPL'd or LGPL'd? > > > > > > Qt 2.0 with LGPL, no problem > > > Qt 2.0 with GPL, problem > > > > > > Same stance, has never changed. The GPL does not allow linking with Qt > > > 2.0. The people who write GPL apps using Qt 2.0 know this by now. KDE > > > knows it, that's for damned sure. Those authors who care have added the > > > necessary permissions. KDE hasn't and won't because then they'd have to > > > give up being able to use GPL'd code. > > > > ok...unixODBC say's this: > > > >* All programs are GPL. * > >* All libs are LGPL > > > > so..based on what your saying, the libs could go into main, but the programs > > would be non-free...(or just not distributed)... > > Since I have no idea what the HELL you're talking about, I can only assume > you're talking about mixing GPL and LGPL licenses. If you are, I suggest > reading the LGPL sometime. unixODBC is a software package made up of libraries and a few apps which use those libraries. The libraries are LGPL'd and the apps are GPL'd. They are also linked to libqt2.1. I'm trying to find out if packages I create can be uploaded to Debian or not. :) Ivan -- Ivan E. Moore II [EMAIL PROTECTED] http://snowcrash.tdyc.com GPG KeyID=90BCE0DD GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD
Re: stance on QPL 2 / GPL/LGPL license usage
On Fri, May 26, 2000 at 03:47:10AM -0700, Ivan E. Moore II wrote: > > > ok...unixODBC say's this: > > > > > >* All programs are GPL. * > > >* All libs are LGPL [..] > > unixODBC is a software package made up of libraries and a few apps which use > those libraries. The libraries are LGPL'd and the apps are GPL'd. They > are also linked to libqt2.1. > > I'm trying to find out if packages I create can be uploaded to Debian or not. > :) Not. =< The binaries can't be uploaded without specific exemptions for Qt and any GPL'd apps that link the libs are going to have the same problem. This is precisely what Troll Tech won't fix and KDE wants to ignore. -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 Caveats: it's GNOME, be afraid, be very afraid of the Depends line -- James Troup
Re: When will KDE and Debian get together?
On Thu, May 25, 2000 at 08:53:06AM -0700, Alan W. Irwin wrote: > I applaud these compromises, Well, then, you just don't have the Debian attitude... :) -- G. Branden Robinson| To stay young requires unceasing Debian GNU/Linux | cultivation of the ability to unlearn [EMAIL PROTECTED] | old falsehoods. roger.ecn.purdue.edu/~branden/ | -- Robert Heinlein pgp0dlEajP1c2.pgp Description: PGP signature
Re: stance on QPL 2 / GPL/LGPL license usage
Today, Joseph Carter wrote: > On Fri, May 26, 2000 at 03:47:10AM -0700, Ivan E. Moore II wrote: > > > > ok...unixODBC say's this: > > > >* All programs are GPL. * > > > >* All libs are LGPL > > unixODBC is a software package made up of libraries and a few apps which use > > those libraries. The libraries are LGPL'd and the apps are GPL'd. They > > are also linked to libqt2.1. > > I'm trying to find out if packages I create can be uploaded to Debian or > > not. > Not. =< The binaries can't be uploaded without specific exemptions > for Qt and any GPL'd apps that link the libs are going to have the > same problem. This is precisely what Troll Tech won't fix and KDE > wants to ignore. By the way, should the shared libs also have the exception for Qt? -- Jean-Christophe Dubacq
Re: Silly observation...
Scripsit Nicolás Lichtmaier <[EMAIL PROTECTED]> > If we see "License: GPLv2 or greater" we know it's DFSG compliant. > But... look: "License: latest GPL version" is not! Is anyone releasing software with that license specification? -- Henning Makholm "Lucy giver mig en smule af sin vandration. Hun siger, piger ikke bliver så tørstige som drenge. Jeg har tit selv tænkt dette, men det burde være noget søfolk blev bedre orienteret om."
Re: stance on QPL 2 / GPL/LGPL license usage
On Fri, May 26, 2000 at 01:21:53PM +0200, Jean-Christophe Dubacq wrote: > > Not. =< The binaries can't be uploaded without specific exemptions > > for Qt and any GPL'd apps that link the libs are going to have the > > same problem. This is precisely what Troll Tech won't fix and KDE > > wants to ignore. > > By the way, should the shared libs also have the exception for Qt? LGPL doesn't require it, but it can't hurt. (This makes 11 for the people counting on irc..) -- Joseph Carter <[EMAIL PROTECTED]> GnuPG key 1024D/DCF9DAB3 Debian GNU/Linux (http://www.debian.org/) 20F6 2261 F185 7A3E 79FC The QuakeForge Project (http://quakeforge.net/) 44F9 8FF7 D7A3 DCF9 DAB3 Fuck, I can't compile the damn thing and I wrote it !
Re: stance on QPL 2 / GPL/LGPL license usage
Today, Joseph Carter wrote: > On Fri, May 26, 2000 at 01:21:53PM +0200, Jean-Christophe Dubacq wrote: > > > Not. =< The binaries can't be uploaded without specific exemptions > > > for Qt and any GPL'd apps that link the libs are going to have the > > > same problem. This is precisely what Troll Tech won't fix and KDE > > > wants to ignore. > > By the way, should the shared libs also have the exception for Qt? > LGPL doesn't require it, but it can't hurt. > (This makes 11 for the people counting on irc..) I got the impression that to be linked with a GPL app and distributed as such, it is required that one uses the GPL conversion clause. And to be later linked with libqt, it requires that it is converted to GPL with libqt exception clause. IMHO, pure LGPL is not good enough for static binaries. That's if I got the LGPL right, altough I am not so sure now. Well, I might be a bit paranoid. And sorry for not being able to IRC... -- Jean-Christophe Dubacq
Re: ia64 port
Mike Bilow wrote: > I think this is dangerous. In the worst case, confidential information > could be contained in the mere existence of the binaries. For example, > suppose Intel has invented a new and secret floating point unit, the > "xo4" array processor. Intel gives you a program called "xo4.exe" which > they tell you will dramatically improve floating point performance when > you run it over your source code, and after doing so you will have to link > to the "xo4.dll" file which they also supply. This is a nice hypothetical, but here's a quote from VA's Chris DiBona that I read on slashdot (http://slashdot.org/article.pl?sid=00/05/26/1251258&mode=nested) The only code that is from Intel in object code form is the BIOS and motherboard controller firmware. There is no other object code on the system. The IA-64 Linux kernel is completely open and has been out of NDA and licensed under the GPL since February. Do you still have concerns? If so, I'd like to just forward them to Chris for comments. Is anyone else actually interested in getting started on this port? I personally feel that the agreement is something I can sign without feeling unduly encumbered by it. This is probably something other developers have to decide for themselves (unless you have a lawyer to help you ;-). If there are enough developers who feel comfortable with it, I think we should go ahead and get started. -- see shy jo
Re: stance on QPL 2 / GPL/LGPL license usage
On Fri, May 26, 2000 at 02:38:32PM +0200, Jean-Christophe Dubacq wrote: > I got the impression that to be linked with a GPL app and distributed > as such, it is required that one uses the GPL conversion clause. I don't think you got this impression by reading the text of the license -- the license clearly states that converting the LGPL to the GPL is an option. And, the license clearly indicates that the purpose of this option is so that authors of GPLed code can incorporate LGPLed code into their programs without forcing them to weaken the license on their programs. So you must have gotten this impression from somewhere else. -- Raul
