Re: ITP: OpenNap -- Free Napster server
On Tue, Nov 28, 2000 at 04:53:45PM +0100, Arthur Korn wrote: It works great and is GPLed. Is it OK if this goes to main? I think so, but I'm not shure about some funny reverse-ingeneering laws in some not-so-free countries like the US. I don't think you have anything to worry about at the moment. Reverse engineering protections have kinda weird legal grounds anyway and there are reverse-engineered napster CLIENTS already. The people who would have to attempt to sue seem unlikely to. There doesn't appear to be a legal danger, and there's no need to invent our own dangers if we don't have to. -- 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 Joy wow... simple maths show that Debian developers have closed more than *31* *thousand* bug reports since our BTS exists! Joy that is about 30999 more than Microsoft ;)
Re: LICENSE of Adobe CMap files.
[ I'm not subscribed to this list, so please Cc: me. Thanks. ] At 28 Nov 2000 15:25:30 +0100, Henning Makholm wrote: Scripsit Yasuhiro TAKE [EMAIL PROTECTED] Well, i've heard that according to the International Copyright Law(or something like that), nothing is permitted unless explicitly declared as permitted in a license. This rule of thumb only holds for actions that are actually protected. Mere use of data is not protected and needs no permission (unless the particular use can *also* be construed copying, that is). Hmm. I see. Perhaps i was too much worried and suspective about the license. I'll announce ITP of cmap-files at debian-devel soon. If the ITP was rejected due to the license problem, At Tue, 28 Nov 2000 15:55:13 + (GMT), Jimmy O'Regan wrote: Is there any volunteer who writes an e-mail to Adobe instead of me? If you send me an e-mail address, I'll do it for you. I'll ask you to write the e-mail instead of me in that case. Thanks to you all about the information and the offer. -- Yasuhiro TAKE [EMAIL PROTECTED] / Debian Project I'd just be the catcher in the rye and all.
Integrity of Source Code
I wanted to enquire if clause #4 of the DFSG would allow a warning splash screen as follows: The program by default pops up a splash saying 'This is the official version of X obtainable in source and binary form from Y' - justs popups up for 3 seconds or something not to obnoxious. If the source code (not build parameters) are changed you are required to have the message popup with 'This is an UNOFFICIAL version of X. The official version can be obtained from Y.' - again for ~3 seconds. The makefile could even be doing a quick checksum of the source code (*.h and *.cc) files and comparing it to the release checksum to make it easy for people modifying the program - they don't have to hunt for where to change the message. So, adding a debian directory and changing build paths and parameters would not be modifying the source and so the 'this is official splash' would still be used. However, if the code had to be tweaked - something disabled, etc, that would make the program no longer the official upstream version. Obviously any changes to the source code that improve it's configurability or quality would be merged upstream. Further, we have no intention of inhibitting the free flow of modified version of the source or binaries, we merely want the user of derived works to be made aware that this is no longer a version approved by us although it is based off of work by us. So, supposed a third party distributing the program needed to modify some hard-coded path. They could do so and redistribute it with the splash automatically updated to warn that this was not the official version. They could then submit a change upstream that made the hard-coded path configurable, if the quality of the code is not degraded it's merged in and now the third party can rebuild using a configuration directive to change the path - and it's now an official version. Is this process legal and does it fit within the DFSG? We want this warning prominently visible b/c unless the user knows to look they are not going to root through help files and documentation to see if the program has been modified. And of course, if they know to look, they probably know the program has been modified. The reason for wanting this is because the company I work at does not want our product to have the quality impared and redistributed without the user knowing about it. Thanks in advance. -- Wesley W. Terpstra [EMAIL PROTECTED] Javien Canada Inc. - Linux Developer pgpwbSeBNyCYO.pgp Description: PGP signature
Re: Integrity of Source Code
On Wed, 29 Nov 2000, Wesley W. Terpstra wrote: I wanted to enquire if clause #4 of the DFSG would allow a warning splash screen as follows: The program by default pops up a splash saying 'This is the official version of X obtainable in source and binary form from Y' - justs popups up for 3 seconds or something not to obnoxious. Some may disagree with how annoying a popup is, but that's a secondary issue. If the source code (not build parameters) are changed you are required to have the message popup with 'This is an UNOFFICIAL version of X. The official version can be obtained from Y.' - again for ~3 seconds. Hmm. What if I modify it for non-gui or non-interactive use, and the popup no longer is possible? Would I be in violation of the license? Obviously any changes to the source code that improve it's configurability or quality would be merged upstream. How about the modification to remove the annoying popup ;) Further, we have no intention of inhibitting the free flow of modified version of the source or binaries, we merely want the user of derived works to be made aware that this is no longer a version approved by us although it is based off of work by us. DFSG #4 is certainly not in conflict with this goal. The required-popup implementation of the goal MAY be in conflict with DFSG #3 (you're limiting the ability to derive works) or DSFG #6 (you're limiting it's use in applications where a popup is undesirable or impossible). It's a pretty fine point, though, so I'd recommend against it and probably accept it if you decided to use it anyway. (not that I decide whether it's acceptible, this is just MHO). We want this warning prominently visible b/c unless the user knows to look they are not going to root through help files and documentation to see if the program has been modified. And of course, if they know to look, they probably know the program has been modified. This is a common concern. One possible way to fix it is to reserve the name of the official release (through trademark or license), and require that modified versions not use that name. You don't need to specify what name they use, though you could suggest they use [Unofficial Name]. You don't need to specify HOW they tell the user their name, just that they may NOT tell the user that it's [Official Name]. This leaves people free to modify it without infringing on your reputation, but doesn't limit them to having a specific behavior like a popup. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Integrity of Source Code
On Wed, Nov 29, 2000, Wesley W. Terpstra wrote: The program by default pops up a splash saying 'This is the official version of X obtainable in source and binary form from Y' - justs popups up for 3 seconds or something not to obnoxious. If the source code (not build parameters) are changed you are required to have the message popup with 'This is an UNOFFICIAL version of X. The official version can be obtained from Y.' - again for ~3 seconds. I think this breaks the DFSG, because it simply prevents to remove the popup code. Further, we have no intention of inhibitting the free flow of modified version of the source or binaries, we merely want the user of derived works to be made aware that this is no longer a version approved by us although it is based off of work by us. [...] We want this warning prominently visible b/c unless the user knows to look they are not going to root through help files and documentation to see if the program has been modified. And of course, if they know to look, they probably know the program has been modified. [...] The reason for wanting this is because the company I work at does not want our product to have the quality impared and redistributed without the user knowing about it. One solution I may suggest is to require any modified version to have a fully different name. The Apache project is using such a license for their webserver: * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. You might find this solution acceptable, since it is DFSG compatible. Regards, Sam. -- Samuel Hocevar [EMAIL PROTECTED] http://sam.zoy.org/ for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done | \ perl -ne 's/\.//g; print pack(H224,$1) if(/^x([^z]*)/)' | gunzip
Re: Integrity of Source Code
On Wed, Nov 29, 2000 at 08:35:45PM +0100, Samuel Hocevar wrote: The program by default pops up a splash saying 'This is the official version of X obtainable in source and binary form from Y' - justs popups up for 3 seconds or something not to obnoxious. If the source code (not build parameters) are changed you are required to have the message popup with 'This is an UNOFFICIAL version of X. The official version can be obtained from Y.' - again for ~3 seconds. I think this breaks the DFSG, because it simply prevents to remove the popup code. This is no different than the interactive execution copyright notice that the GPL mandates unless the upstream author opted not to place one. Of course, it is more annoying. One solution I may suggest is to require any modified version to have a fully different name. The Apache project is using such a license for their webserver: * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. You might find this solution acceptable, since it is DFSG compatible. This is a much less annoying alternative. It is not however GPL compatible until after the name has changed. -- 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 NeonKttn I had a friend stick me in her closet during highschool beacuse I wouldn't believe that her boyfriend knew about foreplay... NeonKttn I shoulda brought popcorn. :)
