Re: license of smapi
On 2000-06-09 at 13:06 +0200, Henning Makholm wrote: > Scripsit Mike Bilow <[EMAIL PROTECTED]> > > > > > 3) If you modify this code, you must keep the message format compatible. > > > > That is also non-free. > > > I disagree here. Dudley is trying to prevent people from making > > proprietary "embrace and extend" changes to the message format. > > Yeah, that's also what Sun is saying each time they pull this one. > > I'll leave open whether this should be attributed to malice or > thoughtlessnes, but I'd like to point out at least two adverse > effects: I misunderstood the license in my earlier response; you are correct that this is non-free. The issue has to do with defining "message format." > It is OK if the license requires me to document what I changed > if I give my changed code to someone else who also needs to solve > my new problem - but that is different from the clause above, > which says that I must not change the data structures, full stop. The main issue is that you are not allowed to call something "Fidonet Technology Networking" or "Fidonet compatible" unless it complies with certain specifications for data structures. This is essentially the same situation as applies to any protocol, including those applicable to numerous protocols implemented in Linux, such as Ethernet. If a piece of software implements FTN protocols, then it does so pursuant to an equal access license and must honor its terms. Fidonet does not care what private parties do among themselves, but protects public use of its name. However, the license here relates to the data structures on disk, not to interaction between systems. As a result, it is entirely outside the concern of Fidonet protocols proper, regardless of any other issues. IMPORTANT DISCLAIMER: I speak only for myself here, not for the Fidonet Technical Standards Committee. -- Mike
Re: license of smapi
On 2000-06-09 at 13:06 +0200, Henning Makholm wrote: > Scripsit Mike Bilow <[EMAIL PROTECTED]> > > > > > 3) If you modify this code, you must keep the message format compatible. > > > > That is also non-free. > > > I disagree here. Dudley is trying to prevent people from making > > proprietary "embrace and extend" changes to the message format. > > Yeah, that's also what Sun is saying each time they pull this one. > > I'll leave open whether this should be attributed to malice or > thoughtlessnes, but I'd like to point out at least two adverse > effects: I misunderstood the license in my earlier response; you are correct that this is non-free. The issue has to do with defining "message format." > It is OK if the license requires me to document what I changed > if I give my changed code to someone else who also needs to solve > my new problem - but that is different from the clause above, > which says that I must not change the data structures, full stop. The main issue is that you are not allowed to call something "Fidonet Technology Networking" or "Fidonet compatible" unless it complies with certain specifications for data structures. This is essentially the same situation as applies to any protocol, including those applicable to numerous protocols implemented in Linux, such as Ethernet. If a piece of software implements FTN protocols, then it does so pursuant to an equal access license and must honor its terms. Fidonet does not care what private parties do among themselves, but protects public use of its name. However, the license here relates to the data structures on disk, not to interaction between systems. As a result, it is entirely outside the concern of Fidonet protocols proper, regardless of any other issues. IMPORTANT DISCLAIMER: I speak only for myself here, not for the Fidonet Technical Standards Committee. -- Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: license of smapi
On 2000-06-08 at 23:39 +0200, Henning Makholm wrote: > Scripsit Martin Butterweck <[EMAIL PROTECTED]> > > > 1) This code must not be sold. Permission to post this file on "pay > >BBSes" is granted, as long as no extra fee (above and beyond the > >normal access charges) is required to download or access this code. > > ---snap--- > > this means non-free, right ? > > Yes. I suggest that you drop a note to Scott Dudley asking for clarification. I think what he is after is that he does not want someone charging for his code specifically, which is essentially consistent with the DFSG. I doubt he intends that aggregation of his code into an archive or application which is sold, which is the main focus of the DFSG, be prohibited. > > 3) If you modify this code, you must keep the message format compatible. > > That is also non-free. > > (Wow, a sunstunt long before sun began doing them!) I disagree here. Dudley is trying to prevent people from making proprietary "embrace and extend" changes to the message format. This would be something like Debian requiring that no one make proprietary changes to the .deb file format, or requiring that mail programs comply with RFC822. The whole point of Fidonet is that it defines a technical file format which permits interaction between systems; if deviation from that defined file format is permitted, the endeavor is pointless. IMPORTANT DISCLAIMER: Although I hold a seat on the Fidonet Technical Standards Committee, I am speaking only for myself here. -- Mike
Re: license of smapi
On 2000-06-08 at 23:39 +0200, Henning Makholm wrote: > Scripsit Martin Butterweck <[EMAIL PROTECTED]> > > > 1) This code must not be sold. Permission to post this file on "pay > >BBSes" is granted, as long as no extra fee (above and beyond the > >normal access charges) is required to download or access this code. > > ---snap--- > > this means non-free, right ? > > Yes. I suggest that you drop a note to Scott Dudley asking for clarification. I think what he is after is that he does not want someone charging for his code specifically, which is essentially consistent with the DFSG. I doubt he intends that aggregation of his code into an archive or application which is sold, which is the main focus of the DFSG, be prohibited. > > 3) If you modify this code, you must keep the message format compatible. > > That is also non-free. > > (Wow, a sunstunt long before sun began doing them!) I disagree here. Dudley is trying to prevent people from making proprietary "embrace and extend" changes to the message format. This would be something like Debian requiring that no one make proprietary changes to the .deb file format, or requiring that mail programs comply with RFC822. The whole point of Fidonet is that it defines a technical file format which permits interaction between systems; if deviation from that defined file format is permitted, the endeavor is pointless. IMPORTANT DISCLAIMER: Although I hold a seat on the Fidonet Technical Standards Committee, I am speaking only for myself here. -- Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Would this be applicable to the API issue?
On 2000-06-07 at 12:18 -0400, Chloe Hoffman wrote: > trademark at least in the U.S. Taco Cabana won damages - see the U.S. > Supreme Court case here > http://caselaw.findlaw.com/scripts/getcase.pl?court=us&vol=505&invol=763 > > As a basis for suit in this case, I would not think trade dress infringement > would be the strongest claim (although that doesn't mean it shouldn't be > raised). I would think the copyright infringement / breach of contract case > is much stronger. Perhaps followed by trademark infringement for the use of > the Debian swirl. It seems to me that there is serious doubt that a web site could ever meet the non-functionality test. In the Taco Cabana case, the Court held: * BEGIN QUOTE * Suggestions that, under the Fifth Circuit's law, the initial user of any shape or design would cut off competition from [505 U.S. 763, 775] products of like design and shape are not persuasive. Only nonfunctional, distinctive trade dress is protected under 43(a). The Fifth Circuit holds that a design is legally functional, and thus unprotectable, if it is one of a limited number of equally efficient options available to competitors and free competition would be unduly hindered by according the design trademark protection. See Sicilia Di R. Biebow & Co. v. Cox, 732 F.2d 417, 426 (1984). This serves to assure that competition will not be stifled by the exhaustion of a limited number of trade dresses. * END QUOTE * My take on this is that the Debian "swirl" is an open-and-shut issue, and that the copyright claim could be minimally resolved in a way that would provide no remedy to Debian's real concerns about public confusion. > >I think the Apple/eMachines case is something of an aberration in being > >taken seriously. > > I am not so sure. I think iMacs have a pretty distinctive shape (trade > dress) and when I see them I know they are Apple's. Perhaps it can be argued > that the iMac design is "functional" - an aspect of the test not mentioned > in the article - that is whether the particular feature(s) of the product > are essential to the user or purpose of the article. > > > To me, the iMac looks like a case made in the natural > >shape of the CRT and given a funny color, which is hardly in itself > >sufficient to justify a protectable claim. > > But that's not the legal standard. The analysis is whether the shape is > functional (perhaps an issue of dispute), is distinctive (iMacs don't look > like your run of the mill beige box) and it identifies the source of the > goods to which the trade dress is applied (I think a good survey would show > most people identify the iMac shape with Apple). My argument on the iMac rests primarily on the claim of distinctiveness. I think there is very strong argument to be made that the iMac shape is not _inherently_ distinctive: it is not appreciably different than a Lear-Siegler ADM3 terminal or an ADDS Regent terminal, for example, and the shape is simply that of the CRT inside the monitor box. One might argue that, since the vast majority of the public has neither seen nor heard of these ancient terminals and has no idea of the natural shape of a CRT, then Apple has through advertising bestowed a secondary meaning onto their shape which is not otherwise inherently distinctive. > > Taken to its logical extreme, > >Apple could use this argument to prohibit anyone else from making a > >computer that was not perfectly rectangular and beige. To make matters > >worse for Apple (as you note in the part of your quote I snipped), the > >eOne is a Windows machine and therefore very unlikely to be confused by > >the public with the iMac, so Apple is reduced to arguing a dilution claim. > > Confusion is the lynchpin I think of a suit pertaining to the iMac shape or > any trade dress case for that matter. Frankly, I have not seen the alleged > infringing eMachines computer nor know whether any consumer would be > confused. I can't speculate whether the case is with or without merit. I > also think it is overstatement that Apple could prohibit anyone else from > selling a computer that was not perfectly rectangular and beige simply from > a having a trade dress right in the iMac; the right is not absolute and > Apple has to prove all the elements including that its design is not > functional and that of confusion given the proliferation of computer shapes. > Courts are pretty good at determining what is confusing and what is not. Well, I specifically said "taken to its logical extreme." My point is that the iMac is not, in my opinion, "inherently distinctive" because the shape of a CRT in a CRT-shaped case cannot be so regarded. Given that the Taco Cabana case starts out from the assumption that its trade dress was found by the jury to be inherently distinctive and non-functional, it seems to me that this moves it outside the main sphere of relevance for both the Debian issue and the Apple iMac claim. > Not sure how
Re: Would this be applicable to the API issue?
In general, "trade dress" is a fairly weak concept. Owens-Corning has been held, for example, to have a protectable right to make fiberglass insulation in a distinctive pink color because there is no natural association with that color and construction material. On the other hand, John Deere has been held not to have a protectable trademark interest in their distinctive green color because there is an obvious and natural association between the color green and farm equipment. I think the Apple/eMachines case is something of an aberration in being taken seriously. To me, the iMac looks like a case made in the natural shape of the CRT and given a funny color, which is hardly in itself sufficient to justify a protectable claim. Taken to its logical extreme, Apple could use this argument to prohibit anyone else from making a computer that was not perfectly rectangular and beige. To make matters worse for Apple (as you note in the part of your quote I snipped), the eOne is a Windows machine and therefore very unlikely to be confused by the public with the iMac, so Apple is reduced to arguing a dilution claim. More critically with regard to the Debian issue, "trade dress" must be applied to the actual goods or services themselves. That is, although Ferrari may claim a protectable interest in the distinctive shape of their cars, the cars are the product. An analogous claim on a web site might be argued in theory for a product which is a web site, such as Yahoo, but the Debian web site is not itself a product. The "swirl" graphic, of course, is a classic trademark, intended to be affixed to the product itself. The notion of applying a "trade dress" theory to "sales techniques" seems very far-fetched, at least as I understand those terms. I suppose this is theoretically possible, but any case I can think up where this might work would have stronger claims otherwise. For example, taking the iMac as an inspiration, suppose that a used car salesman happens to be named "Barber" and decides to buy uniforms for all of his salespeople which are red and white striped, like a barber pole. He features people dressed in these odd outfits extensively in his print and television advertising. His competitor decides that this is working well, and decides to buy all of his salespeople uniforms that are blue and yellow striped. Barber cannot make much of a "trade dress" claim: he is not painting the cars, and he is not making the cars to begin with; car salespeople are notorious for wearing outlandlish attenion-getting clothing; and it is hard to see why blue and yellow stripes would suggest "Barber" in the same way as red and white. Unless Barber has some independent claim (if he, say, uses the slogan "The Home of the Striped Salespeople") then he has a tough case. -- Mike On 2000-06-05 at 00:11 -0400, Andrew Weiss wrote: > It seems as if this would bundle the Debian Swirl and the look of Debian's > website and cover any issues rather than dealing with it as copyright > infringement and/or trademark infringement. > > Excerpt from an article dealing with Apple sueing Emachines for the eOne: on > MacWeek News > > Trade dress > > Trade dress is protectable as an unregistered trademark and is a subset of > trademark law and principles; it is designed to ensure that a product or > service's shape, appearance, color, packaging or even sales techniques are > not copied by a competing product.
Re: practical question on copying of our HTML code
On 2000-06-02 at 11:11 -0700, Mark Rafn wrote: > > The critical question, then, is: what remedy should Debian seek here? * * * > Remedy? They should give credit to Debian in the source, and make their > source available. Oh, wait - they do that already. I disagree with this. I think the copyright issue is secondary to the trademark issue in importance, as I have said already. By allowing someone to maintain a web site which looks almost exactly like the Debian web site, including its distinctive appearance, including color scheme, layout, display typography, and even the "swirl" graphic, I think there is a substantial likelihood of public confusion. That is, it is reasonable for someone who is familiar with the Debian web site to assume that such a close copy, although with entirely different text, implies some connection or endorsement relationship with Debian. This is a far more serious problem than whether the HTML is credited. -- Mike
Re: complete clone of the debian website
On 2000-06-02 at 13:55 -0400, Raul Miller wrote: > On Fri, Jun 02, 2000 at 12:47:31PM -0400, Mike Bilow wrote: > > I recognize your point, but there is enormous uncertainty whether HTML > > source is subject to copyright protection at all, as distinct from > > rendered HTML. The problem is that copyright protects, by definition, > > an actual expression of an idea. This presupposes at least the > > possibility of communicating the work to another person. > > Is this the same kind of uncertainty that exists about whether computer > source is subject to copyright protection at all? Copyright protects the "essential character" of a "work of authorship." In the case of a computer program, the source code is clearly included within the scope of essential character: because the purpose of a computer program is to be run on a computer, the source code which is used to generate the executable program is copyrightable. There is no doubt or uncertainty about this, if the source code itself is published. In the case of a literary work, the typesetting specifications and layout are not part of the essential character of the work, and are not protected within the scope of copyright. The issue of whether page numbers are subject to copyright has actually been litigated inconclusively. > What we have here is evidence that a work has been copied. That the > evidence itself might or might not be copyrightable doesn't mean that > it's not evidence. No one disputes that much of the Debian web site has been copied. If Debian had a copyright notice such as "All rights reserved," then this would be an open-and-shut case of copyright infringement. The problem is that Debian, for whatever reason, has chosen to license the copyright on its web site subject to the OPL. The relevant question then is: Has API violated the OPL license terms and, if so, to what extent? API is not using any of the exact words from the Debian web site in the rendered text. At most, API has used some of the exact words from the Debian web site in the unrendered text, such as the META tags. Is any unrendered text part of the essential character of a web site? That is far from clear. The real problem is that API has appropriated the artistic content of the Debian web site. The focus of the OPL is on the literary content of the work of authorship, in the sense that the work is a book. It is not clear that, under the license terms of the OPL, Debian can raise a meaningful objection to what API has done. This was clearly not what was intended by Debian in choosing to license its web site content under the OPL, nor does it seem likely that this was what was intended by the author of the OPL. Nevertheless, relying upon the actual wording of the OPL itself, I am not sure that what API has done is a violation of the copyright license. -- Mike
Re: complete clone of the debian website
On 2000-06-02 at 17:46 +0100, Colin Watson wrote:
> Mike Bilow <[EMAIL PROTECTED]> wrote:
* * *
> >Further, it is doubtful that invisible (that is,
> >unrendered) parts of the HTML source, such as META tags, could be
> >protected by copyright at all.
>
> Clearly, however, such tags are more important than, say, HTML
> comments would be. For instance, a search engine that encounters the API
> website may classify it using the keywords given, and may even choose to
> display the description ("Debian GNU/Linux is a free distribution of the
> GNU/Linux operating system ...") as a short description of that site. In
> this context, the normally unrendered parts of the HTML source *are*
> significant, though of course they are not the sole problem.
Significant, yes. Protectable by copyright, not necessarily.
An index basis is not itself any kind of intellectual property. Libraries
traditionally sort books by title, author, subject, call number, or some
similar set of indices. Book authors would have no copyright claim if
libraries decided to index their works idiotically, say by cover color.
Libraries and bookstores could actually do fairly extreme things by way of
indexing, such as placing all books about religion under "fiction," and
still not infringe the copyright of their authors.
In any case, I think this is off the point. Assuming that the META tags
are a copyright infringement, the remedy would be to remove them. If the
API web site removed the "swirl" graphic and the META tags, would those
changes alone satisfy Debian? I think not.
The critical question, then, is: what remedy should Debian seek here?
-- Mike
Re: complete clone of the debian website
On 2000-06-02 at 12:07 -0400, Raul Miller wrote: > On Fri, Jun 02, 2000 at 12:01:23PM -0400, Mike Bilow wrote: > > Yes, but it is not clear to me that this is a violation of the OPL. The > > problem is that the OPL is overwhelmingly concerned with, and written > > subject to the assumption that, it is protecting something equivalent to a > > book. This means that the main thrust of the protected material is the > > words and the _relevant_ illustrations. > > The exact significance of this interpretation depends on the > technology used to display the text. > > For example, hit "view source" under netscape, and you'll > see some rather interesting words. I recognize your point, but there is enormous uncertainty whether HTML source is subject to copyright protection at all, as distinct from rendered HTML. The problem is that copyright protects, by definition, an actual expression of an idea. This presupposes at least the possibility of communicating the work to another person. Is a web site most similar to a literary work, in which the words are most important? Or is a web site most similar to a visual work, in which the overall appearance is most important? Or is a web site most similar to a computer program, in which the raw content is most important? The OPL clearly assumes that it is being applied to a literary work, so I think that Debian is stuck with this assumption once it has chosen to license its web site under the OPL. This is not unreasonable, since the artistic components of the Debian web site, while distinctive (in the trademark sense), are by no means central to the purpose of the site. Insofar as a web site is a literary work, the unrendered parts of the HTML source are something like the binding and paper size used in a book: regardless of how distinctive and unusual they may be, such parts can never be protected by copyright. -- Mike
Re: complete clone of the debian website
On 2000-06-02 at 11:08 +0200, Peter Makholm wrote: > Mike Bilow <[EMAIL PROTECTED]> writes: > > > artistic character. It is also not clear to me whether the API web site, > > with entirely new text, is a derivation from or an aggregation with the > > Have you seen the source from the API-website? > > That haven't even changed the meta-tags, from the debian website. It > is clearlky, to me, that they have copied the html and chenged the > text. Yes, but it is not clear to me that this is a violation of the OPL. The problem is that the OPL is overwhelmingly concerned with, and written subject to the assumption that, it is protecting something equivalent to a book. This means that the main thrust of the protected material is the words and the _relevant_ illustrations. For example, if there were charts and diagrams on the Debian web site which were used to support the text, say a flow chart showing how to obtain the Debian distribution, then this would be definitely protected under the OPL just as the words would be. However, the artistic character of the web site, its "look and feel," are essentially arbitrary. (In fact, if this were not the case, such artistic character could not serve as a component of a trademark.) One could draw the navigation bar and the letters and so forth in a hundred different ways, and they would all work as well in terms of communicating the basic message of the web site. It is by no means clear that the OPL protects the ancillary or incidental components of a copyrighted work, such as the layout, color scheme, or display typography. The situation is somewhat similar to that faced by bad novels. I know this may seem counter-intuitive at first, but it is much easier to make an infringement claim in support of a great or famous novel than in support of a bad one, because bad novels tend inevitably to be fairly similar. What are known as "romance novels" in the US, for example, are consciously based upon entirely formulaic characters, plot, title, length, and cover art. One can be reduced in court to arguing such things as, "Yes, it is true that in both works at issue the heroine is named 'Susan,' was disappointed in love, and was finally reunited with the man of her dreams, but in one she is working as a waitress waiting to be swept off her feet and in the other she is working as a secretary waiting to be swept off her feet." I realize that I am being perhaps overly sarcastic here, but the problem is very real and it is hard, short of producing actual passages of words quoted verbatim, to show an infringement of a bad novel. Whatever one may think of the ethics of the API web site using literal HTML source from the Debian web site without attribution, there is little or nothing of the words and substance of the Debian site (other than the "swirl" graphic, which is important in a trademark context). Copyright infringement in this situation must consist entirely in the ancillary and incidental aspects of the Debian web site: layout, color scheme, display typography, and so on. Further, it is doubtful that invisible (that is, unrendered) parts of the HTML source, such as META tags, could be protected by copyright at all. So the copyright question must be considered in light of the nature of the works concerned. It is not unreasonable to claim that the API site is essentially an aggregation of Debian's layout, color scheme, display typography, and "look and feel" with API's words and substance. If the words and substance of the Debian web site were reused, then certainly the API site would be a derivation and not an aggregation. This means that it is not clear to me that the credit requirements of the OPL come into play here, since the OPL is applicable to derivation. This is also why I suggested in my earlier message that a trademark claim is a stronger argument in this situation, if the goal is to prevent someone from putting up a web site that looks just like Debian's but is not, in fact, Debian's. Ordinarily, this would be an open-and-shut copyright infringement issue, but the construction of the OPL complicates that very severely. To put it more simply, I am not sure that what API did is actually a violation of the copyright license (the OPL) which Debian has chosen to grant. This may really be an indication of a defect in the OPL -- the "we didn't think of that" problem -- but it is real. -- Mike
Re: complete clone of the debian website
On 2000-06-01 at 13:56 +0200, Wichert Akkerman wrote:
> Previously Joey Hess wrote:
> > http://www.491.org/projets/api/
>
> Nice. Time to write them a letter I guess. How about something like this:
>
> --
>
> We recently became aware of your website at http://www.491.org/projets/api/ .
> Unfortunately your webpages are a copy of the Debian homepage
> (http://www.debian.org) and clearly violates its license in a couple
> of points:
I certainly would not use the term "copy" in this context. There is no
question that their web pages are not a copy. They may be an
infringement, but they are not a copy. Debian needs to be careful.
> * The usage of the Debian Open Use Logo (better known as the swirl) is not
> allowed by its license. Its license states:
* * *
> * The Debian homepage is covered by the Open Publication License (OPL) as
> found
> on http://www.opencontent.org/openpub/. That license puts some requirements
> on modified versions of the copyrighted material. From section I:
* * *
> We request that you remove the API webpages until they are relicensed
> and updated to resolve these problems.
There are two entirely separate and distinct allegations of infringement
which could be made: trademark and copyright.
A trademark infringement, generally, is based upon the likelihood of
confusion in the totality of circumstances. That is, how likely is
someone familiar with the general appearance of the Debian web page and
its other distinctive characteristics to be fooled into thinking that
there is some affiliation or endorsement relationship between Debian and
API? The misappropriation of a pure trademark, in this case the "swirl,"
makes this far more likely, since it by definition and design has no
purpose other to identify the goods or services of its real owner.
Indeed, such a blatant misappropriation of both the distinctive artistic
components of the Debian web site and the "swirl" graphic might even be
cited as evidence of conscious intent to falsely claim affiliation with
Debian. It is essential to the preservation of a trademark that it be
protected by a license which in general must impose some sort of quality
control; in this case, the central restriction of the license is that it
sets out what may be called "Debian," and the misuse of the distinctive
appearance of the Debian web site, especially of the "swirl" graphic,
represents a violation of that license.
A copyright, on the other hand, protects the originality of artistic
expression in its own right, without regard to the issue of public
confusion. Debian has a copyright interest in the distinctive artistic
character ("look and feel") of its web site, but it chooses to license
this copyright interest under the OPL. It is not entirely clear to me
what is and is not permitted under the OPL in this context, since the
mindset underlying the OPL is directed primarily at content rather than
artistic character. It is also not clear to me whether the API web site,
with entirely new text, is a derivation from or an aggregation with the
Debian OPL content. If the API web site is a derivation from the Debian
web site, then it must itself be licensed under the OPL; if the API web
site is merely an aggregation with the Debian OPL content, then only the
Debian OPL content and not the API content need be licensed under the OPL.
The remedies for trademark and copyright infringement are also entirely
different from each other. As far as the trademark issue is concerned,
the remedy which Debian should demand is that the API site not look so
much like the Debian site that people are likely to confuse the two so as
to incorrectly assume some connection or endorsement by Debian. As far as
the copyright issue is concerned, it seems to me that the only remedy
available under the OPL is that the original design be explicitly credited
to Debian. These concerns and remedies are, it is important to note,
inherently contradictory: Debian cannot take the position that API has to
make their web site look different but, if they do not, then they have to
credit Debian for the design. In fact, there is at present no mention of
Debian on the API site (except in the HTML source), and this tends to
_reduce_ the likelihood of confusion; if Debian were credited explicitly
for the artistic design, then this would tend to _increase_ the likelihood
of confusion and make people more likely to assume incorrectly a
relationship or endorsement by Debian.
So the key question is: what does Debian want changed? If the issue is
that the API site should not look like the Debian site, then that is a
trademark issue. If the issue is that the API site does not properly
credit the Debian design work, then that is a copyright issue.
-- Mike
Re: ia64 port
On 2000-05-29 at 23:29 -0700, Randolph Chung wrote:
> ***Disclaimer***: I work for Intel, but do not speak for them in any regard
> whatsoever. I also don't work with/for the IA64 group.
>
> > I readily concede that my concerns were hypothetical, but what else could
> > they be? I suppose that promising not to reverse engineer the BIOS and
> > motherboard controller firmware is not likely to lead to an egregious
> > problem, but my point is that you never know. I have a great deal of
> > respect for Chris DiBona, and I would credit his views on this as
> > deserving of great weight. On the other hand, I also recall Intel pulling
> > the "Appendix H" stunt some years ago, and that makes me, personally,
> > uncomfortable about whether they "get" the Open Source concept.
>
> Have you seen http://developer.intel.com/design/ia-64/downloads/245473.htm ?
Have you seen the link on that page to "Legal Information?" It is:
http://developer.intel.com/sites/developer/tradmarx.htm
I really have doubts about whether the left hand knows what the right hand
is doing at Intel. The license that applies to the only downloadable
information on the page, a PDF file, reads in part:
You may download one copy of the information or software
("Materials") found on Intel sites on a single computer for your
personal, non-commercial internal use only...
Am I prohibited from telling other people what is in the PDF file? Am I
prohibited from making use of this information in software I distribute?
Am I prohibited from using the information to optimize commercial product?
Obviously, Intel intends the information in that file to be disseminated
fairly widely, or it would otherwise be of no use. So why such a license?
If Intel actually tried to enforce this paranoid license, especially since
it is buried in a separate page accessed through a tiny link, they would
be laughed out of court.
> It's interesting to note that TurboLinux and RedHat both have IA64
> distributions out. There are public mailing lists where a lot of porting and
> kernel issues are discussed. The IA64 Linux kernel and compilers are open
> source (the Cygnus one anyway). For "porting" Debian to IA64, most of the
> work will involve recompiling and twaking existing GPL software. Intel has
> no way (or reason, really) to restrict what you do.
Agreed, your position is reasonable. So who tells the Intel lawyers?
-- Mike
Re: ia64 port
On 2000-05-26 at 15:36 -0700, Joey Hess wrote: > 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. I readily concede that my concerns were hypothetical, but what else could they be? I suppose that promising not to reverse engineer the BIOS and motherboard controller firmware is not likely to lead to an egregious problem, but my point is that you never know. I have a great deal of respect for Chris DiBona, and I would credit his views on this as deserving of great weight. On the other hand, I also recall Intel pulling the "Appendix H" stunt some years ago, and that makes me, personally, uncomfortable about whether they "get" the Open Source concept. -- Mike
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: 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: ITP seahorse
On 2000-05-24 at 23:22 -0400, Branden Robinson wrote: > [Replies to this message should move to debian-legal.] I have dropped debian-devel as a recipient. > However, the BXA regulations were later amended[2]. I haven't read through > all the changes, but we might presume with some caution that you don't need > to attempt to restrict access to public Web or FTP sites to exclude > connections from countries that the United States has identified as its > enemies. If, on the other hand, you were engaged in some sort of commerce > where you would get the name and address of every person to whom you > distributed crypto, you almost certainly would be expected to turn away > Libyans, Sudanese, etc. > > This message is not an endorsement of BXA policy. Quite the contrary; I > think the U.S. government needs to leave the cryptographic community to > exercise its constitutional rights in peace. The very fact that such > letters have to be written to explain these Byzantine regulations to > American academics is evidence that the BXA should be dismantled and > eliminated from the federal budget. Perhaps its employees could find > gainful employment elsewhere as truant officers or gossip columnists. I don't think this is clear at all. I certainly can see no basis for reading the regulations so as to distinguish between actual knowledge acquired prior to export as distinct from after export. That is, what is Bernstein to do if his web server log clearly shows a download from a prohibited domain? Does Bernstein have a duty to disclose his logs? Does Bernstein have an obligation to keep logs? Does Bernstein have a legal duty to read the logs he does keep? This is a crazy situation foisted upon us by regulations written by people who have no understanding of how the Internet works, much like the apocryphal rules requiring that a man waving a red flag should be required to walk ahead of an automobile so as to warn of its approach. The Bernstein case also, as far as I know, addresses the issue of source code per se. It is by no means clear that restrictions which would not be enforced against source code would also not be enforced against binary executables such as Debian packages. The key legal element of the Bernstein case is that source code has a "speech" component such that it is the unique means of communication used among human programmers, and it is far from clear that one can have a free speech right when talking directly to a machine. There have certainly been stranger distinctions drawn in the courts on this issue, as in the Karn case where the source code was held to be exportable when printed on paper but not when stored on a floppy disk, although the government stipulated to Karn's assertion that the paper printout could be scanned in using OCR and turned into the identical form as on the floppy disk in only about three hours. Regardless of the transactions in the Bernstein case, the common interpretation which is evolving of the new regulations seems to be that the user has to be forced to affirm that they are not in a prohibited country before downloading the files. This is how Netscape seems to handle their 128-bit browser now. It makes no sense that "I am not a terrorist" loyalty oaths are expected to be useful for any purpose whatsoever, and we are starting to approach the realm of legal absurdity when plastic bags are labeled "This bag is not a toy" and coffee cups are labeled "Coffee may be hot." -- Mike
Re: Possible copyright violation wrt SNNS
On 2000-05-23 at 08:37 -0500, Steve Greenland wrote: > On 23-May-00, 00:56 (CDT), Mike Bilow <[EMAIL PROTECTED]> wrote: > > This would be my position: once you edit in the "debian" subdirectory, you > > are modifying the source tree. I don't see any way of satisfying the > > license other than by distributing source patches and letting the user > > build, as is done with Pine. This is annoying at best, and the Pine > > license is actually one of the principal motivations for Mutt. > > There's (possibly) two issues: distributing modified source, and > distributing a binary that was built from the modified source. Debian > is okay on the former: we distribute the upstream source + patch. We're > not okay on the latter. But most licenses that restrict the former also > restrict the latter (or don't mention it at all, which is equivalent, in > my opinion). My reading of the snns license is that distributing a binary version is allowed, as long as it is built from unmodified source. The license is quite expansive in terms of what can be done with unmodified source. In fact, the license explicitly says that it is the same as GPL except for the provision that you cannot distribute modified source or derivatives of modified source (which would include binaries built from modified source), so I would take that as a fairly clear endorsement. As a practical matter, the distinction is irrelevant to snns since the unmodified source violates Debian Policy substantially enough that it would not even be eligible for non-free. While it might get the binary back into Debian if the upstream maintainer accepted the suggested changes from the Debian maintainer, this would leave the package effectively unmaintainable by the Debian maintainer in the future. As a side note, the act of changing the binary file name (to "snns.xgui" instead of "xgui") has no copyright implications because the title of the file is not subject to copyright. (There might be trademark implications, but not copyright implications.) The Debian source patch would have to be careful to modify the file name after the build is complete, as stupid as that sounds, since modifying the original Makefile would violate the license. The snns license is really evil well beyond any intent its authors could possibly have possessed. -- Mike
Re: Possible copyright violation wrt SNNS
This would be my position: once you edit in the "debian" subdirectory, you are modifying the source tree. I don't see any way of satisfying the license other than by distributing source patches and letting the user build, as is done with Pine. This is annoying at best, and the Pine license is actually one of the principal motivations for Mutt. There is almost certainly no way to get this into Potato now. -- Mike On 2000-05-22 at 18:54 -0500, Steve Greenland wrote: > I think there is also a body of opinion that the mere act of making a > debian package constitutes "distributing a modified version".
Re: Possible copyright violation wrt SNNS
I think there is no question you have to get it out of Potato as things stand. You might be able to do something similar to what is done with Pine, where there is a package that walks the user through an automated patch-and-build-from-source procedure. -- Mike On 2000-05-23 at 00:15 +0200, Torsten Landschoff wrote: > You are right :( It seems like I can't distribute the binaries created from > the modified source. The license does not at all refer to binary > distributions > but I think I am in violation with the license here. > > This opens a release critical but on snns until that is resolved. If somebody > from -legal agrees that I can't modify the source than we have to get this > out of potato...
Re: Fair use defined (was: Re: Stallman Admits to Copyright Infringement)
The basic principles of legal construction weigh heavily against any interpretation that would imply "legal but impossible." In other words, a court trying to make sense of the statutory language is bound to assume that the Congress must have had something in mind other than outright deceit. In fact, my reading of the statutory language is considerably broader on the point of fair use, where the Congress explicitly promises that no one will lose the ability to do anything under the terms of fair use that they could have done before the statute was enacted. The problem is that, if one chooses to emphasize one provision of the statute, then the other is reduced to an absurdity. I contend that the MPAA/RIAA position on DMCA interpretation is inconsistent with the language regarding fair use. The "legal but impossible" argument being advanced by the MPAA is legally indefensible. On the other hand, the blame rests squarely on the Congress for adopting language that was intended to make everyone happy by promising contradictory things. Since there is a traditional understanding that there are Constitutional underpinnings for the fair use doctrine and not merely statutory ones, I think it is likely that the courts will be forced at some level into explicitly articulating whether or not this is correct. If the Congress proves incapable of deciding questions of national policy because of political paralysis and its own incompetence, then the inevitable result is government by litigation. -- Mike On 2000-05-22 at 13:32 -0500, sam th wrote: > I'm not entirely sure what you think is contradictory. The only thing > that I can think of is that Congress said that it is not denying fair use, > when in fact it make it impossible. However, these are not neccessarily > contradictory (although I think the MPAA's interpretation of the DMCA is > contradictory). However, the MPAA's position is that fair use is legal, > just impossible. This is not an inherently contradictory position > (although an evil one).
Re: Fair use defined (was: Re: Stallman Admits to Copyright Infringement)
I think the real problem is that the actual statutory language enacted by Congress in the case of the DMCA is inherently contradictory, and it is therefore impossible to know what the act means in practice without a great deal of litigation. This is a grossly irresponsible surrender of lesiglative duty, much like a football referee trying to make everyone happy by telling both sides that they have won and then encouraging the fans to resolve the matter with fistfights. -- Mike On 2000-05-22 at 01:02 -0500, sam th wrote: > Normally, this would not be enforcable under copyright law. However, the > DMCA allows manufacturers to prevent people from bypassing technological > measures that prevent fair use of the materiel. Thus, fair use is legal, > but technically impossible. The DMCA does not abolish fair use, however > it allows copyright holders (in these cases, usually not the artists) to > make the sort of access that would make fair use possible criminal.
Re: GNU License and Computer Break Ins
At the risk of seeming to pick nits, this is not actually the effect of the GPL. The author of a GPL work can license it to different parties on different terms; only authors of derivative works are so encumbered. The author of a GPL work could even sell it, or add conditions of sale, such as allowing people to purchase technical support only if they also purchased the program. The author of a GPL could even make two completely different versions such as a free version and a pay version; nothing in the GPL prohibits crippleware by an original author. -- Mike On 2000-05-19 at 22:27 -0400, Raul Miller wrote: > However, the GPL tries to make sure that -- once copies of GPLed software > are distributed -- the recipients of the software have as many rights as > any other recipients of any other versions of that software. [That means > no peculiar rules about how recipient c has to follow special procedures > when modifying the version of the software received from recipient f, > for instance.]
Re: GNU License and Computer Break Ins
Some copyrights never expire. For example, my understanding is that the UK "crown copyright" (a copyright owned by the government) is perpetual. The US follows almost exactly the opposite rule, where works by or for the government are in the public domain. Please do not confuse copyright and patent. Part of the core function of a patent is to require that the art be published for the benefit of all, in exchange for a short period of exclusivity. Disclosure is the essence of the patent process. Someone who chooses to obtain a patent makes an explicit choice to surrender other protections, such as trade secrecy. Sometimes a trade secret endures far longer than a patent could, as with Coca-Cola's formula or Colonel Sanders' herbs and spices. -- Mike On 2000-05-19 at 20:30 -0500, Paul Serice wrote: > Subjectively, it seems right that, if somebody spends 30 years writing > the best novel of the 21st century, she should be allowed to give the > proceeds to the charity of her choice for as long as she wanted. After > all, the book will be in the public library system soon so no one can > claim that they are being denied access to it. > > Subjectively, it seems wrong that someone could abuse the copyright or > patent laws to produce a monopoly like the one the justice department is > in the process of breaking up.
Re: GNU License and Computer Break Ins
Not only do I not recall saying that the full social consequences of the GPL are obvious, I would not claim to know what they are. Many widely respected people have expressed essentially opposite opinions on that. This is the underlying issue in the dispute between the "Free Software" camp (Stallman) and the "Open Source" camp (Perens, Raymond). I would not want to put words into Stallman's mouth, but I think his disapproval of the basic premises put forward in Raymond's famous "The Cathedral and the Bazaar" are well known. Raymond focuses his argument, as I understand it, on making what amounts to a business case for the GPL. That is certainly not where Stallman is coming from, but they are both arriving on certain common ground within the GPL wording itself. Raymond himself published an article saying that he ended up with something like $36 million in stock as a result of the Red Hat IPO, which was given to him in appreciation for his service to Open Source software in various forms. Stallman, on the other hand, is understood to have turned down a similar offer. Clearly, since both Raymond and Stallman are men of integrity, we have to accept that they have an honest yet fundamental disagreement about exactly the philosophical issues on which you are trying to corner us. -- Mike On 2000-05-19 at 12:58 -0500, Paul Serice wrote: > Socially speaking, it seems using the GPL is like signing a petition. > > I wonder how many people who say they support the GPL mean that they > support the right of the author to choose the GPL -- which, to me, means > they do not support the larger social program of which the GPL plays > such a large part. > > I would like to see the intended consequences of the entire social > program explicitly stated in the preamble to the GPL so that people like > me don't end up accidentally saying they support something they don't. > > I would greatly appreciate your letting me know how you came to realize > the full social consequences of the GPL. You say it is obvious, but > would you agree that it is not generally distributed along with the GPL.
Fair use defined (was: Re: Stallman Admits to Copyright Infringement)
Do not put too much emphasis on the "fair use" concept. It is deliberately very vague, much like the concept of "due process of law." Exactly what it means in any particular situation can be very hard to pin down without actually litigating the issue. I would argue that there are extreme cases where "fair use" would allow the publication of an entire work over the objections of an author where questions of historical importance or public policy were at stake. A "fair use" claim cannot be decided by the extent of the excerpt. To give a notorious example, Adolf Hitler died in 1945, meaning that "Mein Kampf" would have fallen into the public domain in the US only in 1995. Upon his death, the copyright of Hitler's book passed to his heirs, but they obviously were primarily concerned with suppressing publication of the book. We are not talking about reaching into the man's typewriter and disseminating an unpublished manuscript, but rather of putting an historical document into circulation rather than letting it be suppressed by an embarrassed family. While one might reasonably argue that the world would be better off if "Mein Kampf" were suppressed, no one would argue that access to it should be denied to legitimate historians. (The exact copyright legacy of "Mein Kampf" is actually considerably more complicated than that, but is mostly irrelevant for this discussion. In fact, the government of Bavaria makes a practice of suing anyone who tries to put "Mein Kampf" into print, except in the two countries, the US and the UK, where that would be legally hopeless, and some very odd legal results have been obtained. For details, see: http://www.algonet.se/~andersa/ad/copyreich/index.eng.html As I understand the present legal situation in Sweden, for example, the courts have held that someone owns the copyright but they cannot identify who does, thereby completely preventing publication because no one is recognized as having legal power to authorize reprinting.) A similar situation has arisen with the unpublished manuscript of Adolf Eichmann, written during his imprisonment in the early 1960s. This document was released by the Israeli government only a few months ago in connection with a defense request in the libel case brought by David Irving. The copyright is probably still in force, and it is not entirely clear who owns the work and, therefore, has the right to authorize or suppress publication. Although Eichmann himself intended the document for publication -- it is, after all, entirely a self-serving version of historical events -- it seems evident that his heirs would prefer that it be locked away for as long as possible. Putting it into the public record through a British court proceeding creates an interesting conflict between public policy and copyright interests. There is a good summary at: http://www.guardianunlimited.co.uk/Print/0,3858,3969076,00.html Further, there is some acceptance in the US that the "fair use" doctrine has a Constitutional basis, and that the statutory language is merely recognition of a right which exists independently of statute. This is essentially the issue being raised by the Eldred v. Reno case, which seeks to overturn the Copyright Term Extension Act. -- Mike On 2000-05-18 at 16:48 +0100, Jules Bean wrote: > For example, on page 28 [1] of circular 92, we find paragraph 107. > Paragraph 107 says that (heavily edited, it's long, go read the > original) "... fair use of a copyrighted work, including such use by > reproduction in copies of phonorecords or by any other means specified > by that section, for purposes such as criticism, comment, news > reporting, teaching ... scholarship or research is not an infringment > ... factors to be considered shall include ... purpose and character > of use ... commercial or ... nonprofit educational .. nature of the > copyrighted work ... effect of the use upon potential market for or > value of the copyrighted work..."
Re: GNU License and Computer Break Ins
None of this makes a bit of difference. You are making a very obvious error by failing to realize that different authors may elect to put their works under GPL with different intent and different motivation. You are reading too much into the mental process behind the author's action, while what is really relevant is the commitment that author makes through the actual written words of the GPL. In this case, the GPL -- like any public document -- should mean the same thing in terms of effect to all people, and it is a mistake to go beyond its wording. The GPL is intended to be more restrictive than comparable licenses, such as BSD. In particular, the BSD license says that the author permits anyone to do what they like as long as they do not hold the author (such as the Regents of the University of California) responsible or misuse the author's name and reputation in their own work. The critical difference is that the BSD license allows commercial derivatives to be created by parties other than the author, while GPL requires that derivative works also be licensed under GPL. My understanding is that this grew out of Stallman's own experience with Emacs, where a number of commercial variants began popping up, all with competing non-standard extensions. The GPL concept is known as "copyleft" for a reason. Assume, for the sake of argument, that someone believes that "all property if theft" and that his political philosophy is that everything should be owned in common. It might then be a perfectly logical and consistent position for such a person to put his own software under GPL, insisting that others who recognize the author's right to private property thereby respect his right to use a license such as GPL, while at the same time arguing that the basic concept of private property is morally wrong. In fact, one could argue that he accomplishes the result most logically consistent with his personal philosophy by using a license such as GPL, even if he also believes that the theoretical underpinning of GPL (property rights) is morally unsound. Note that I am not saying that Stallman, for example, is actually a Marxist. What I am saying, and what I think you are missing, is that you are trying to probe into the mindset of a person well beyond what he has stated it to be, and have accused him of lying, or at least of illogical inconsistency, because of what amounts to his disagreement with you. Where you and Stallman have a meeting of the minds is in the text of the GPL, and it is improper and irrelevant to go beyond that. I think it is obvious, and Stallman has stated as much, that he believes the bulk of the current system of intellectual property law to be morally wrong, and that the GPL was created specifically to subvert that system by turning its own weapons on itself. In the past, Stallman has done such things as lead a picket protest outside the offices of Lotus Development Corporation, and I am fairly sure that was before it was bought by IBM. He has toned down his rhetoric considerably since then, but mainly because (unlike the Marxists) he is winning. -- Mike On 2000-05-18 at 06:32 -0500, Paul Serice wrote: > In Orwell's _1984_, there is a discussion about how things get named > with the exact opposite of what they mean. For example, the "People's > Newspaer" or the "Freedom Ministry." I have to think that I should > start thinking "free" as in 1984, not as in beer and certainly not as in > freedom to choose how your work is used. Sigh. > > Disclaimer: To reach the above decision, I have to make a few > assumptions. First, that in the Wired interview, RMS was talking about > trading bootlegs. Just listening to the interview, trading bootlegs is > by far the most obvious interpretation. Of course, I don't know RMS > like you do. So, I would be grateful for any insight into the correct > interpretation. > > Second, I have to assume that the GPL, written a long time ago, is still > accurately reflected in Stallman's actions today. > > Both of these assumptions seem warranted.
Re: Stallman admitted to something which should not be confused with copyright infringement
On 2000-05-16 at 20:35 -0400, Raul Miller wrote: > On Tue, May 16, 2000 at 08:25:00PM -0400, Mike Bilow wrote: > [stuff about LaMacchia] > > Mike: the subject line you used doesn't seem to be related to the contents > of your post. Care to explain? I didn't write the subject line; I hit reply. One could argue that this was a bad idea... I certainly do not mean to express any opinion that Stallman (or anyone else) has, on the basis of knowledge personal to me, done anything improper. If the opposite impression was conveyed by automatically picking up the subject line, I apologize to all concerned. -- Mike
RE: Stallman Admits to Copyright Infringement
The US law was changed after the Lamacchia case. See, for example: http://www.eff.org/pub/Legal/Cases/LaMacchia/ (Note that Brian LaMacchia, who runs the PGP keyserver at pgp.ai.mit.edu, and David LaMacchia, who was the defendant here, are brothers.) David LaMacchia's personal page is: http://www.swiss.ai.mit.edu/~dml/home.html LaMacchia's attorney, Harvey Silverglate, has some useful resources on his web site: http://www.silverglategood.com/cases/lamacchia/ Harvey comments: Subsequent to and as a result of the outcome of the LaMacchia case, Congress amended the criminal copyright statute so that it currently punishes copyright infringement, whether or not the infringer seeks or obtains financial gain, so long as infringement causes more than $5,000 in damage to the copyright holder. By the way, it is worth noting that Harvey is, in my opinion, one of the nation's best and most committed civil liberties lawyers, and has written extensively on many issues of importance: http://www.silverglategood.com/people/silverglate.html -- Mike On 2000-05-16 at 10:03 -0400, Andrew Weiss wrote: > Doesn't the original FBI warning on videos and similar copyright protections > cover only redistribution for profit? Sure Metallica can point to lost > sales, but unless somebody else is making a profit off of their work, or > calling it their own, where is the illegality of it? This may have changed > a long time ago so I may be way off.
Re: GNU License and Computer Break Ins
I think there's a fundamental misunderstanding here. GPL is a set of copyright license terms, and the subject of copyright is the right to publish. The essence of GPL is that, if you publish, you must follow certain conditions. There is nothing in GPL that requires you to publish. If someone breaks into your computer and copies GPL software without permission, then the best that can be said in their defense is that they have not committed copyright infringement. In such a case, however, it seems to me that copyright infringement would be the least of their worries, relative to more traditional criminal charges. However, an unpublished work derived from a GPL work is not itself open to be copied freely unless and until it is published. "Publishing," in this context, is pretty much anything that involves distribution to others, such as selling the work, but having a copy of your work stolen is not "publication" for copyright purposes. GPL does not require disclosure, let alone involuntary copying, and a GPL work could even be a trade secret. For example, if I made a device that ran on unmodified Linux, which is GPL, I could decide not to tell anyone that I was using Linux inside the device and I could require anyone to sign a non-disclosure agreement before I told them. As long as I did not charge for the operating system in my device, this would be perfectly in compliance with GPL. (Of course, if my device ran on modified Linux, the act of selling the device would be publication, and I would have to make my modifications available to the Linux community -- but nothing would require me to disclose, for example, what motivated the modifications.) -- Mike On 2000-05-14 at 21:46 -0500, Paul Serice wrote: > Something has to give. > > So my question is whether you can prevent people from copying your > copy of GPLed software. > > If you can't, then having GPLed software on any system connected to the > internet is a security issue because preventing people from making > unauthorized copies is in violation of the GPL. > > Silly? Maybe. But I've seen Debian attack the KDE people on lesser > grounds. > > > Paul Serice > > > P.S., I understand Steve Greenland's position that I have no recourse > against an unauthorized copy, but I might have recourse against the > manner in which it is obtained. I would like to hear that I would have > recourse against unauthorized copies.
