Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > What about cases where you pay for the software before you're allowed > > to see the EULA? On Wed, Apr 13, 2005 at 11:21:42PM -0700, Sean Kellogg wrote: > It is enforcable and is called a rolling contract. Seminal case is ProCD, > Inc. v. Zeidenberg, 86 F.3d 1447 (7th Circut, 1996). That precedent is for a case where no one objected to the terms of the EULA. SoftMan Products Co. v. Adobe Systems Inc. (3rd Circuit, 2001) is an example of what can hapen when someone objects to the terms of the EULA (the court ruled that the EULA didn't apply because the software had never been run and the EULA is not presented until it is run). Step-Saver Data Systems, Inc. v. Wyse Technology (3rd Circuit, 1991) is an earlier example (court of appeals held that the EULA printed on the box was not enforceable and did not require return of the software). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > What compels you to agree with an EULA? On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote: > If you do not agree with the EULA, you cannot and do not acquire > lawful possession of the work. What about cases where you pay for the software before you're allowed to see the EULA? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > [2] I don't think you can construe this paraphrase of the GPL authors > > claims as meaning that a person using that grant is free to ignore the > > conditions imposed by the GPL. On Wed, Apr 13, 2005 at 03:49:44PM -0700, Sean Kellogg wrote: > Not quite sure what you mean hear... but I do know that a grant cannot > impose active conditions. If the active conditions are enforceable, > then they need to be in a contract. If my grant says "you can do X, > but only if you do Y" then it it is a contrct. If, instead, my grant > says "you can do X, but not Y" then its less a condition and more that > I reserved Y from the list of rights I gave you, so its not a contract. > The issue with the GPL is that waving right to warrenties is like saying > "you can do X, but only if you do Y", which is a contract. Basically, I think the GPL offers a contract, but the GPL is significantly more than just a contract. The warranty disclaimer is a disclaimer regardless of whether or not you use the copyright grant, though it's undoubtedly stronger if you do use that grant. > Additionally, I don't think we get anywhere with the statement that "some > jurisdictions look at it differently." This is always going to be the case, > and if we dwelled on it for too long the whole of open source software would > be swallowed by lawyers trying to write exceptions for each and every > jurisdiction. All I can do is tell you what I believe the U.S. law is on a > subject matter. Well... the answers.com page on first sale doctrine indicates some significantly different results from different jurisdictions, and indicates that until this is resolved by the supreme court there's good reason to be uncertain about what that eventual precedent will be. > > > That questions falls to a matter of agency law, not contract law. > > > Same goes for your installation of software on behalf of your dad. > > > When you clicked that agree button, you did so as his agent and he will > > > be liable. > > > > But I didn't click that agree button. > > > > He got his system with software pre-loaded. Or, the neighbor installed > > it for him. > > > > If someone entered into a contract on Dad's behalf, and did not > > disclose the contract to him, they are probably liable instead of Dad. > > For example, if the EULA prevents resale of the software, and Dad > > decides to sell the computer at a garage sale, I doubt he would be in > > any danger of prosecution. There would be no evidence whatsoever that > > Dad had entered into a contract to not sell that part of the system. > Agency law says otherwise. If I instruct my neighbor to install software > then I am instructing that neighbor to consent on my behalf. Agency law places on the agent an obligation to inform the principal of the terms of contracts the agent has entered the principal into. Until the agent informs the principal of these contracts, they are the liability of the agent. > If the neighbor installs the software without my permission, ... That's not the issue. The neighbor recommended the machine in the first place, and Dad has been following the neighbor's recommendations on what to get and so on. Dad just wants something simple that he can use. > Preinstalled software, if I had to take a guess, probably comes with a > contractual agreement that you are said to have agreed to when you buy the > thing. Although I bet you have the right to return all of that software if > you don't agree. Sure, there were probably some plastic envelope with EULAs which were included with the stuff when the neighbor picked up the machine for Dad. There might even have been some click through licenses that the neighbor dealt with while getting the machine up and working. But if that neighbor is in Iraq now, it's kinda hard to ask him. > > In any event, it's not always the case that the existence of > > click-through license means that a user has accepted the license. > > Thats right, if I can manage to install the software without seeing the > license, then I can probably get out of it. This is why the technology > requiring the click to actually happen is getting better and better. And then there's 17 USC 1201. But there's other issues as well (for example, buying software under a student discount and then reselling it -- without clicking on the license). Anyways, my original point is that you cannot simply assume that the person in question has clicked on the click-through license. That's a fact that needs to be established. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 11:26:47PM +0200, Francesco Poli wrote:
> US copyright italian author's right ("diritto d'autore italiano")
> --
> compilation work <---> collective work ("opera collettiva")
> derivative work <---> creative elaboration ("elaborazione creativa")
>
> In the USA, a compilation work is a collective work has its own
> copyright and thus is also a derivative work.
>
> I hope to get it right... or am I confused?
Sounds right.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > On Tue, Apr 12, 2005 at 11:28:59PM -0700, Sean Kellogg wrote: > > > Failure to have a click-through license means that there is no > > > acceptance, which is a fundamental part of contract law. No acceptance, > > > no contract, no exceptions. > On Wednesday 13 April 2005 06:55 am, Raul Miller wrote: > > False. > > > > For example, you can indicate acceptance of the GPL by exercising the > > rights it grants. On Wed, Apr 13, 2005 at 10:07:09AM -0700, Sean Kellogg wrote: > While I certainly appriciate the simplicity with which you view the > law, I'm going to have to stand by my earlier comment and restate, > once again, that the authors of the GPL claim it is NOT a contract, > but rather a grant/license. [1] Examples and counter-examples can be simple. But please don't pretend that they cover all issues. [2] I don't think you can construe this paraphrase of the GPL authors claims as meaning that a person using that grant is free to ignore the conditions imposed by the GPL. [3] You might want to take a look at Richard B. Johnson's post (he posted it a couple hours before you posted your message). > Now, I've said it before, and I'll probably say it again, lots of > reasonable minds differ as to whether the GPL is actually a contract > or not. But if it is a contract then we need to start looking at > acceptance by performace. Did the party who failed to make explicit > acceptance act in a way as if he did accept? I agree. > With the GPL that's a pretty easy to sustain... the limitations on the > average user of GPL code is that they give up their right to a warranty. > As long as they don't claim otherwise, I can't see how they could act > contrary to the GPL. If you are a developer/distributor, now you NEED > to have agreed to the contract in order to exercise certain rights under > the copyright act. This means you have either accepted the contract > and given up the right to close the source of your own work, OR, you > have refused the contract and you are in breach of the copyright act. The GPL isn't intended to restrict use, so "the average user" isn't particularly interesting. It's "the average distributor" who would care or not care. (Quote: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope"). > > Furthermore, the converse is also false: it's quite possible to install > > software on your machine without clicking on the click-through license. > > For example, someone else might install it for you. [You expect my dad > > to figure out how to install anything?] > > Its an unclear area of law, in my opinion. If you install an illegal > version of Adobe Photoshop on your employers computer are they liable? I was talking about cases where the user had legally obtained the software. > That questions falls to a matter of agency law, not contract law. > Same goes for your installation of software on behalf of your dad. > When you clicked that agree button, you did so as his agent and he will > be liable. But I didn't click that agree button. He got his system with software pre-loaded. Or, the neighbor installed it for him. If someone entered into a contract on Dad's behalf, and did not disclose the contract to him, they are probably liable instead of Dad. For example, if the EULA prevents resale of the software, and Dad decides to sell the computer at a garage sale, I doubt he would be in any danger of prosecution. There would be no evidence whatsoever that Dad had entered into a contract to not sell that part of the system. In any event, it's not always the case that the existence of click-through license means that a user has accepted the license. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
GFDL redux, all over again, yet another time
While looking up laws this morning, to answer a question someone asked about the GFDL, I noticed something: 17 USC 1201 grants the copyright holder the right to authorize that technological measures be bypassed. The current GFDL trys to prevent any distribution of GFDLed documents where technological measures may restrict access to the work. In part, this is probably because anyone can apply such technological measures, without needing authorization from the copyright holder. Anyways, for debian's purposes authorization to bypass does us a lot more good than denying license to those who use measures. [1] Authorization doesn't run afould of the DFSG. [2] Authorization makes legit cracking software of any DRM code used to publish the work. Our current approach has been rather combative, and rather ineffective. "The GFDL has these problems, please fix them". I think, instead, we should offer solutions to each of the problems, and ask that the GFDL be modified to allow works to be published in a way that satisfies us. [Once we have that, we can contact authors individually and ask them to use the satisfactory terms.] [I have some ideas about further alternatives for some of the other problematic clauses in the GFDL, but they're not as good as this one. But the approach seems valid.] Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 11:28:59PM -0700, Sean Kellogg wrote: > Failure to have a click-through license means that there is no acceptance, > which is a fundamental part of contract law. No acceptance, no > contract, no exceptions. False. For example, you can indicate acceptance of the GPL by exercising the rights it grants. Furthermore, the converse is also false: it's quite possible to install software on your machine without clicking on the click-through license. For example, someone else might install it for you. [You expect my dad to figure out how to install anything?] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 01:57:29AM +0200, Francesco Poli wrote: > > The law talks about collective > > works and derivative works, and to a casual reader it appears as > > though collective works are in some way different from derivative > > works. > > Why? > Are collective works and derivative works the same thing? The definitions overlap. Not all collective works are derivative works, because "derivative work" means that the work is based on some other work and yet still has enough originality to be granted separate copyright protection. Not all derivative works are collective works, because "collective work" means that there was more than one original work, but "derivative work" means that there was one or more original work. When a collective work is not a derivative work, it's not original enough to get any special copyright protection -- it's just the original works, under whatever terms. When a derivative work is not a collective work, it's because there's only one original work. But collective works that have their own copyright are derivative works, and derivative works that have more than one original work are collective works. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 03:45:43PM -0700, David Schwartz wrote: > This wasn't a copyright case. The court only refused to uphold the > agreement because there was no oppurtunity to review the agreement before > purchase. So it certainly wouldn't apply to a click-through type agreement. http://www.answers.com/topic/first-sale-doctrine cites several cases, and has a very nice writeup on the current status of this issue. In essence, you're claiming that the difference between Davidson & Associates v. Internet Gateway Inc (2004) and other cases such as Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000) is that the presence of a click-through is the determining factor. Of course, it could just as easily be something else (for example, admitting in court agreement with the license). Does this thread have anything to do with the linux kernel at this point? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote: > Yes, the GPL can give you rights you wouldn't otherwise have. A > EULA can take away rights you would otherwise have. What compels you to agree with an EULA? > In the few court cases that have directly addresses shrink-wrap and > click-wrap type agreements, I've seen them consistently upheld. However, > this is not relevent to the GPL issue at all because the GPL can only give > you rights you wouldn't otherwise have, it cannot take away any rights. The GPL offers you certain rights if you agree to be bound by certain conditions. You are not compelled to agree to those conditions, but those who do not gain no rights from the GPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 12:01:15PM -0700, David Schwartz wrote: > Would you agree that compiling and linking a program that uses > a library creates a derivative work of that library? No, I would not. Creating a derivative work requires creativity, and a linker is not creative. The copyright issues for the linked program are the copyright issues for the unlinked program. Of course, you might have evidence in the form of a linked program where you don't have evidence in the form of an unlinked program. But that's a practical issue, not a copyright issue. > And doesn't first sale give you the right to normal use of a work you > have legally acquired? The first sale doctrine (basically, 17 USC 109) doesn't really say that. > There are many ways you can lawfully create a derivative work without > explicit permission of the copyright holder. One clear case is when you > lawfully possess the work, there is no EULA or shrink-wrap agreement, and > you need to produce a derivative work to use the work in the ordinary > fashion. I don't think the words you're using mean what you think they mean. I'm just going to quote part of 17 USC 106 at you. "... the owner of copyright ... has the exclusive rights to ... prepare derivative works ...". Go look it up yourself if you think the text I've omitted makes it mean something different. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 09:44:29AM -0700, David Schwartz wrote: > I would say that if not for the EULA, you could transfer ownership > of the image to someone else. And if you legally acquired two copies of > Windows, you could install both of them and transfer them. Otherwise, > you could not sell a machine with the Windows OS installed unless you > were a Microsoft OEM. Does Microsoft take the position that if you want > to sell your PC, you must wipe the OS? Not that I know of. [1] I think you've confused Microsoft's Original Equipment Manufacturer License with Microsoft's End User License Agreement. [2] The grounds for Microsoft's EULA are much weaker than the grounds for the GPL restrctions on the production of derivative works. At least with the GPL, you're getting something you didn't already have (rights restricted to the copyright holder -- for example, in the states, under 17 USC 106). With Microsoft's EULA, it's not clear that you're getting anything in exchange for complying with the copyright -- at least not in the U.S. which is where Microsoft is based. You already have a number of rights (17 USC 107, 17 USC 117), and while the DMCA has put into law that you can't bypass copyright protection (17 USC 1201), it seems to allow bypassing technological defects which would prevent actions allowed under copyright. It's probably worth noting that legal actions based on Microsoft's EULA are settled out of court -- Microsoft has a history putting a lot of direct and indirect pressure on people charged with violating the agreement and, in the rare case where someone has stood up to the pressure, of cutting their losses and settling out of court. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Mon, 11 Apr 2005 01:47:19 +0100 Henning Makholm wrote:
> > (I wonder what happens in jurisdications whose copyright law is not
> > phrased in terms of "derived" - or that have several native words
> > which are given different explicit meaning by the local law but would
> > all need to be represented as a form of "derive" in English).
On Tue, Apr 12, 2005 at 12:21:40AM +0200, Francesco Poli wrote:
> In jurisdictions such as the Italian one, for instance?
>
> In Italian author's right law ("legge sul diritto d'autore"), there is
> no use of or definition for the term "derivative work", AFAICS.
>
> The law speaks about collective works ("opere collettive") and creative
> elaborations of the work ("elaborazioni di carattere creativo
> dell'opera").
> The former term refers to works that result from joining other works or
> parts of works in a creative way (by means of choice and coordination
> for a specific goal).
> The latter refers to substancial transformations and modifications (of a
> work) that have creative character.
This may just be a notational difference.
In U.S. law, similar concepts exist. The law talks about collective
works and derivative works, and to a casual reader it appears as though
collective works are in some way different from derivative works.
In U.S. law, in both kinds of cases, an issue is: is there enough
creativity in this derivative work for it to be granted copyright coverage
as a unique work?
However, for collective works there's some additional writeup to
distinguish editorial work on the anthology (or whatever) from editorial
work within a particular work.
But, of course, it's legal to publish an anthology and also edit the
stories within that anthology (as long as you have adequate copyrights).
I'd be surprised if Italian law didn't have this same basic structure,
though perhaps with different details.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 11:24:10AM +0200, Giuseppe Bilotta wrote: > AFAIK software only refers to programs, not to arbitrary sequences of > bytes. An MP3 file isn't "software". Although it surely isn't hardware > either. This point is a controversial point. Different people make different claims. For example, http://www.answers.com/software -- the Computer Desktop Encyclopedia asserts that you are correct, while Wikipedia asserts that you are incorrect. The American Heritage Dictionary implies you are correct, and WordNet implies that you're incorrect. Usage is still evolving, so who knows where this issue will stand in five years. In the context of the linux kernel (which I presume you're talking about, given the message headers), I don't think it's plausible to suggest that the occasional use of the term "software" in the license means that the stuff under Documentation/ isn't covered by the license. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 12:31:53PM -0700, David Schwartz wrote: > Perhaps you could cite the law that restricts to the copyright > holder the right to restrict the distribution of derivative works. I can > cite the laws that restrict all those other things and clearly *don't* > mention distribution of derivative works. 17 USC 103 17 USC 106 -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: > You could do that be means of a contract, but I don't think you > could it do by means of a copyright license. The problem is that there > is no right to control the distribution of derivative works for you > to withhold from me. While you are may be reporting your thoughts accurately, this problem doesn't seem to be a legal issue. The GPL explicitly discusses this issue (section 5), and a number of people have already posted with similar commentary. Anyways, one thing to keep in mind here is that if copyright law doesn't allow the GPL's grant of permission to be conditional then copyright law would not allow other copyright grants to be conditional. Another way of looking at this is that the GPL is a copyright license -- it represents the terms and conditions under which copyrights are granted, and it also represents those permissions. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > It's impossible to treat patents consistently. On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote: > Even RedHat with a stronger financial background than Debian considered > the MP3 patents being serious enough to remove MP3 support. It's silly to treat financial risk as being a one dimensional quantity. It could easily be that Red Hat decided that the mp3 patent owners would be going after people with deep pockets. If this is the risk model, Red Hat's risk would be much much higher than Debian's. > Note that this is a respose to Josselin's statement: > < When there are several possible interpretations, you have to pick up the < more conservative one, as it's not up to us to make the interpretation, < but to a court. Sure, if you have several plausible interpretations, you pick the one you feel is likely to be the most important, and if all of them seem likely you pick the one that seems worst. But, ultimately, you can't treat software patents consistently. There's no reasonable way to do so. > It's simply silly to be extremely picky on copyright issues while being > extremely liberal on patent issues - the risk of a Debian distributor > being sued for patent violations (no matter how the lawsuit might end) > is definitely present. Anything to do with software patents is silly. Being liberal about software patents is silly. Being conservative about software patents is silly. Copyright, while far from perfect, can at least be reasoned about. > > As for this particular patent, I'm not really sure what's being patented. > >... > Which one of the 23 patents they list do you call "this particular > patent"? What makes you think I'm sure about what's being patented in 22 of those patents? I should probably have said "As for patent claims applying to mp3, ...", but the issue is thorny enough that even that might not have been accurate enough. But, treating "this particular patent" as a meta-syntactic variable should be adequate for you to understand what I was saying. Bottom line, though: softare patents generally make very little sense. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: > If Debian was at least consistent. > > Why has Debian a much more liberal interpretation of MP3 patent issues > than RedHat? It's impossible to treat patents consistently. The U.S. patent office, at least, has granted patents on natural laws, on stuff that's already patented, on stuff with clear prior art, on trivial math operations and so on. Patents are being granted so quickly there's no way of even knowing what's patented. Or were you hoping that Debian would follow Red Hat's lead? As for this particular patent, I'm not really sure what's being patented. Trial and error? Spectral quantization? The specific data format? Addition, multiplication, and exponentiation? In many respects, mp3 is similar to jpeg. Does that mean that any use of the techniques used by jpeg in the domain of audio is covered by this patent? Does that mean that jpeg is in violation of this patent? If I use the same kind of math with a time dimension, am I violating some other mpeg patents? What about the other hundreds of thousands of patents? How many of them am I violating when I use lossy compression based on spectral quantization? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 09:41:35AM +0200, Sven Luther wrote: > BTW, have any of you read the analysis i made, where i claim, rooted > in the GPL FAQ and with examples, why i believe that the firmware can > be considerated a non derivative of the linux kernel. I hadn't. I did just now. Here's my opinions, after reading it: [1a] It's pretty long, and some of the redundancy is not really relevant to the issue at hand. This might be less of an issue, except [1b] It has some grammar problems that should be fixed. [2] The presented arguments all look plausible. Maybe I should study it more, but I didn't see any significant logical flaws. [3] It focuses on debian issues more than kernel issues (though a dedicated reader could see some issues relevant to the linux-kernel mailing list). I agree with both you and the gpl faq writers that "communicates at arms length" is probably a good measure of whether or not the kernel and the module are the same program. I can think of cases where this wouldn't hold (GPLed documentation, for example), but those kinds of issues don't seem to be relevant here. > I further argumented that taking any different stance would bring us worlds of > hurt as we would consider the bios as being a derivative work of the kernel > they are running, or the bootloader, or the firmware present in proms on > devices loaded into the system and so on. Here, you've confused two issues: "Are A and B part of the same program?" and "Are A and B together part of a derivative work under copyright law?" Sometimes one is true, sometimes the other is true. You have a GPL issue when both are true. One question has to do with the function of A and B. The other question is whether the combination is eligible for copyright protection. Copyright protection is not granted or denied because of functionality. The functional issues are relevant only because they're written into the license. Of course there can be other GPL issues (e.g. it's bad to put a GPL notice on something which isn't GPLed). And, of course, there can be non-GPL issues (pulling the blobs out of the kernel lets people update their firmware without having to compile the kernel or a kernel module). > I think only the fact that if you consider firmware as being a derivative > work, you should consider it a derivative work also when it is flashed on the > prom of a pci card or what not, is decisive enough to make those firmware > blobs not derivative works of the kernel they are under. Uh... not precisely. You have your facts straight, but your logic is bad. This fact alone isn't enough to decide whether or not firmware is a derivative work. Fortunately this thought isn't a big deal for the cases we're currently talking about. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 08:05:31PM -0700, David Schwartz wrote: > I think we have a real problem, however, in cases where the source > file that holds only the firmware data contains a GPL notice. Sure: the GPL notice isn't completely valid. But I think people have already decided that this is an issue that needs to be fixed. And, I think most of the approach for fixing these is fairly clear. That said... perhaps it's worth going over a hierarchy of copyright issues: First, there's the issue of whether or not work is protected by copyright. I think we're talking about stuff that's protected by copyright. If it is protected by copyright, there's the question of whether the things being done with that work are regulated by copyright law. I think we're talking about activities (making copies of linux and distributing it) which are regulated by copyright law. If both hold, the next question is whether or not the copyright license allows this use. As you've indicated, we do have some real issues here. Finally, if you're dealing with regulated activity and the license doesn't allow it, it's up to the copyright holder to decide whether or not to prosecute. So far, the copyright holders haven't said much about these issues. We probably have some issues where what we're doing is only by the good graces of the copyright holder(s). We should fix those things, of course, but currently there aren't any deadlines we have to meet. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > Also, "mere aggregation" is a term from the GPL. You can read what > > it says there yourself. But basically it's there so that people make > > a distinction between the program itself and other stuff that isn't > > the program. On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: > It's also there because the GPL can only apply to either works > placed under it by their authors and works that are legally classified > as derivative. If you merely aggregate two works, there is no > derivation. The GPL is making clear that it's not trying to exceed the > scope of its authority (which is copyright law). The issue of whether or not the combined work is a derivative under copyright law is a copyright law issue. The GPL does concern itself with that issue, but not in the "mere aggregation" clause. The "mere aggregation" clause holds regardless of whether or not the combined work is a derivative under copyright law. [P.S. I've set the Reply-To: header on this message because I think this thread has drifted away from kernel issues.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote: > If you believe the linker "merely aggregates" the object code for the > driver with the data for the firmware, I can't see how you can argue > that any linking is anything but mere aggregation. In neither case can > you separate the linked work into the two separate works and in both > cases the linker provides one work direct access to the other. You can indeed separate the firmware and the kernel into two separate works. That's what people have been proposing as the solution to this problem. Also, "mere aggregation" is a term from the GPL. You can read what it says there yourself. But basically it's there so that people make a distinction between the program itself and other stuff that isn't the program. Without that mere aggregation clause, people might be claiming that text on a disk has to be GPLed because of emacs, or that postscript files have to be GPLed because of ghostscript, or more generally that arbitrary object FOO has to be GPLed because of gpled program BAR. Put another way, what the linker does or doesn't do isn't really the issue. People like to think that the linker is somehow special for copyright, but it's not. Either the stuff being linked is protected by copyright even when it's not linked or it's not protected by copyright after it is linked. If the license says something about linking then that matters, but only for cases where the code was protected by copyright even before it was linked. And then linking only matters in the specific way that that license says it matters. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> Josselin Mouette wrote: > >It merely depends on the definition of "aggregation". I'd say that two > >works that are only aggregated can be easily distinguished and > >separated. This is not the case for a binary kernel module, from which > >you cannot easily extract the firmware and code parts. On Tue, Apr 05, 2005 at 04:00:32PM -0300, Humberto Massa wrote: > Not really... As a matter of fact, it's quite easy to separate those > parts, at least as easy as it is to separate one story inside a book > that contains an anthology of short stories. And the latter is not > considered a derivative work, either. I'm not sure who it is that doesn't consider anthologies a derivative work. The u.s. copyright office considers anthologies and other compilations derivative works except when they involve insufficient creative work to grant them copyright protection. http://www.copyright.gov/circs/circ14.pdf But it's probably not interesting to argue any further about the inner workings of copyright law. Pretty much everyone seems to agree on what the right approach is, here. The big issue seems to be stability of linux during the transition. The interesting topics, at this point, have to do with the details of migrating such drivers out of the kernel. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Concerns about works created by the US government
On Wed, Apr 06, 2005 at 05:55:36PM +0300, Sami Liedes wrote: > The relevant US law says (title 17, chapter 1, § 105): >Copyright protection under this title is not available for any work >of the United States Government, but the United States Government >is not precluded from receiving and holding copyrights transferred >to it by assignment, bequest, or otherwise. > > This certainly seems to make the works effectively PD in the US; > however it almost seems as if that was carefully worded to _not_ place > works in the PD, only to make the US government unable to enforce > their copyright under the US law. I think this is drawing a distinction between government works and works received by the government from elsewhere. For example, the Library of Congress receives copyrighted works, but that doesn't mean that they're works of the goverment. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sql-ledger may belong in non-free
On Mon, Apr 04, 2005 at 03:35:10AM -0500, Warren Turkal wrote: > I was reading through the Terms & Conditions[1] (henceforth Terms page) > on the and I am not sure that it conforms to the DFSG, specifically > section 3. If you look at the Terms page, you will notice that the > section on "Extending and Re-branding SQL-Ledger" indicates that the > GPL only allow the derivative work to be a "Larger Work" and that you > cannot remove the SQL-Ledger logo as a result. That's a bit confusing. I don't know whether that's because they're confused or if it's deliberate. You can't remove other people's copyright notices from a GPLed work, so where the trademarked name occurs as a part of a copyright notice, the GPL says you can't remove it. However, the GPL doesn't say any such thing about the source code referred to by those notices. Also, just because a sentence has the word "copyright" and "notice" in it doesn't mean that the sentence is a copyright notice (otherwise this sentence would be a copyright notice). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Apr 04, Sven Luther <[EMAIL PROTECTED]> wrote: > > is waiting for NEW processing, but i also believe that the dubious > > copyright assignement will not allow the ftp-masters to let it pass > > into the archive, since it *IS* a GPL violation, and thus i am doing > > this in order to solve that problem. On Mon, Apr 04, 2005 at 09:47:50PM +0200, Marco d'Itri wrote: > Sure, and I suppose that the SuSE and Red Hat lawyers who are allowing > them to distribute this "violation" are all morons, right? That's an irrelevant question: The linux kernel is big and complicated enough that the presence of any non-immediate problem tells us little about anyone. If those lawyers have specifically read this part of the code and realized that the GPL notices on these bits of code are invalid they've probably adopted a "wait and see" approach. There's probably no way to determine whether or not Red Hat or SuSE pay their lawyers to read the kernel code, looking for mis-handled copyright issues. But I'd guess that there's not a lot of money to be made that way. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
> Raul Miller <[EMAIL PROTECTED]> writes: > > Right, in the sense that copyright is about tangible forms of creative > > expression, and it's not about functional mechanisms such as interfaces. On Mon, Apr 04, 2005 at 12:16:28PM +0200, Måns Rullgård wrote: > Mechanisms like header files, for instance. Or like paper and ink: Copyright doesn't protect paper and ink. Copyright will protect some things expressed in paper and ink, but that's a completely different focus. > If writing that story on the command line is required for using the ... "required" means you're talking about function. Copyright doesn't protect function. > > I was trying to say that just because something is a relevant interface > > in case A doesn't mean that that kind of interface is relevant in case B. > > Who gets to decide what is relevant, and when? At one level of abstraction, a judge. At another level of abstraction, treaty writers and law makers. At another level of abstraction, the copyright holder (who chooses what issues are worth pursuing and which are not). But as a general rule, none of them will be focussing on the mechanics except as an incidental issue. Mechanics are a detail, like date and time -- used to establish whether presented testimony is factual. Beyond that they're not the subject of discussion. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
> > If you can find us a country whose laws make this illegal, > > this issue would be worth discussing. On Fri, Apr 01, 2005 at 06:15:34PM +0200, Måns Rullgård wrote: > You are obviously convinced that using a command line interface can't > be protected by copyright. Right, in the sense that copyright is about tangible forms of creative expression, and it's not about functional mechanisms such as interfaces. So, for example, this lack of copyright protection for command line interfaces doesn't mean that I can put some copyrighted story on the command line and make its copyright protection go away. > Why, then, are you so persistent in insisting that other interfaces > somehow are awarded such protection? That wasn't what I was trying to say. I was trying to say that just because something is a relevant interface in case A doesn't mean that that kind of interface is relevant in case B. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Thu, Mar 31, 2005 at 09:17:51PM +0200, Måns Rullgård wrote: > Thanks for mentioning command lines. Running a program from the > command line, usually involves passing it options. These options are > (obviously) copies of strings from the actual program. Can this > copying be a copyright violation? IMHO, it is no different, in > principle, from using function names declared in a header file. If you can find us a country whose laws make this illegal, this issue would be worth discussing. If the laws of that country were available in english, we could probably do justice to that (hypothetical) discussion. If there are any such countries, and they make a practice of enforcing such laws (rather than just having them on the books to confuse novices), we should probably put together a page warning people to about using computers in that country (or those countries). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
> > Those .h files were held to be not protected by copyright because no > > viable alternatives were available to interface with the system. > > It's hard to see how this reasoning would apply in a context where there > > is some viable alternative available to interface with the system. On Wed, Mar 30, 2005 at 04:15:57AM +0200, Måns Rullgård wrote: > Alternative to what? There can be no alternative to the full set of > interfaces to the system. Are you trying to argue, that several > interfaces exist, use of each one is protected due to the existence of > the others? For example: gcc provides a command line interface as an alternative to rebuilding gcc every time you need to compile a program. > Suppose there is only one interface, such that it, per your reasoning, > is not protected. Now add another. Does this addition suddenly make > the first interface protected? What if they were created in the > opposite order? That all depends on the design of the program in question, how it's documented, how it's licensed, and so on... -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote: > >>My claim was: "*Basically*, bits in .h files are not > >>copyrightable". Which I now solemnly amend to "The kind of bits you > >>normally (>99% of the times) find in .h files in c-language based > >>projects, and often (>50% of the times) find in .h files in c++ based > >>projects, are those defining interfaces, deeming them uncopyrightable > >>by current USofAn and Brazilian law". Better? > Raul Miller wrote: > >However, for U.S. law, this isn't necessarily the case. On Mon, Mar 28, 2005 at 04:14:47PM -0300, Humberto Massa wrote: > I was referring to the fact that there is some case law in the USofA > that deemed interface definitions, as present normally in .h files, > uncopyrightable. > > HTH Those .h files were held to be not protected by copyright because no viable alternatives were available to interface with the system. It's hard to see how this reasoning would apply in a context where there is some viable alternative available to interface with the system. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2#
> On Sat, Mar 26, 2005 at 11:16:29AM -0500, Raul Miller wrote: > > This seems to imply that there's some single perspective which can be > > easily described to clarify this issue. On Sat, Mar 26, 2005 at 12:08:08PM -0500, Glenn Maynard wrote: > I was asking for Andrew's perspective, not The Perspective. Now you seem to be implying that Andrew has only one perspective on this issue. > I don't even feel strongly about this, and wasn't particularly > expecting to argue about the answer; I was just curious why he dislikes > fair use so much as to use such a strongly negative word, and found > it strange that a simple "why do you think that?" inquiry resulted > in evasive maneuvers. Andrew seems to avoid Red Herring arguments more than I. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Mon, Mar 28, 2005 at 11:25:39AM -0300, Humberto Massa wrote: > Troll editing. My claim was: "*Basically*, bits in .h files are not > copyrightable". Which I now solemnly amend to "The kind of bits you > normally (>99% of the times) find in .h files in c-language based > projects, and often (>50% of the times) find in .h files in c++ based > projects, are those defining interfaces, deeming them uncopyrightable by > current USofAn and Brazilian law". Better? I don't know about Brazilian law. However, for U.S. law, this isn't necessarily the case. A key feature of U.S. copyright law is that it's creative expression which is being protected -- not form or function. In other words, if the software in question provides some other interface then U.S. law overriding copyright for interface purposes probably wouldn't apply. [A strong legal case could be made here, though I don't think anyone has actually taken this particular issue to court.] On the other hand, in a case where this mattered, the .h files would not probably not be considered in isolation. You could say that copyright law does not factor issues on functional boundaries, except as a notational convenience. Instead, in the context of copyright, issues are factored on creative boundaries. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2#
> On Fri, Mar 25, 2005 at 09:55:40AM +, Andrew Suffield wrote: > > 'Worse' is purely a matter of perspective. There's irony here... On Fri, Mar 25, 2005 at 05:31:27AM -0500, Glenn Maynard wrote: > No, there isn't. It's very simple. You called it a "perversion", > which means you think it's worse. I asked why you think it's a > perversion. (In other words, "what is your perspective that makes > you consider is worse?") You won't answer. This seems to imply that there's some single perspective which can be easily described to clarify this issue. Personally, while I wouldn't describe things using the terms Andrew has, I think I see something similar to his point. For example, one perspective is: computer programs, in the general case, shouldn't be regulated by copyright law. Note that this particular flavor of perspective is not claiming that computer programs should not be regulated (though it does fit with that kind of argument). It could just as easily be a part of an argument for other kinds of regulations (perhaps far more restrictive than anything we've seen to date). That said, it's probably worth noting that until the mid-1970s, computer programs were thought to be not copyrightable. And, because of the economics of the time this wasn't a big deal for a lot of people. I think one of the reasons IBM has taken to open sourced software so well is that their business model was developed under those conditions -- they actually started losing ground, financially, when they switched to an ultra-restrictive license model. [But they were in some sense forced to do so, because if something isn't copyright protected it can be incorporated in something which is copyright protected by someone else, which has unpleasant business connotations.] Anyways, the original quip should probably just be taken as a statement that Andrew is dissatisfied with the system of copyright laws. We don't have to turn this into some kind of forum for discussing potential alternative systems. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
On Wed, Mar 23, 2005 at 10:56:49AM -0300, Humberto Massa wrote: > Whoa, slow down, cowboy! Re-read what I have written up there: <<".h" > _bits_ are not copyrightable>>. Now take a deep breath. The thing is: it > is considered by USofA and other countries case law that the bits that > are at compile/link time from a .h file (as you mentioned down here, as > macros and inline functions) are not really being "included" in the > work, but are in reality being "referenced" on it. Even assuming that this "considered" has some legal basis, this "rule" utterly misses the point. You have a decent heuristic there, but it's just a heuristic -- it doesn't mean anything legally. In the U.S., derivative works don't need to include a literal copy of any of the original to be derivative works. All they need to do is include more creative content than "fair use". See circular 14 (http://www.copyright.gov/circs/circ14.pdf) for more detail on what is and is not a derivative work. In particular, note that it uses the phrase "based on" 11 times. See circular 21 (http://www.copyright.gov/circs/circ21.pdf) for more detail on fair use. Outside the free software community, copyright infringment cases frequently involve works with many superficial differences. Just because we're usually dealing with relatively unambiguous questions doesn't mean that's always the case for copyright law. Which, perhaps, is one of the reasons proving "financial harm" is one of the key issues in most copyright infringement cases. As another heuristic, that's when use isn't fair use. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Tue, Mar 01, 2005 at 06:17:56AM -0800, Ben Johnson wrote: > After a quick search to try and find if the FSF ever > voiced an opinion on nv, I unfortunately only dug out > the well-known case against NVidia's binary kernel > module. Will any of the X nVidia support work without that binary kernel module? Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mplayer, the time has come
On Sat, Feb 26, 2005 at 09:26:18PM +, Andrew Suffield wrote: > Of course, how else are people going to notice all the contemptible things? Given that there's an effectively infinite supply of worthless, useless and irrelevant things to express contempt at, I'd guess that people will never notice all the contemptible things, regardless of your efforts, or lack. [Note that I'm not commenting on the utility, or lack thereof, of expressing contempt to achieve some other purpose. I'm simply answering your question, as stated.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
> On Fri, Feb 25, 2005 at 11:33:29PM -0500, Raul Miller wrote: > > On Fri, Feb 25, 2005 at 02:02:57PM -0800, Ben Johnson wrote: > > > http://www.mail-archive.com/devel%40xfree86.org/msg03961.html On Fri, Feb 25, 2005 at 11:40:16PM -0500, Justin Pryzby wrote: > Can someone tell me specifically what files we're discussing? A quick google search for the line quoted in the above message turns up http://www.oxxus.net/host/2.6.8/hosting-riva_hw.htm which looks like riva_hw.c. More specifically, it contains the comment: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/nv/riva_hw.c,v 1.33 2002/08/05 20:47:06 mvojkovi Exp $ */ If you really want to find all files of this flavor, it be worth grepping for similar files. Perhaps the regular expression PGRAPH.0x[0-9A0-F]*/4 would be a good place to start. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mplayer, the time has come
On Thu, Feb 24, 2005 at 08:52:12PM -0800, Sean Kellogg wrote: > Can this list PLEASE stop the belief that ducking your head in the > sand in regard to patent violations saves you from increased liability? What would that achieve? I don't think that we ignore patents because we believe that in doing so we will encounter some liability but less than if we paid more attention to them. Some people might have expressed such opinions, but they really don't make sense. I think we largely ignore patents because as a general rule the patents and the patent system don't make sense. There's little to be gained by dealing with them, as a general rule. We have dealt with specific patent issues in the past, for high profile patents, and I'm sure we'll do so in the future. But, for the most part, this is just a waste of time. Reasons it's a waste of time: [1] Typically, prior art exists (but is costly to locate examples of while will hold up in court). [2] The number of patents which may apply to any piece of software is unknowable, and very large. [3] Debian does not have deep pockets. In a sense, patents are mostly a "PR" issue. If we do something nasty and unpleasant in the context of patents, that's bad PR for us, and we lose. If some major corporation does something nasty and unpleasant in the context of Debian and patents, that's bad PR for them, and they lose. In either case, our users probably lose. In most cases it's also likely that Debian would lose and the corporation bringing the lawsuit would lose. Debian would lose time and effort defending ourselves. The corporation would lose legal costs, perhaps some good will, and might also lose patent coverage (assuming we can find adequate prior art -- perhaps from some superficially unrelated field). If you want to worry about patents, feel free. But last time I paid attention to this issue, our policy was to pull stuff if specifically asked, or if we felt there's a significant chance we would be asked, unless we had good reasons to go ahead and distribute the stuff anyways. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Fri, Feb 25, 2005 at 02:02:57PM -0800, Ben Johnson wrote: > http://www.mail-archive.com/devel%40xfree86.org/msg03961.html Looks to me like it's been run through cpp, or the equivalent. While this might be classified as obfuscation, it's more likely that the associated definitions are verbose, unwieldy and somewhat broken. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Authority and procedures of debian-legal
On Sun, Feb 06, 2005 at 04:06:32AM +1100, Glenn L McGrath wrote: > For debian-legal to abide by Debians Social Contract, i think someone > should be attempting to "exhaustively list non-free restrictions". To my knowlege, no one has prevented you from attempting to make such a list. Of course, since there's no bound on "non-free restrictions", you'll barely be able to scratch the surface of all the possibilities before you die of old age. But you are a volunteer, accountable to yourself -- feel free to put your time where you think it's worthwhile. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is choice of venue non-free ?
On Thu, Feb 03, 2005 at 01:50:16PM +, Matthew Garrett wrote: > If a large US corporation violates my copyright license, I'm likely to > stand a significantly better chance if I can sue them in the UK. To some > extent, I think it comes down to intent - if people are introducing > these clauses with the desire to restrict people's behaviour above and > beyond the terms of the license, then that's non-free. If they're doing > it in order to make it easier to enforce the terms of the license, then > I think the situation is less clear. I think I agree on this point. If the license is otherwise DFSG free, it's more likely that choice of venue would be used to deal with "Foo, Inc. is stealing my code by not releasing the modified sources" than with "Smith, J. is figuring out what my sup3r s3krit code does, and telling people about it". -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
On Tue, Feb 01, 2005 at 01:21:32PM +, Gervase Markham wrote: > This is not a criticism of Eric - as Firefox package maintainer, his > opinion is clearly important. But is this sort of thing merely something > one has to accept when dealing with Debian, or is there anyone in > authority who can actually give me a consistent story here? Well... to some degree it's the way Debian is. As far as authority goes, the package maintainer is the primary authority for issues regarding that package. There are limits and balances on that, but unless we have a really good reason we're not in a position to override the maintainer. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Mon, Jan 31, 2005 at 10:18:56PM -0500, Walter Landry wrote: > You have made a very convincing argument that "required to install" is > too broad. My criteria is "required to run". If you're talking about the scope of copyright law, or the relevance of the license granted by the GPL, you're talking about "required to copy". If you're talking about the DFSG, you're not talking about a legal issue, but a set of guidelines, and the scope is Debian, and adoption into its archives. You might have some personal "require to run" criteria, for some context. But please don't mistake that for a copyright issue. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL as a license for documentation: What about derived works?
On Mon, Jan 31, 2005 at 12:09:18PM +0100, Frank Küster wrote: > Would it be possible to create something like a reduced form of the GPL, ... This isn't really the right forum for that. Maybe the fsf licensing forum would be better? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> >>If the > >> GPLed work is separate from other works under copyright law, it > >>doesn't contaminate them at this point. Walter Landry wrote: > > This is wishful thinking. The paragraphs after GPL 2c clearly cover > > collective works. On Sat, Jan 29, 2005 at 10:02:19AM +, Lewis Jardine wrote: > Are you sure this is the case when the work is unmodified? > > As I understand it, in the case of an unmodified work, section 2 (and > thus, 2b) does not apply: (GPL 2: "You may *modify* your copy or copies > of the Program or any portion of it, *thus forming a work based on the > Program*...", my emphasis) - if you don't modify it, you don't activate > section 2b, and you don't form a work based on the Program. If you have > some other works that are not "any derivative work under copyright law", > then you could distribute them alongside the unmodified GPLed work, > without activating section 2, regardless of how closely the works > interact with the GPLed work*. Walter Landry seems to be arguing that the scope of section 2 is the entity who makes the changes + any copyrightable work distributed by that entity + running the program + apt sections. In other words, if you modify emacs so that it loads faster, and then you distribute emacs with some "patches only" licensed source code, then you'd be violating the GPL if that source code was in main, but not if that source code was in non-free. Except, I'm sure he'd argue that that doesn't matter because emacs isn't running the source code, it's only displaying it. Or perhaps he'd argue something else which tries to make notions of functionality a copyright issue. Anyways, to my mind the thing missing from your explanation (which was basically good) is that a little critical thinking needs to happen to identify the work being modified. Clearly, modification doesn't alter the permissions granted by the "mere aggregation" clause, because both are in section 2, with the "mere aggregation" clause being an addition to the modification rules. So there has to be some other reason -- besides modification -- for the components of some derived work to be considered as part of a work (a Program) which is more than mere aggregation. Here's how I'd phrase the criteria: If A and B are copyrightable modules of work C, where A is GPLed and B does not satisfy the terms of the GPL, then distribution is restricted by the GPL if B was specifically created to go with A. There are some edge cases where this way of expressing things doesn't work so well, but we don't seem to be discussing those kinds of things at the moment. Finally, it's worth noting that the permission to distribute unmodified copies only applies to the source. Another way of putting this is that binaries are always treated as modified copies. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL as a license for documentation: What about derived works?
On Fri, Jan 28, 2005 at 11:56:25PM -0500, I wrote:
> The Berne Convention does not appear to use the term "derivative"
> at all. The only place I can find that uses related worde
> (derived, and collection) is Article 14 and 14ter, in reference
> to ("derived") cinematographic production based on other
> kinds of works and ("collection") the collection of fees.
> (http://www.law.cornell.edu/treaties/berne/overview.html)
Oops, I missed the use of "collection" in section 2bis of
the Berne Convention. This doesn't change my understanding
of the issue, but I should mention it, for completeness.
Thanks,
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL as a license for documentation: What about derived works?
On Fri, Jan 28, 2005 at 07:44:38PM -0800, Michael K. Edwards wrote:
> Any given country's implementation of the Berne Convention may vary
> somewhat, but the US statute (at least as of 1986) and the case law I
> have seen are consistent with the interpretation that "compilations"
> (or the subset "collective works") are a disjoint category from
> "derivative works". See 17 USC 101, and compare the UK CDPA sections
> 3 (1) (a) (a "table" or "compilation" is a subtype of literary work)
> and 21 ("adaptations" are defined to cover essentially the same scope
> as Berne Convention "derivative works").
The Berne Convention does not appear to use the term "derivative"
at all. The only place I can find that uses related worde
(derived, and collection) is Article 14 and 14ter, in reference
to ("derived") cinematographic production based on other
kinds of works and ("collection") the collection of fees.
(http://www.law.cornell.edu/treaties/berne/overview.html)
Furthermore, if 17 USC 101 is a basis for "collective works" being
disjoint from "derivative works" then it's also a basis for "computer
program" being disjoint from both. Which is clearly not the way a court
would treat computer programs.
I think that the mathematical concept of a disjoint set misconstrues the
nature of legal definitions. The difference is more one of focus. There
is no need to believe that there is some precise legal difference between
"an anthology" and "a work based on one or more preexisting works".
Finally, I agree that "linking doesn't create a derivative work".
But I also feel that this statement about linking can be misleading.
Before a program can be successfully linked with some other body of work,
it is already a derivative work, or not a derivative work, of this other
body of work.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > The license on Eclipse doesn't make an issue of this. > > > > The license on Kaffe explicitly says that running Kaffe is not restricted. > > > > So you have no plausible reason for believing that this matters. On Fri, Jan 28, 2005 at 09:55:10PM -0500, Walter Landry wrote: > Ok. One more time. The license on Kaffe says that distributing Kaffe > with other things can be restricted. That's not a plausible reason for believing that your "Eclipse can't go in main because of the GPL" has any validity to it. > > Irrelevant, until you show some reason for this to matter in > > the specific case of Eclipse and Kaffe. > > You gave alternate heuristics. I gave reasons why they won't work. > Please pay attention. Your "reasons" are nothing more than sentence fragments, taken out of context. > > But I should note that I'm not claiming that any of these criteria should > > stand by themselves. > > Perhaps you should take some time and consider these things a little > more. Otherwise, you are just wasting everyone's time. If I had any respect for your interpetation of the issue we're currently discussing, I might take you up on this suggestion. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > You and Brian keep on claiming that. Do you actually have anything > > solid on which to base this assertion? On Fri, Jan 28, 2005 at 09:56:13PM -0500, Walter Landry wrote: > The GPL mentions whole works, and I have given my criteria of a whole > work: Requires to run. Both of these statements are true. However, the GPL specifically allows certain kinds of "whole works", and only places certain restrictions on certain kinds of "whole works" and your criteria isn't a part of the GPL. > The Debian Depends: relationship is also useful and mostly equivalent. It's mostly equivalent to your criteria. It's useful in the context of apt. But that doesn't constitute a basis for your claims about the GPL. > I have not seen any other criteria which matches what the GPL actually > says. Try the GPL faq. > As I mentioned before, I am open to discussion on what the criteria > should be, but it does have to match what the GPL says. The only way you'll have text which means exactly what the GPL says is to limit the text in question to the GPL. Other than that, it's quite reasonable to talk about what the GPL says in the context of specific works. However, you haven't provided anything I recognize as a valid refutation of the points I've been making. You've simply been quoting sentence fragments, and pretending that they make sense in this context. > > * Kaffe will happily install without Eclipse > > * Eclipse will happily install, depending on any Java 2 runtime > > But there is only one Java 2 runtime in main that will work. This is not a GPL issue. This is not a DFSG issue, either. > You seem to have missed it the three other times I mentioned it, > but this discussion is about whether Eclipse goes in main, not whether > it is distributable at all. "Eclipse can't be distributed in main" is not a valid interpretation of any of the GPL restrictions. The GPL would either prohibit distribution of the work entirely, or it would allow unlimited distribution of the work. You seem to have the GPL confused with some kind of proprietary license. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Fri, Jan 28, 2005 at 12:47:21PM -0800, Josh Triplett wrote: > Good luck proving your replacement isn't a derived work after you've > studied the GPLed work you are replacing. Actually, he has a point there. There has to be significantly more going on than "read the GPLed work" for some other work to be a derived work. Remember: copyright protects creative expression, not functionality. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
> > Why assume that interoperability is the only benefit from release under > > copyleft? On Thu, Jan 27, 2005 at 07:45:29PM -0800, Michael K. Edwards wrote: > I'm not assuming that. I'm saying that the public benefit of > interoperability, used in a number of the decisions that I've cited to > justify permitting competitive use of an interface, is even stronger > when the factual situation involves cooperative use. Ok, but unless you take all benefits into account, you don't have a coherent "the benefits are better" reason for changing the license. > > For example, there's issues like "more eyes on the code", "easier to > > make derived works", and "enabling literacy". > > All of which I agree with. The GPL is a good thing. I would like to > see all of the code in the commons under the GPL. I would like to see > lots more code gifted from commercial software vendors into that > commons. I believe that the FSF's attitude on the GPL and linking > boundaries is the biggest obstacle to these goals. I'm dubious, at least for now. > > And then there's the whole area of increasing the market for some related > > product (for example: the hardware which runs the free code, or the > > training services to help people use the free code more effectively, or > > the consulting services to help businesses use the free code to improve > > their processes, or ...). > > Yes, and I've made (part of) my living for the last decade or more, on > and off, doing all of the above. One of the BSD projects? > None of these benefits go away when the closed-application/GPL-library > scenario is also permitted. It's pretty clear to me that the "easier to make derived works" does tend to go away with BSD style licenses. I'm not convinced that a "GPL modified to be more like BSD" license would not suffer the same class of problem, over time. It's very obviously the case that those closed-application licenses do not offer GPL's public benefits. > > For that matter, what makes you think that competitive use of the > > interface is being disallowed? Near as I can tell, the only thing being > > disallowed is use of the implementation and that's only being disallowed > > in circumstances where the competing use won't comply with the copyright > > on that implementation. > > Replace "won't comply with the copyright on that implementation" with > "won't comply with the FSF's interpretation, poorly supported if at > all by case law in any jurisdiction, of the power of the GPL to > leverage the copyright monopoly to dictate the licensing terms of > software that uses that implementation" and we agree. I'm not convinced that your interpetation is correct. Your reasoning is based on precedents which do not involve the copying of any copyrighted material, and on rigidly mechanical logic for how this relates to the applicability of the GPL's terms. Copyright law is not that rigid, so I don't think your logic holds. > > > You can argue that there's a completely different kind of public benefit > > > that would result from giving free software a special status, but you're > > > going to find limited legal precedent for that view. > > > > Why bring in "a special status" as an issue? > > Because that's what one is arguing for when one argues that a free > software license ought to be able to reach across an interface > boundary even if case law says that copyright itself can't. I think you've totally misunderstood the concept of what a "derivative work" is. http://www.copyright.gov/circs/circ14.html In other words, your assertion here is simply meaningless. "Interface boundary" is a mechanical issue -- one of the facts relating to the composition of the work -- which may or may not be relevant to whether copyright applies in any specific case. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > Kaffe does not require Eclipse to run. So by this heuristic, > > Eclipse is not a part of Kaffe. On Thu, Jan 27, 2005 at 09:56:34PM -0500, Walter Landry wrote: > You missed the part about Eclipse requiring Kaffe to run. The license on Eclipse doesn't make an issue of this. The license on Kaffe explicitly says that running Kaffe is not restricted. So you have no plausible reason for believing that this matters. > > > If you have a better heuristic, I am open to discussion. > > > > "Requires to build". > > I have serious doubts that only the header files would become part of > the complete work. Irrelevant, until you show some reason for this to matter in the specific case of Eclipse and Kaffe. > > "Incorporates content from". > > That would be an ordinary derived work. As I mentioned, the GPL goes > beyond derived works. Irrelevant, until you show some reason for this to matter in the specific case of Eclipse and Kaffe. > > "Designed as part of". > > So if a GPL'd program can use GNU TLS or OpenSSL, we don't have to > actually ship GNU TLS? Are you actually proposing that? I'm not discussing GNU TLS at the moment. I've not studied that issue. But I should note that I'm not claiming that any of these criteria should stand by themselves. > I think that if we can agree on what a useful criteria is, then the > rest of the discussion melts away. Ok, if we agree to avoid discussing how the issues relate to the license itself, but have some alternate agreement we hold in its place, we would be holding a different discussion. I don't disagree with this concept, I just think it's irrelevant. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > First: There is no such legal entity as "Debian" which is doing such > > things. "Debian" is a trademark of SPI, and there are people who use > > that trademark, but that's not the same thing. On Thu, Jan 27, 2005 at 09:55:30PM -0500, Walter Landry wrote: > You can replace "Debian" with "SPI" if it makes you feel better. I > feel that you are quibbling about unimportant matters. I'll agree that this is a tangential point. However, SPI has not modified Kaffe, and has no plans for doing so. > > Second, when a volunteer who associates with the name "Debian" modifies > > Kaffe, he or she does not modify it to include Eclipse. So the > > distribution of Kaffe proceeds unhindered. > The volunteers are agents of Debian. Agent: One authorized to represent and to act on behalf of another person (called the principal). Unlike an employee, who merely works for a principal, an agent works in the place of a principal. The main difference between an agent and an employee is that the agent may bind his or her principal by contract, if within the scope of authority, whereas an employee may not unless given express authorization. (See law of agency, principal) > > The make an aggregate work. However, this aggregate work is not the > > work which is made when Kaffe is modified. > > Debian distributes a modified Kaffe and Eclipse together. Section 2 > of the GPL does not care whether the modifications made to Kaffe are > for making Eclipse work better or not. False. Section 2 specifically says "The source code for a work means the preferred form of the work for making modifications to it." No one believes that Eclipse is a part of the preferred form of the work for making modifications to Kaffe. > > There is an aggregate work which is also being distributed which includes > > both Kaffe and Eclipse, but the GPL allows that. > > They are not an aggregate work, they are a whole work. That's easy to assert. What you are unable to do is provide any meaningful explanation of why your assertion is correct. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote: > I do want my government and my cellphone to run on Free Software, > and neither will happen in my lifetime if there isn't a commercially > viable transition strategy. If you want to work towards a situation where everything is available under a compatible license, consider a project oriented approach: pick a license and put together a project where everything distributed by that project is available under that license or under compatible terms. There are a number of ramifications to this, but I'm not sure if you're interested enough to spend time on them. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote: > If the public benefit of interoperability outweighs the harm done to a > copyright holder by permitting competitive use of the interface they > created, how can it not outweigh the harm to him of permitting > cooperative use? Why assume that interoperability is the only benefit from release under copyleft? For example, there's issues like "more eyes on the code", "easier to make derived works", and "enabling literacy". And then there's the whole area of increasing the market for some related product (for example: the hardware which runs the free code, or the training services to help people use the free code more effectively, or the consulting services to help businesses use the free code to improve their processes, or ...). For that matter, what makes you think that competitive use of the interface is being disallowed? Near as I can tell, the only thing being disallowed is use of the implementation and that's only being disallowed in circumstances where the competing use won't comply with the copyright on that implementation. > You can argue that there's a completely different kind of public benefit > that would result from giving free software a special status, but you're > going to find limited legal precedent for that view. Why bring in "a special status" as an issue? Free software exists under current copyright law. > In any case, the argument from free speech principles > doesn't reduce the applicability of these precedents with regard to > the copyright holder's economic interests. Sure, just keep in mind that free software copyright holders also have valid economic interests. > > I strongly disagree. No one is arguing that you should not be able to > > develop a proprietary program with equivalent functionality to a GPLed > > program. The issue concerns the ability to build upon the actual GPLed > > program in order to provide that functionality. > > So Sony should have attacked Connectix, not for emulating the > PlayStation's interface in order to compete with it, but for building > on customers' access to Sony-authored games to make their emulator > useful? The PlayStation is GPLed? Connectix is GPLed? Connectix used Sony's copyrighted code (what was on the other side of the interface)? Unless the answers to one of these questions is yes, you're talking about irrelevancies. > Or perhaps Sega should have fought Accolade, not for > copyright infringement in the course of reverse engineering to create > games for the Sega console, but for interfering with Sega's ability to > engage in social engineering within the Sega-game-author community? Irrelevant, again. > Fortunately for us all, engineering reality tilts the playing field in > favor of componentization; where there are interchangeable components, > there are opportunities to find new uses for those components, some of > which may compete with their originators' interests; and courts > properly frown on the abuse of the copyright monopoly to block this > competition. There's a legal device designed to control the terms, > not merely of copying, but of use; it's called a patent, and (in > theory) requires a much greater showing of originality. You present a convincing case that contributory infringement is likely to be limited in scope. But that's not the same thing as distributing copies of the code behind the interface. > ... > > I am, in fact, opposed to the idea that unlimited reach for copyleft > is desirable. I don't really care whether the software inside my > microwave oven is Free. I do want my government and my cellphone to > run on Free Software, and neither will happen in my lifetime if there > isn't a commercially viable transition strategy. Don't expect the license to be changed to make it easier for past problems to resurface. > Last I checked, some people were arguing against the legitimacy of > running Eclipse on Kaffe because this alternate implementation of the > JVM interface happens to expose the inconsistency of the "linking > creates a derivative work" stance. What, this would be a smaller > problem if the first JVM implementation were GPL'd? As it happens, that's not the case, and probably would never have been the case. On the other hand, it would be plausible to have released the first JVM under LGPL. > > Use of words like "abuse" and "tricksy" to describe copyleft sound about > > as convincing as those who attempt to label the GPL "viral". > > Courts and respectable commentators do use phrases like "abuse (or > misuse) of copyright monopoly" to describe the conduct of plaintiffs > who knowingly push the limits of copyright protection for > anti-competitive purposes. Hint: Google for "abuse copyright > monopoly Lexmark". This is not at all the same thing as the GPL. In Lexmark, the "copyrighted" material in question served the role of a key in a lock, and was not a work of art or science in any other respect.
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > In other words: derivative works include "mere aggregation". On Wed, Jan 26, 2005 at 11:57:29PM -0500, Michael Poole wrote: > As a point of law, derivative works are not a superset of "mere > aggregation" in the US, and I suspect not in other jursidictions. 17 > USC 101 requires that a derivative work be "recast, transformed, or > adapted" from the original; the GPL's "mere aggregation" would be some > subset of compilations, possibly the same subset as collective works. Since the GPL explicitly doesn't put any restrictions on "mere aggregation", I don't think this is a very important issue. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Wed, Jan 26, 2005 at 09:53:03PM -0500, Walter Landry wrote: > The GPL puts restrictions on whole works. True. > "Requires to run" is a useful heuristic to determine what a whole > work is. Kaffe does not require Eclipse to run. So by this heuristic, Eclipse is not a part of Kaffe. > If you have a better heuristic, I am open to discussion. "Requires to build". "Incorporates content from". "Designed as part of". > But I have only seen people talk about derivative works, and the GPL > clearly goes beyond just derived works. [1] I don't think this phrase "derivative works" means what you think it means. [2] Whether or not Eclipse + Kaffe is a derivative work of Kaffe is not the issue, in my opinion. In other words: derivative works include "mere aggregation". -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > Section 2 is about the restrictions which come into play when you > > build a modified form of Kaffe, which is not the case for Eclipse. > > Eclipse involves no modifications of Kaffe. On Wed, Jan 26, 2005 at 09:50:17PM -0500, Walter Landry wrote: > Debian modifies Kaffe and distributes Eclipse with it. If Debian did > not modify Kaffe, then this section would not be relevant. First: There is no such legal entity as "Debian" which is doing such things. "Debian" is a trademark of SPI, and there are people who use that trademark, but that's not the same thing. Second, when a volunteer who associates with the name "Debian" modifies Kaffe, he or she does not modify it to include Eclipse. So the distribution of Kaffe proceeds unhindered. Third, when a volunteer who associates with the name "Debian" distributes Eclipse, this is under the terms of the Eclipse license, and this does not in any way violate the Kaffe license. Of course, if someone modified Kaffe to incorporte Eclipse, that would be a problem. To my knowledge, no one has done so, no one plans to do so, and no one is seriously presenting this as an issue. In other words: even if your sentence were legally accurate (which it isn't, given the legal status of Debian), it would still be irrelevant. > > Once again, the only relations between Eclipse and Kaffe are "Eclipse > > is aggregated with Kaffe" and "Eclipse is run by Kaffe". > > And once again, you miss the point that Eclipse and Kaffe together > make a whole work. The make an aggregate work. However, this aggregate work is not the work which is made when Kaffe is modified. > > In particular, you can't impost restrictions from Section 2 on cases > > where Sections 0 and 1 have already granted permissions. Not unless you > > want to make distribution under the GPL void (see Section 4 for why that > > is a requirement). > > Section 0 says that this license only affects copying and distribution, > which is what is going on here. Section 0, when taken by itself (as you're doing here), only requires the inclusion of appropriate copyright notices. So we're satisfying that aspect of section 0. > Section 1 gives permissions for distributing unmodified versions. Yes. > I am talking about distributing modified versions of Kaffe (which > Debian does). And we're satisfying the conditions required for the distribution of those modified versions. Those modified versions of Kaffe do not include Eclipse. There is an aggregate work which is also being distributed which includes both Kaffe and Eclipse, but the GPL allows that. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 03:09:58PM -0800, Michael K. Edwards wrote: > Great. Except either this interpretation isn't part of the contract, > and therefore doesn't bind other contributors, or else I've created > another little almost-GPL fiefdom, and any bit of code that turns out > to have been copied from another project with a non-matching GPL > exemption gives the copyright holder leverage to sue me with the FSF's > help. This is clearly well intentioned, but it's no substitute for a > solid legal precedent or a change of heart from the FSF. You can't please everyone all of the time. Alternatively: I don't understand your agenda. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
> On Wed, 26 Jan 2005 09:38:19 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > Because "all public interfaces" is too general a concept. On Wed, Jan 26, 2005 at 03:03:57PM -0800, Michael K. Edwards wrote: > Too general for what? That is indeed a good question. Once we settle what it is that we're talking about, let's come back to it. > > > Doesn't the chain of reasoning, from Computer Associates to > > > Lotus to Lexmark, apply just as well to any other published interface? ... > > When I see MS Word or Powerpoint being distributed for free, because > > they constitute functional implementations of publc interfaces, I'll > > agree with you. > > I never said, and don't mean, that the implementation internals are > not copyrightable. You did, however, say that the GPL would not hold in such a circumstance, with the implication that this was because something was not copyrightable. > So let's lay this poor straw man to rest, OK? If by this poor straw man, you mean the chain of reasoning that says that interfaces may be reimplemented, sure. > > Of course, there are cases where A+B is a collective work, or a part > > of a collective work, and the GPL's terms allow its distribution. > > But equally obvious, that's something the GPL specifically allows, and > > it doesn't provide a basis for generalizing this permission to other > > cases which the GPL disallows. > > What "case which the GPL disallows" are you talking about? What > relationship between A and B, other than sharing copyrightable > material, is discussed in the text of the GPL? Let's take A: the objective C front end, and B: gcc. Or, let's take the MagpieRSS and some commercial effort build on it. Or, let's take ghostscript, and some commercial effort built on it. [This last one is interesting, because it's also available under a different license -- and, in fact, the alternately licensed commercial version gets more immediate support than the GPL'd version.] > > > It is of course possible that a court won't go so far as to rule that > > > a given published interface isn't copyrightable. But supposing that > > > this generalization does hold, what grounds do you find in the GPL for > > > retaliating against the commercial application vendor by denying it or > > > its customers license to the library? > > > > It seems to me that you'd be engaged in activities where you need the > > permissions described in the first sentence of section 2, but that you > > would not be satisfying the associated conditions. > > What activities? Building and distributing modified versions of the GPLed program. > > And I don't see the GPL denying its customers license. I do see grounds > > to have the commercial vendor cease and desist from distributing the > > library (whatever "distributing the library" means in that context). > > What grounds? Not satisfying the GPL requirement that people who distribute modified copies of the program, in binary form, make available the source code for the work under appropriate terms. > > In the C universe, no such guarantee applies to system header files -- > > they're system specific. > > What do these statements have to do with the question of which bit is > the public interface? They have to do with the nature of those of those interfaces -- in particular, they have to do with the distinction between the "Program" and a "work based on the Program". > > You also appear to think that where a GPLed work has functional > > components, the license protecting the rest of the work no longer engages > > when it the work is incorporated in a program which only modifies the > > functional components. > > No, I don't think that. I think that the PEOTL and the library remain > separate works for copyright purposes because the only text that they > share is uncopyrightable. I think that they include functional elements, but I don't think that the text is uncopyrightable. Only the functional elements are uncopyrightable. On the flip side, re-engineering those functional elements and then distributing the combined work (which includes the GPLed implementation) might very well be seen by the court as an attempt to sneak around the terms of the license. Or not... what a court will decide, and why, can be hard to predict -- especially in the general case. > > > OK, "unique" was an overstatement. But the FSF has an axe to grind > > > that discomfits many decent people who would otherwise be willing to > > > share in the maintenance and expansion of the commo
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 09:38:19AM -0500, Raul Miller wrote: > > But we don't really want to set up a copyright assignment regime, so > > the FSF's insistence on waving the preliminary injunction club at > > unwary linkers is a red flag. Let's consider a release of libFoo under terms guided by your interpretation of the GPL and cases like lexmark and lotus v. borland: We are releasing libFoo under the GPL, but hold the interface and header files to be public domain. In GPL terms, the implementation -- the *.c files, and files built from those .c files at compile time -- are the Program, and must be distributed only under the terms of the GPL while the headers -- *.h files and build scripts -- may be incoroprated in anyone's program without copyright being an issue. In GPL terms, linking your program with libFoo is mere aggregation, and using your program in conjunction with libFoo constitutes running libFoo as a program. The GPL requirements for source code release when you modify libFoo only apply to the implementation itself -- not to programs which happen to use libFoo. As near as I can tell, this kind of release notice would satisfy the concerns your company has about the GPL. If that's not the case, I think you need to better understand the nature of your company's concerns. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 09:38:19AM -0500, Raul Miller wrote: > If I understand you correctly, you could address all your company's > concerns by licensing the headers and build files needed to compile your > libraries under BSD (or maybe LGPL) and license the rest of your content > under GPL. > > Or is there some other concern? Or, better yet, include a statement of intent -- a description of what is meant to be protected and what is not. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
> On Tue, 25 Jan 2005 21:49:00 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > [snip] > > The cited cases were cases where copyright was held to not exist on the > > materials in question because they were functional materials instead of > > copyrightable materials. > > > > For cases where the interface definition is not protected by copyright, > > I'd agree with you. However, I doubt that this could be generalized to > > "all public interfaces". On Wed, Jan 26, 2005 at 05:34:00AM -0800, Michael K. Edwards wrote: > Why not? Because "all public interfaces" is too general a concept. > Doesn't the chain of reasoning, from Computer Associates to > Lotus to Lexmark, apply just as well to any other published interface? > It's not that these plaintiffs weren't trying to copyright their > interfaces, it's that the courts ruled that the necessity of > duplicating them in order to interoperate warrants their exclusion > from the portion of the work that is considered copyrightable > expression. When I see MS Word or Powerpoint being distributed for free, because they constitute functional implementations of publc interfaces, I'll agree with you. > > Where the library itself is copyrighted under the same copyright as the > > interface, you have a different situation, with respect to copyright. > > It's not just the interface which is being copied, but the entire library. > > To copy the entire library, you of course need license to do so. The > GPL spells out the terms of that license. The GPL proclaims that the > scope of the material for which license is needed is determined by > copyright law. Copyright law, as interpreted by courts, appears to > deny monopoly protection to published interfaces when they must be > used in order to interoperate successfully, even when that > interoperation is against their creator's interests. Ergo, the use by > a commercial application of the published interface of a GPL library > does not infringe copyright, does not trigger rescission of rights > under the GPL, and does not justify restrictions on the distribution > or use of the application together with the GPL library. The GPL coverse both derivative and collective works. I don't think that a claim that <> is sufficient in all cases. Of course, there are cases where A+B is a collective work, or a part of a collective work, and the GPL's terms allow its distribution. But equally obvious, that's something the GPL specifically allows, and it doesn't provide a basis for generalizing this permission to other cases which the GPL disallows. > It is of course possible that a court won't go so far as to rule that > a given published interface isn't copyrightable. But supposing that > this generalization does hold, what grounds do you find in the GPL for > retaliating against the commercial application vendor by denying it or > its customers license to the library? It seems to me that you'd be engaged in activities where you need the permissions described in the first sentence of section 2, but that you would not be satisfying the associated conditions. And I don't see the GPL denying its customers license. I do see grounds to have the commercial vendor cease and desist from distributing the library (whatever "distributing the library" means in that context). > > [a] The libraries are freely redistributable to everyone, with no > > restrictions whatsoever, or > > > > [b] The libraries are very heavily restricted with extremely high costs > > associated with each copy. > > > > The GPL doesn't precisely fit into either of those categories, and I > > don't see any reason why either form of industry practice should take > > precedence. > > I referenced "industry practice" to suggest a likely source of > consensus about what constitutes an interface definition in any given > technical context (header files for C libraries, interface definitions > extractable from class files for Java, etc.). Note that these are very different cases. The interface definitions from class files for the system libraries for Java are (if copyright applies) owned by Sun, and distributed under their license. Authors of GPL'd java systems can't claim ownership of that specific content. In the C universe, no such guarantee applies to system header files -- they're system specific. > > If the courts hold that all libraries are purely functional, despite > > their licensing terms, that could indeed be seen to satisfy a valid > > public policy goal. I don't think that's going to happen, however. > > Hopefully it is clear by now that I think th
Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 01:14:05AM -0800, Michael K. Edwards wrote: > But just as Lotus customers had already invested in learning menus and > creating macros, and Sony PlayStation users had already invested in > game titles, many MySQL users (for instance) have invested in > developing MySQL-bound applications and the knowledge required to use > MySQL well. Had the Progress Software v. MySQL litigation proceeded > far enough, I think it is no stretch to argue that MySQL's attempt to > use the copyright monopoly to obstruct Progress's efforts to reach > their customers would and should have foundered on the rocks of > precedent and equity. And many more users have invested invested in learning how to use windows and microsoft office. But that's largely irrelevant to the case you're citing here. At least, the way I read it, the progress softare v. mysql case didn't get a preliminary injunction because the two parties had largely settled their differences by the time the case had arrived in court. > My impression is that the same court system that discourages direct > abuse of copyright monopoly frowns on tricksy indirect mechanisms as > well. Although I don't have precedents handy, I would expect that > rules that clauses forbidding competitive interoperation in licenses > are unenforceable, especially in a "standard form" contract with > little or no opportunity to assess the consequences and negotiate. I can see that this could limit the scope of contributory infringement. I think it's unlikely that this could limit the scope of direct infringement. > This is true, but doesn't explain the dearth of "unauthorized use of a > published API" cases. It's probably worth noting that there aren't many "unauthorized use of an unpublished API" cases, either. This is despite anti-reverse engineering clauses in the licences. Of course, those cases which do exist tend not to involve distributing copies of the licensed materials behind the API. Also, the DMCA has somewhat changed the focus of these kinds of court actions. > Yet even > when both parties are plenty sophisticated and the contract is fully > negotiated and executed, courts take their own tack on license > interpretation (see the Sun v. Microsoft saga for examples); and when > the evidence of "meeting of the minds" is rather weak, ancillary > As for the DirectX example, when was the last time Microsoft resorted > to mere lawsuits to obtain compliance with its strategic imperatives? > Those clauses get the message across: accept lock-in or we will > destroy you. Do you really approve of similar tactics in the name of > software freedom? That's not really the question for us, here. As a general rule, we try to not have an adversarial relationship with software authors, if they're upstream of us. It's just not worth it. If someone asks us to not distribute software, even if we're technically licensed to distribute it and even if it seems the license is DFSG compatible, we're likely (though not guaranteed) to stop distributing it. We don't always have working relationships of this quality with authors of works we don't distribute, but that's probably less important. And, for the most part, we don't try to exert control over what other distributors do. We make our choices, not their choices. [objective c and gcc] > Note also the absence of actual legal proceedings. I noted that when I introduced the issue. > It is also worth noting that the GCC front end / back end interface > is somewhat fluid, unusually complex, and not intended for arm's length use. Yeah, I think intent matters, too. > And irrespective of legalities, there are few factual settings in which > proceeding in the face of hostility from the maintainers of the > interlocked component would be greater folly than in the case of an > optimizing compiler. I can think of many other examples. Software tends to get rather complex, rather quickly. In any event, NeXT shippd the specific gcc version they needed, so version drift wasn't a practical concern at the time. > Similar conclusion, mostly different logic. Sega v. Accolade ruled > that the reverse engineering process was permitted as "fair use" > although the activities it entailed would otherwise have constituted > infringement. Yeah, if you buy a book you're allowed to read it, too. In general, once you have legally obtained a copy of a program you're allowed to use it, [In other words: I have no disagreement with your reasoning, here.] > To the extent that Sega also applies a theory of uncopyrightability of > purely functional elements to legitimize copying of the Genesis > "unlock code", it cites Computer Associates v. Altai as authority for > doing so. But none of these cases involve copying of the original and copyrighted material which came with that purely functional content. You keep ignoring this issue, which is why I keep bringing it up. > > Among others, the millions of Free Software users who benefit
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Tue, Jan 25, 2005 at 10:49:42PM -0500, Walter Landry wrote: > When one work requires the other in order to function, then you have > gotten past mere aggregation. So Emacs is not required for Kaffe to > work, or vice versa. Putting them on the same medium is mere > aggregation. "Requires to run" is a debian packaging concept, and is not a restriction which is expressed in the GPL. Instead, the GPL says: The act of running the Program is not restricted and You may not impose any further restrictions on the recipients' exercise of the rights granted herein. If you sincerely think otherwise, please cite the relevant section of the GPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > > Michael Poole <[EMAIL PROTECTED]> wrote: > > > > Eclipse is, similarly, not a derivative of Kaffe and by itself is > > > > not subject to the GPL. > > On Sat, Jan 22, 2005 at 11:07:37PM -0500, Walter Landry wrote: > > > The key word is "by itself". There is no problem with Eclipse being > > > distributed alone. The problem is when it is distributed with Kaffe. > > > Kaffe's license cares about the company it keeps. > Raul Miller <[EMAIL PROTECTED]> wrote: > > I see no such problem. > > > > Since you claim to, please cite the specific, relevant language from > > the GPL that "cares about the company it keeps". And, indicate why > > those parts of the GPL are significant to the combination of Eclipse > > + Kaffe. [To me, "the company it keeps" sounds like the same topic as > > "mere aggregation".] On Tue, Jan 25, 2005 at 08:54:50PM -0500, Walter Landry wrote: > I have already noted that the paragraph after Section 2c is where this > occurs. It is even clarified in the next paragraph > > the intent is to exercise the right to control the distribution of > derivative or collective works based on the Program. > > Note the use of the word "collective". Sure -- this phrase is necessary because in some cases building a program creates a derivative work under copyright law and in other cases building a program creates a collective work. But you can't take that phrase in isolation -- you have to look at when Section 2 is significant. Section 2 is about the restrictions which come into play when you build a modified form of Kaffe, which is not the case for Eclipse. Eclipse involves no modifications of Kaffe. Once again, the only relations between Eclipse and Kaffe are "Eclipse is aggregated with Kaffe" and "Eclipse is run by Kaffe". In particular, you can't impost restrictions from Section 2 on cases where Sections 0 and 1 have already granted permissions. Not unless you want to make distribution under the GPL void (see Section 4 for why that is a requirement). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
> On Tue, 25 Jan 2005 19:11:27 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > [snip] > > You think the "bright line" which has yet to be drawn is not far from > > the theory articulated in lotus an lexmark? That's... a fairly murky > > way of thinking... On Tue, Jan 25, 2005 at 05:33:39PM -0800, Michael K. Edwards wrote: > I think that a "bright line" could be drawn substantially at the > boundary between public interface and implementation internals, as the > cited cases did in the case of menus and macro languages (Lotus) and > pluggable hardware components (Lexmark). That's a functional issue. The cited cases were cases where copyright was held to not exist on the materials in question because they were functional materials instead of copyrightable materials. For cases where the interface definition is not protected by copyright, I'd agree with you. However, I doubt that this could be generalized to "all public interfaces". > The definition of "interface" is going to vary from language to > language, but that's what expert witnesses are for. In many cases, > industry practice is so well understood that there isn't much room > for those expert witnesses to disagree anyway. In lotus, the functional aspects of the interface were copied, but nothing else was. In lexmark, the same thing holds. Where the library itself is copyrighted under the same copyright as the interface, you have a different situation, with respect to copyright. It's not just the interface which is being copied, but the entire library. As an aside, "industry standard practice" as far as libraries go tends to fall into one of two categories: [a] The libraries are freely redistributable to everyone, with no restrictions whatsoever, or [b] The libraries are very heavily restricted with extremely high costs associated with each copy. The GPL doesn't precisely fit into either of those categories, and I don't see any reason why either form of industry practice should take precedence. > Encouraging competitive interoperation is a valid public policy goal, > pursued fairly consistently by the courts in the case law that I've > read. If the courts hold that all libraries are purely functional, despite their licensing terms, that could indeed be seen to satisfy a valid public policy goal. I don't think that's going to happen, however. > Of the theories that have been applied to disallow the use of > the copyright monopoly to block interoperation, I think situating > published interfaces firmly in the realm of the > functional-and-therefore-uncopyrightable is easiest to apply > consistently and operates at the right stage of analysis. And I think that for cases where that's all that's being copied, that it's likely that the courts would agree with you. However, I don't think that you can argue that this is a relevant precedent when the entire library is being copied. > What's murky about this way of thinking? The implications. And, thus, the semantics. > > > There doesn't seem to be much case law in which a court has been asked > > > to apply sanctions against "unauthorized use of a published API" under > > > a copyright theory. > > > > Right, because people generally pay attention to the license on the > > components they'll be building on and don't bother to make an investment > > in any area where they're likely to have problems. > > There's some truth to this; but I think it's a bigger factor that most > software component business models fall squarely into either the > unpublished camp (with access only granted by negotiated contract) or > the no-fee-to-redistribute camp (with revenues based on toolchain > sales, technical support, and sometimes end-user purchase of hardware > and/or software platforms). Or the high-end-but-published camp. What Joel Spolsky calls the "Dear" price range. http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html > Both models provide more practical ways > of pursuing freeloaders than prosecution for copyright infringement. > The GPL, as interpreted by the FSF, is unique in going after > commercial users' intellectual property rather than their cash. It's unique in its price range, but it's hardly unique in its terms. Have you ever looked at some of the older AT&T Unix source licenses? > > In this context, the handling of objective c and gcc is probably relevant. > > Could you expand on this comment? Is there any history of legal > activity or discussion there? There's a paragraph at http://www.free-soft.org/literature/papers/gnu/pragmatic.html which mentions this issue. The NeXT is
Re: Illustrating JVM bindings
> > "Written to use the library", in the simple case, with no trickery > > involved, means that you are incorporating a modified form of some of > > the copyrighted code of that library. In the typical case, this would > > be anything covered by copyright that has to be included when compiling > > the combined work. On Tue, Jan 25, 2005 at 03:41:28PM -0800, Michael K. Edwards wrote: > The scope of copyright in external interfaces is the crux of the legal > debate. I don't mean to claim that the "bright line" has yet been > firmly drawn, identifying published interface definitions as > intrinsically uncopyrightable portions of software works. I do think > that's pretty close to industry practice, and not far from the theory > articulated in Lotus and Lexmark. You think the "bright line" which has yet to be drawn is not far from the theory articulated in lotus an lexmark? That's... a fairly murky way of thinking... > There doesn't seem to be much case law in which a court has been asked > to apply sanctions against "unauthorized use of a published API" under > a copyright theory. Right, because people generally pay attention to the license on the components they'll be building on and don't bother to make an investment in any area where they're likely to have problems. In this context, the handling of objective c and gcc is probably relevant. > The various cases I have cited are mostly competitive situations > (creation of interoperable substitutes), and older precedents on > interface usage from the telecom industry usually hinge on contract > terms and trade secret status rather than on copyrightability. Agreed. > Personally, I think that the FSF is swimming upriver when it claims > that any of the steps involved in implementing and linking against a > library creates a derivative work. You're swimming up the same river when you claim that a binary is a derivative work of the source. > As far as I can see, this attitude goes against the legal trend in > the US and in any other jurisdiction which looks to the US judiciary > for reasoned analysis of the public policy issues. For contexts where the treatment of copyrighted material is an obstruction to hardware compatability, sure. > Moreover, together with the FSF's bizarre insistence on a "non-contract > license" interpretation of the legal basis for the GPL, it discourages > established software players from publishing mature software components > under the GPL, since they fear that allowing a patch from a competitor > to leak into the GPL component will provide a lever with which to open > up their entire code base or to obtain crippling injunctions under > the generous copyright standard. The FSF apparently has some analogous fear. Last time I checked, they insisted that they be given copyright on code before they accept it into their code base. > Arguably, the barriers to adoption of GPL components in commercial > software projects are in the interest of programmers of limited skill > and experience, since the usual alternative is in-house Greenspunning, > which seems to be most of what novice programmers are employed to do. > They might also be in the interest of the egos of the maintainers of > some GPL components which would be overdue for a rewrite if > mission-critical projects depended on them. Everyone else loses out. Everone else, with a few million exceptions, sure. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote:
> I'm focusing on a simple case. Pre-existing GPL library, shipped
> unaltered, or with any bug fixes and enhancements contributed
> upstream. New application ("PEOTL") written to use the library.
> Tested and shipped together, with no tricksy business to pretend that
> the application isn't dependent in an engineering sense on the
> library. Intent: to exploit the market for the application, and to
> save on engineering cost by not reinventing the wheel contained in the
> library.
"Written to use the library", in the simple case, with no trickery
involved, means that you are incorporating a modified form of some of
the copyrighted code of that library. In the typical case, this would
be anything covered by copyright that has to be included when compiling
the combined work.
> Simple legal question: can a GPL library author use the copyright
> monopoly to ban the vendor from writing, or the end user from running,
> a closed-source application that uses the library through its
> published interface?
Simplisticly, that depends on on the nature of the published interface.
> Equally simple ethical question: does releasing
> code under the GPL create a commons or a commune?
That depends on perspective, and intent.
> Can one choose to share of and share in a pool of competent solutions
> to well-understood programming problems, without abandoning conventional
> mechanisms for recouping capital investment in novel creations?
In the general case, yes.
In specific cases, there might be specific details that make the
consequences of such choices easier or harder to deal with than in other
specific cases.
In particular, you can't incorporate copyrighted concrete expressions of
those solutions without paying the price set by the copyright holder.
That is, after all, the conventional mechanism for recouping capital
investment in novel creations.
> > I think this falls under fair use. The program in the printer cartridge
> > was tiny, and if Lexmark really wanted copyright protection on that
> > program, they shot themselves in the foot by making its checksum a
> > functional issue.
>
> The interesting part of the ruling, to me, was that the court didn't
> use a "fair use" theory to reach the conclusion they did. The problem
> with "fair use" is precisely that it depends on the circumstances and
> intention of the use; it's an affirmative defense of the behavior, not
> a property of the material being used. So it's pretty easy for a
> copyright holder to get a fresh hearing in court based on a new
> incident of use of the same material.
Ok, ignore the first sentence of that paragraph then.
> The Lexmark court, like the Lotus court, ruled instead that, when
> prima facie copyrightable material is actually necessary for
> functional interoperability, it loses eligibility for copyright
> protection. If this precedent holds, we can stop counting the angels
> dancing atop an exec() boundary.
I don't think this generalization can be made to apply when the only
thing that the copyrightable material is necessary for interoperability
with is the copyrightable material in question.
> GPL. Correctly or not, I understood you to have said that having
> studied a GPL library's internals weakens one's case for being
> justified in writing a non-GPL application that uses it. Copyright
> doesn't and shouldn't work that way. I feel strongly that the ideas
Ah, reading back, I think I see the problem.
I wrote:
< < < < The GPL intentionally removes the freedom to collaborators
< < < < freedoms on collaborative works.
I meant to write something like:
The GPL intentionally removes the freedom to remove collaborators'
rights to access and use collaborative works.
In other words, it's designed to avoid people claiming full ownership and
control over a body of work which they had only partial responsibility
for creating.
That is the kind of freedom the GPL removes, and I don't see that as a
bad thing.
But I think you're talking about the same thing from a different point
of view. You're talking about someone's control over the part they
did write. The GPL doesn't remove their freedom to control that part,
by itself.
--
Raul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> Michael Poole <[EMAIL PROTECTED]> wrote: > > Eclipse is, similarly, not a derivative of Kaffe and by itself is > > not subject to the GPL. On Sat, Jan 22, 2005 at 11:07:37PM -0500, Walter Landry wrote: > The key word is "by itself". There is no problem with Eclipse being > distributed alone. The problem is when it is distributed with Kaffe. > Kaffe's license cares about the company it keeps. I see no such problem. Since you claim to, please cite the specific, relevant language from the GPL that "cares about the company it keeps". And, indicate why those parts of the GPL are significant to the combination of Eclipse + Kaffe. [To me, "the company it keeps" sounds like the same topic as "mere aggregation".] For example, in another context, "the company it keeps" might refer to the part of section 3 which states that the "complete source code" for a modified version of Kaffe means "all modules it contains, plus any associated interface definition files, plus scripts used to control compilation and installation of the executable." But clearly, Eclipse doesn't fit in any of these categories. You might try to argue that Eclipse + Kaffe is not "mere aggregation", but I see nothing in the GPL to support that contention. I do see specific language in the GPL which implies that Eclipse+Kaffe is nothing more than aggregation: "The act of running the Program is not restricted". To my knowledge, the only relationships between Eclipse and Kaffe are that Kaffe runs Eclipse, and that we would be packaging them together, in a fashion which would enable this runtime relationship. But neither of those things are restricted. If you are arguing that Eclipse + Kaffe is not merely aggregation, please describe the relationship, in specific terms, and indicate the section(s) of the GPL where this matters. The way I read the GPL: [*] Kaffe running Eclipse is not restricted. [*] Packaging Kaffe with Eclipse is not restricted. [*] Imposing any such restriction violates the GPL. This characterization would become incorrect if Kaffe were modified in some fashion that made Eclipse a part of Kaffe, but no one seems to believe that that's the case. I might be wrong, but if so I would really appreciate it if someone would spell out the specific clauses of the GPL which I'm overlooking. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Sat, Jan 22, 2005 at 04:15:58PM +0100, Måns Rullgård wrote: > The interpreted program interacts (I don't think "communicate" is the > appropriate word) with the virtual machine (in a loose sense of the > word) presented by the interpreter. It does not communicate with the > actual implementation. A regular program interacts with the > registers, memory and so on found in the machine, not with the > individual gates, electrons and whatnot that make up the actual > hardware. It's kind of interesting to consider what you might mean by "It does not communicate with the actual implementation". One way of looking at this is that programs never communicate -- they just control various pieces of hardware which do the actual communication with each other. Another way of looking at this is that the interpreted program and the interpreter do so much more than communicate, that there ought to be some better word to describe what's happening. There might be other ways of looking at this -- I don't really know what your concept is. > > I'd say it this way: Interpreters generally do not communicate with > > interpreted programs in a fashion which matters for the GPL license on > > the interpreter. > > Say it any way you prefer, as long as we can agree on the > consequences. Good enough. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is phpGrabComics legal?
On Sat, Jan 22, 2005 at 01:50:58PM +, Andres Baravalle wrote: > I suppose that it would mean excluding *all* the syndicated comics > (dilbert, calvin and hobbes etc.). They cover 2/3 of the comics. > They will not give me an explicit permission, but I'd like to know if > I'm doing anything wrong from a legal point of view. If you've asked some of the copyright holders if you're doing anything wrong, I think you can rely on them telling you if you are. Lack of answer isn't any kind of blanket permission, but would show due dilligence (if the matter came up, later, and if you can prove that you asked). On the other hand, if anyone flames you, and they hold copyright on any web comic, it would probably be a good idea to make it trivial for your users to not view those comics. As in: make this the default behavior of your system. And, while it will be possible for the users to reconfigure (or even rewrite) your code, if you leave a reference to the flames where someone undertaking that kind of change is likely to see it, they'll be able to make an informed choice about the issue (which puts a significant element of responsibility on their shoulders). On a more positive note, stuff posted on the web is intended to be viewed by a wide number of people, which means that copies can be made. And it's already been established in court (for VCRs) that it's legal to use recording equipment to allow people to view copyrighted material at a time convenient for them. I believe that as long as you're acting fairly that you'll not wind up in any trouble. Good luck, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Sat, Jan 22, 2005 at 09:58:00AM +0100, Måns Rullgård wrote: > Interpreters are a different issue from the exec() situation. The > program being interpreted generally does not communicate with the > interpreter at all. If the interpreted program and the interpreter can't communicate, then usually nothing works. Variable values are unknown, control flow never happens, and so on. I'd say it this way: Interpreters generally do not communicate with interpreted programs in a fashion which matters for the GPL license on the interpreter. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Thu, Jan 20, 2005 at 08:51:46PM -0800, Michael K. Edwards wrote: > We seem to be talking past one another. Maybe it's just that I'm > implicitly assuming a separation between "library source code" and > "program source code", and saying that the latter is only a derivative > work of the former if it contains copyrightable material, which API > calls are not. I don't think either of us means to get into a > semantic debate about whether the phrase "program source code" ought > to refer to the whole ball of wax. So I'll use "program exclusive of > the library", or PEOTL, instead. Except I'm holding that this kind of distinction is meaningless in the general case. To meaningfully dicuss this kind of things, you'll have to nail down other details. Intent matters, other activities matter, etc. For example, consider a case where I hire person A to write a propietary compiler. I run low on funds, so I hire person B to make a "gcc library", then person C to upgrade that library to include some API features I want, then person D to merge the work of person A and person C. I then hire person E to publish the result. Just for fun, let's say that all this hiring happens in some random countries which haven't signed any of the copyright treaties. Also note that I've not bothered to specify who holds the copyrights on the works I contracted for -- all that matters is that these people don't hold copyright on the original gcc. > Am I correct in reading this as agreement that the PEOTL is not a > derivative work of the library? In the general case, no, I'm not agreeing. However, I do recognize that there can be specific cases where your generalization holds. > > And, the same thing goes for the code which uses the library -- if you > > need to distribute it, or modified forms of it, you still need to comply > > with the terms of its license. > > Let's assume that I wrote the PEOTL and intend to distribute it under > the following license: "You have the copyright holder's permission to > use, copy, modify, and distributed modified copies of this code, in > source code or binary form, and to relicense the result to others > under terms of your choice, as long as everyone pets a cat." This is > GPL-incompatible in the sense that a derivative work of both GPL and > "pet-a-cat" code is undistributable. I think a court would treat this as frivolous. > > For example, if the precedent of lotus v. bourland were relevant in a > > context where you were distributing the library as a whole, that would > > be tantamount to saying that the library as a whole was not copyrightable > > because it was purely functional in nature. While that would be a rather > > interesting and perhaps exciting development for computer software > > professionals, I don't believe that's a likely ruling in a copyright > > infringement case. > > That's actually very nearly the substance of the Lexmark ruling, given > the additional fact that an SHA-1 checksum of the program in the > printer cartridge was used by the printer as a "lock-out code" to > reject non-Lexmark cartridges. Lexmark was trying to use the > copyright monopoly to criminalize the creation of interoperable > cartridges; instead, the appeals court ruled that they gave their > entire program a functional aspect and rendered it uncopyrightable. I think this falls under fair use. The program in the printer cartridge was tiny, and if Lexmark really wanted copyright protection on that program, they shot themselves in the foot by making its checksum a functional issue. But this doesn't generalize to all libraries in all circumstances. It doesn't even generalize to all firmware (though I do see it as weakening software protection on firmware). > That's not where I was going, though; I was saying that the PEOTL > doesn't infringe the library's copyright. But the PEOTL+library > combination, like any collection of things containing the library, > does constitute "copying" in the legal sense. If I don't have a > license to copy the library, or if I had one and it was rescinded, > then I'm infringing its copyright. So far so good? No, not in the general case. > > > > Since the GPL restricts distribution of itself at violation time, this > > > > idea of "function isn't copyrightable" isn't going to solve all the > > > > problems faced by someone violating the GPL. > > > > > > I don't understand this sentence. Perhaps you are trying to say that > > > for A to study a GPL library to understand how it works, and then > > > write non-plagiarized, non-GPL code that uses it correctly, causes A's > > > GPL rights to self-destruct, even if it is not true that under > > > copyright law the non-GPL code is a derivative work. That's not in > > > the GPL that I've read, and if it were -- this is freedom? > > > > That's hypothetical situation is rather narrowly focussed away from > > the typical cases I was trying to address. You don't seem to be asking > > me about what I mean
Re: Illustrating JVM bindings
> On Thu, 20 Jan 2005 11:53:37 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > [snip] > > I'd say this differently. The program is not a derivative work of > > the library if it was written without any of the relevant copyrighted > > material of that library. On Thu, Jan 20, 2005 at 04:26:18PM -0800, Michael K. Edwards wrote: > No, it's not a derivative work if it was written without _copying_ any > of the relevant copyrighted material _into_ the program source code. Didn't we just get done discussing that while technical details are informative they don't tell the entire story? While there are copyrighted programs which consist of only a single file, it's fairly typical for a program to be composed of many files. > It's OK to inspect the library source code, comprehend it, experiment > with it, work out what undocumented call sequence actually works > instead of something equally plausible but wrong, and generally to > write a program that wouldn't work without the library and couldn't > have been written without reference to its internals. You just can't > cut-and-paste, or even plagiarize in another language, expressive > content that could equally well have been written differently without > losing interoperability. There are different kinds of cases to consider here. If you're talking about being in compliance with the copyright on the library, and you're talking about a case where you don't need copyright privileges on the library itself, then you are essentially correct -- you're not violating its copyright by writing something that uses it. However, if you need copyright privileges for that library, that's a different story. If you need to provide copies of that library to other people, you still need to comply with its copyright. If you need to distribute modified copies of the library you need to make sure you're doing so under the terms of its license. And, the same thing goes for the code which uses the library -- if you need to distribute it, or modified forms of it, you still need to comply with the terms of its license. For example, if the precedent of lotus v. bourland were relevant in a context where you were distributing the library as a whole, that would be tantamount to saying that the library as a whole was not copyrightable because it was purely functional in nature. While that would be a rather interesting and perhaps exciting development for computer software professionals, I don't believe that's a likely ruling in a copyright infringement case. > > "A published functional interface" is a easily recongizable and legit > > way for a program to be written so that the program uses the library > > even though the program was written without using the library. Here, > > there's other material under a different copyright (the spec [obviously], > > but also the library headers and a library implementation). > > I think you and I are using "published" differently. You're assuming > that it's a standalone specification, probably with multiple > independent implementations, with fairly explicit permission to code > against it. I just mean "published" in a copyright sense, so that one > doesn't have to deal with trade secrets, "fair use" reverse > engineering, and "clean-room" standards. The notion of having to get > the job done without peeking at the internals just doesn't apply to > published source code. I think you're missing or ignoring the issues I'm trying to bring up. I rather intentionally did not go into the technical details of what distinguishes "published" and "not published". > > It's probably worth noting that Borland did this without using any > > lotus library (or headers, and probably without reference to any formal > > specification), and they certainly weren't being sued for using any such > > library inappropriately. > > Actually, they were being sued primarily because copying the menu > interface went along with copying the macro language, and both helped > users migrate from 1-2-3 to Quattro Pro. So they were being sued for > reimplementing a functional interface, part of whose function was very > much like a library API. I think I understand that. > > Since the GPL restricts distribution of itself at violation time, this > > idea of "function isn't copyrightable" isn't going to solve all the > > problems faced by someone violating the GPL. > > I don't understand this sentence. Perhaps you are trying to say that > for A to study a GPL library to understand how it works, and then > write non-plagiarized, non-GPL code that uses it
Re: Questions about legal theory behind (L)GPL
> On Thu, Jan 20, 2005 at 01:47:46PM -0500, Raul Miller wrote: > > Anyways, freedom is a very broad issue, but the freedoms Debian is > > concerned about are rather specific kinds of freedom (especially those > > that allow us to distribute debian on multiple platforms, and those that > > allow us to fix bugs and security problems). On Thu, Jan 20, 2005 at 02:08:54PM -0500, Glenn Maynard wrote: > ... and that allow users to make whatever modifications they want (even > those that have nothing to do with bugs or security), and to redistribute > those modifications without onerous restrictions. Sure, because in the general case, whether something is a bug or not depends on what people want. For that matter, whether or not someone is a part of Debian, or not, also depends on what people want. Most major corporations are a part of Debian, in some sense or another -- the free software community which Debian is a part of (and depends on) is extremely extensive. > Your "especially" is true in that it's what Debian needs to exist as > a Linux distribution (this applies to all distributions, regardless > of social contracts), but the SC places equal importance on guaranteeing > users freedoms beyond bugfixing--so I disagree with "especially". But there are some freedoms which Debian (or at least the Social Contract) doesn't express any particular views on. For example: the freedom to carry weapons. I'm thinking your objection is basically centered around the issue of "what is Debian" (or "what Debian isn't"). I agree that I was tacitly assuming that I was writing for people who knew what debian is (a volunteer free-software group which helps coordinate -- and relies heavily on -- support from people who are not explicitly members of the group). Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
On Thu, Jan 20, 2005 at 06:59:23PM +0100, Martin Hardie wrote: > It's nice to see some FSF doubters (I have just been reading this thread in > the archives) and questioning of their speech based copyright vision. I think > I agree with Micahel that precedent is fairly against the FSF and Lessig > views of the proper interpretation of copyright. You mean the mysql v progress precedent, where a judge apparently decided that the parties had mostly already settled and so there was no need for immediate action? Or do you mean the borland v lotus precedent where the only possible copyrighted material under consideration were the text (and arrangement) of menus? Anyways, from my point of view, the FSF would like to not have to worry about copyright at all. Every court decision weakening the ability of groups of people to use copyright to hoard software is in a very real sense something that the FSF is trying to achieve. Of course, copyright isn't going to go away, which is where licenses like the GPL have a part -- as a way of releasing something to the public, with fewer counterintuitive consequences than releasing it as Public Domain. [That said, copyright law is intricate enough that there are will probably always be some obscure issue which befuddles someone -- no matter which license or non-license is in use or is not in use.] > Its also nice to see some people talking about how TMs and other things might > restrict the "freeness" of open source. There has been too much junk said by > people that it purely a licence issue and everything else including US Export > Regulations dont interfere with the freedom of the licence! But I notice you using scare quotes. Anyways, freedom is a very broad issue, but the freedoms Debian is concerned about are rather specific kinds of freedom (especially those that allow us to distribute debian on multiple platforms, and those that allow us to fix bugs and security problems). > tradition and internal protocols. A system of trust operates within the > community of producers and users which is sufficently well known to bind > third parties not to use the material in a manner inconsistent with the > communities principles. The Social Contract, the DFSG and the GPL and many other such documents can be seen as concrete representations of some community principle -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 20, 2005 at 03:38:40AM -0800, Michael K. Edwards wrote: > The exec() boundary is bogus. The interpreter waffle is bogus. The > LGPL exemption is bogus. The syscall exemption is bogus. The > Classpath exception is bogus. The entire claim that linking creates a > derivative work is bogus. A published functional interface is a > published functional interface. I think you're overgeneralizing. The mechanical issues are informative but not definative. The license issues are applicable to specific circumstances (though I agree that they're not relevant to the bogus subject line of this thread). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Illustrating JVM bindings
On Thu, Jan 20, 2005 at 03:22:55AM -0800, Michael K. Edwards wrote: > When combining the two is a mechanical operation, the combination is > not separately copyrightable, and hence is not a derivative work. Unless [of course] they were already a derivative work, for some other reason. > Nor is the program a derivative work by itself if it uses a published > functional interface to the library. I'd say this differently. The program is not a derivative work of the library if it was written without any of the relevant copyrighted material of that library. "A published functional interface" is a easily recongizable and legit way for a program to be written so that the program uses the library even though the program was written without using the library. Here, there's other material under a different copyright (the spec [obviously], but also the library headers and a library implementation). > That's the upshot of the case law as I understand it, although you > have to combine a number of precedents to get there. Here's one from > the First Circuit that I haven't cited previously, which is pretty > much a slam-dunk: Lotus v. Borland 1995 ( > http://www.law.cornell.edu/copyright/cases/49_F3d_807.htm ). > > > We also note that in most contexts, there is no need to "build" upon > other people's expression, for the ideas conveyed by that expression > can be conveyed by someone else without copying the first author's > expression. In the context of methods of operation, however, > "building" requires the use of the precise method of operation already > employed; otherwise, "building" would require dismantling, too. > Original developers are not the only people entitled to build on the > methods of operation they create; anyone can. Thus, Borland may build > on the method of operation that Lotus designed and may use the Lotus > menu command hierarchy in doing so. > It's probably worth noting that Borland did this without using any lotus library (or headers, and probably without reference to any formal specification), and they certainly weren't being sued for using any such library inappropriately. Since the GPL restricts distribution of itself at violation time, this idea of "function isn't copyrightable" isn't going to solve all the problems faced by someone violating the GPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
On Thu, Jan 20, 2005 at 02:17:11AM -0800, Michael K. Edwards wrote: > Agreed. But use of a brand name to attempt to stop other people from > giving away the same thing you do under the same name is a bit of a > novelty. Advertisers have been doing this for years, as have broadcasters. [There's ways of making money off free software that don't involve advetising (for example, when you have product A which is a complement to product B, increases in the supply of product A increases the demand for product B), but that's not a new idea either, but I've not done any research on branding history in that context.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Wed, Jan 19, 2005 at 07:22:50PM -0500, Michael Poole wrote: > To summarize you argument: Debian includes both GPL-incompatible work > X and GPLed work Y. Work X can be run on top of other programs than > work Y, but Debian does not distribute those alternatives. That last clause ", but Debian does not distribute those alternatives" was not a part of my argument. I don't think it's an accurate assessement what Debian does, either. For example, we distribute emacs, and we distribute GPL incompatible text files. For example, we distibute linux, and we distribute GPL incompatible executables. And we distribute a variety of other GPL programs which handle quite a wide variety of data -- some of which we distribute. > Work X itself (in either source or binary form) is not a derivative of work > Y, but within Debian, work X can only be run on top of work Y, and we > ship both of them. Again, not a part of my argument, and not a statement I agree with. > Because of that, this is beyond mere aggregation, > and work Y must be made GPL-compatible or moved to contrib. Correct? No. > If so, what is the difference is between Y=Kaffe and Y=Linux? Linux > exempts syscall-using clients from being directly covered by the GPL, > but Kaffe has no direct copyright claim on pure java applications. > It is again a question of how to define "mere aggregation" in the > collective work known as Debian. I can think of numerous differences between Kaffe and Linux, but none seem relevant to this conversation. In any event, in my last message I was disagreeing with your reasoning, not your conclusions. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> Walter Landry writes: > > GPL 2 uses a different term: "work as a whole". The different > > sections do not have to be related by copyright at all. On Wed, Jan 19, 2005 at 06:48:26PM -0500, Michael Poole wrote: > If the two works are not related by copyright, then they are merely > aggregated. I don't think it's always that simple. The "work as a whole" thing is a part of the requirements that come into play when someone modifies the program. Basically, when you modify the program, you're creating a new work, and the GPL requires that all parts of that new work are licensed appropriately. Maybe it would help to think of this as question of what's "inside" and what's "outside" the modified program. Things that are inside (libraries, modules, headers, etc.) need to be GPL compatible. This is where the OS exception comes in. Things that are outside (independently created programs and data -- things that aren't needed to make the modified GPLed work be complete) do not need to be GPL compatible. This is where the clauses about running the program and about mere aggregation come in. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
On Wed, Jan 19, 2005 at 10:09:02AM -0800, Michael K. Edwards wrote: > But the FSF is going to lose a lot of credibility, even with the > choir, if they wait until their noses are rubbed in it in the next > lawsuit to admit that there isn't any universal "law of license" in > the real world after all. Hint: it's not a coincidence that open > source companies and foundations with their own lawyers to advise them > are fortifying around trademark now. These two sentences don't seem to be related. They probably shouldn't be in the same paragraph. Brand name recognition is not a concept invented by lawyers for open source companies. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and Copyright Law (Was: Eclipse 3.0 Running ILLEGALY on Kaffe)
On Wed, Jan 19, 2005 at 12:01:48PM -0800, Michael K. Edwards wrote: > The end being achieved is a major factor in finding a "functional > interface" for legal purposes. We're in violent agreement, here. > The GPL is indeed an offer of contract, but it ties standards of breach > so closely to copyright infringement that there isn't much room to > argue that non-infringing use still breaches the GPL. True, but the distinction between what's infringing and what's not is ... sometimes subject to debate. Anyways, as I understand it, the GPL was inspired by a case where the author of a program (who just happened to be RMS) was not allowed to read modified copies of his own work unless he signed a legal agreement which limited his right to further distribute his work. As a mechanism for releasing software for public use without exposing authors to these kinds of risks (and, thus, encouraging increased computer literacy), I think the GPL does a pretty good job. > Canadian case law seems to be similar, and Canadian courts make > careful use of US precedents in this area (such as the "abstraction - > filtration - comparison" test of Computer Associates v. Altai). I'd > be surprised if US and Canadian appeals courts were to reach seriously > divergent conclusions on facts similar to, say, MySQL v. Progress > Software. The parties settled out of court. In essence, the only thing the judge decided was that the issues worth taking to trial. Given the lack of precident, that's hardly a surprising decision. So, yeah, a Canadian judge would likely decide the same way... but the significant thing this says about the GPL is that it's something new. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Wed, Jan 19, 2005 at 12:52:29PM -0500, Brian Thomas Sniffen wrote: > It seems to me that "mere aggregation" must be the smallest idea that > is still aggregation. What is "the smallest idea"? Do you mean "the least restrictive idea"? For example: both pieces of software happen to exist at some point in time in the same universe? Or do you litterally mean "the smallest", as in "the physical distance separating the pieces of software must be no more than epsilon, where epsilon is on the order of a tenth of a millimeter"? I'm guessing that you're thinking that when the GPL says "mere aggregation" you're thinking that it's defining multiple classes of aggregation, and where the "mere" class is unrestricted but some other "big" class is restricted. To me "mere aggregation" seems to mean "aggregation that's just aggregation and not a reflection of some form of modification". > It's not necessary to look in great detail at what *is* going on there > -- it's enough to say that there is more there, so it's not merely > aggregation. It's aggregation and something else. This doesn't mean that you can ignore those details. The GPL only restricts certain things and it REQUIRES that other things be unrestricted. If you claim that something which the GPL requires to be unrestricted makes something be not "mere aggregation", you are in direct opposition to the GPL. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian repeatedly asserts that the relationship between Eclipse and Kaffe is not "mere aggregation", but declines to say what that relationship is. To my knowledge, the only relation between Eclipse and Kaffe other than "mere aggregation" is that Kaffe runs Eclipse. But the GPL also states that that is unrestricted. More generally, however, mere aggregation is the ONLY distinction between putting Eclipse in main and putting Eclipse in contrib or non-free. In both cases, there will be users who use Kaffe to run Eclipse. If there's some other kind of relationship between Eclipse and Kaffe, which is a problem in the context of the GPL, then we would have to choose between distributing Eclipse and distributing Kaffe. But near as I can tell, everyone agrees that we can distribute both Eclipse and Kaffe -- the only question is the one about aggregation. On Wed, Jan 19, 2005 at 01:03:44AM -0500, Brian Thomas Sniffen wrote: > Not a derivative work: a copy. Debian distributes copies of Kaffe, > and is considering distributing them with copies of Eclipse. That's > only OK if it's not "mere aggregation". When Kaffe is the only reason > Eclipse can go in main, I don't think we're talking about mere > aggregation again. Here, Brian confuses our free software guidelines with the GPL. The guidelines do not constitute license restrictions. On Wed, Jan 19, 2005 at 01:07:16AM -0500, Brian Thomas Sniffen wrote: > It's just a work containing copies of Kaffe and (soon) Eclipse in > closer proximity than aggregation. There's no such thing. Or, if there is, please explain how you determine these quantities. I'm asserting that the distinction between "mere aggregation" and "a work based on the program" is not one of proximity. > It's not about a derivative work or ownership of an API. It's just > about distributing copies of Kaffe with copies of non-GPL'd works. Unless you can show some relationship which is significant in the context of the GPL, I assert that you're talking about mere aggregation. If you can show that kind of relationship, I assert we can't distribute Eclipse in contrib or non-free. > > The distinction between main and not-main is purely a DFSG issue. The GPL > > doesn't care about this distinction at all. On Wed, Jan 19, 2005 at 11:06:33AM -0500, Brian Thomas Sniffen wrote: > Not true. The GPL prohibits distributing bundled copies of GPL'd and > GPL-incompatible works, if they are more tightly coupled than mere > aggregation. I'm going to classify this as a half-truth. What you've not shown is what clause in the GPL -- other than the mere aggregation clause -- which is relevant in this context. > That is, the Debian OS is a work. It contains copies of > Kaffe and Eclipse. They are interdependent, more closely related > than, say, Eclipse and isync. Thus, they must both be distributed > under the terms of the GPL. The interdependence is a runtime relationship. There is no body of copyrighted work in Eclipse which is derived from Kaffe. > Eclipse will also be distributed on CDs with Kaffe, such that the CDs > install an OS with Eclipse and Kaffe set up together. Eclipse will be > part of the Debian OS, which is a work containing a copy of Kaffe. > That fits the GPL's definition in section 2, so Eclipse has to be > under a GPL-compatible license. Section 2 consists of a list of conditions which have to be satisfied when you modify Kaffe. For section 2 to be relevant, you have to show that eclipse is a part of the modified Kaffe. You've no grounds for claiming Debian is a part of the modified Kaffe. > > Since the only relationships between Eclipse and Kaffe are: they're > > (or would be) aggregated together in Debian, and when Kaffe runs, it > > (sometimes) processes Eclipse, and since the GPl specifically allows > > these relationships to be unrestricted, that "work as a whole" language > > is not an issue in this context. > > There is another relationship: the artisans creating Debian made a > creative choice not to put Eclipse in until Kaffe satisfied certain > properties. That wouldn't happen in a case of mere aggregation. Actually, that's typical of what happens with mere aggregation: Files are aggregated because someone decided to store them together. That decision is, as a general rule, based on certain properties of those files. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
On Tue, Jan 18, 2005 at 05:54:40PM -0800, Michael K. Edwards wrote: > In this context, I mean "credible analysis of the legal issues". Eben > Moglen and Bruce Perens were both publicly quoted in the lead-in to > the MySQL trial as being confident that MySQL would win a preliminary > injuction on the GPL issues. They didn't. There were several reasons > for this, which mostly add up to "the judge followed precedent in > applying copyright law standards where they were appropriate and > contract law standards where they were appropriate". Neither the > FSF's subsequent public comments nor the correspondence I have had > with [EMAIL PROTECTED] addresses this point, nor do they seem to be > willing to adduce any modern legal precedent in any jurisdiction. >From my point of view, the brief was trying to estalish that the GPL was protecting value in the case of mysql, and that violating the GPL took away from that value. But I think it wasn't really written for the judge, but was instead written for someone who was already convinced. > I am far from being the first to make this criticism. See, for > instance, the comments in > http://www.oslawblog.com/2005/01/static-linking-gpl-and-lgpl.html by > people who cite actual legal precedents. The emperor is a decent guy > and usually on the side of the angels, but I'm sorry to say that he > has no clothes. This is meta discussion about an oversimplification. It's basically correct, but I don't think the emperor is running around nude, even if that hat is a bit skimpy. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Tue, Jan 18, 2005 at 07:43:08PM -0500, Walter Landry wrote: > But none in Debian main. People seem to be missing the point, so I > will repeat: I am not saying that Eclipse is not distributable, just > that it can't go into main. That's easy to say. It's much harder to back up. The distinction between main and not-main is purely a DFSG issue. The GPL doesn't care about this distinction at all. If you were talking about a GPL license conflict between Eclipse and Kaffe, you'd have to say that Eclipse is not distributable at all. So, you have to show that there's something about the DFSG or the Eclipse license that prevents Eclipse from going in Main. > > On Sun, Jan 16, 2005 at 10:21:23PM -0500, Walter Landry wrote: > > > The kernel has an exemption. This has been pointed out more than > > > once. > Raul Miller <[EMAIL PROTECTED]> wrote: > > Irrelevant: On Tue, Jan 18, 2005 at 07:43:27PM -0500, Walter Landry wrote: > You seem to be missing the point. Someone pointed out that my > interpretation would require all programs to be GPL compatible. I > pointed out an exemption. If I recall correctly, that point was about "all the programs in Debian", not "all programs everywhere". But, the exemption you pointed out doesn't apply to Debian. That makes it irrelevant. > > > There are no JVM's on that CD that will run Eclipse. > > Irrelevant. > > It is relevant if you are trying to satisfy all of the dependencies > for Eclipse in main. I am not quite sure what you are responding to. If you're talking about the behavior of the packaging system, that would be relevant on some other mailing list... but as a general rule not on debian-legal. If you're talking about licensing -- you haven't shown anything to be relevant. > > > > [3] Debian dependencies. [The GPL doesn't seem to have any requirements > > > > in this area.] > > > > On Sun, Jan 16, 2005 at 09:06:31PM -0500, Walter Landry wrote: > > > Actually, it does. The GPL says (with some parts elided) > > > > > > If sections are separate works, then this License does not apply to > > > those sections __when you distribute them as separate works__. But > > > when you distribute the __same__ sections as part of a whole which > > > is a work based on the Program, the distribution of the whole must > > > be on the terms of this License. > Raul Miller <[EMAIL PROTECTED]> wrote: > > You seem to be begging the question. > > > > The GPL doesn't say that. > On Tue, Jan 18, 2005 at 08:57:37PM -0500, Walter Landry wrote: > That is why I included the parenthetical "with some parts elided". In other words: the GPL doesn't say that -- it says something very different. But it contains phrases which can be rearranged to say what you said. Of course, what you said has not relevance to the DFSG, the GPL, Exlipse, Kaffe, or pretty much anything else. But you can take some satisfaction in having said something which had a certain internal self consistency. ... > > This does not equate to debian's dependencies. The GPL has very clearly > > limited its scope (to "the Program" and/or a "work based on the Program") > > and debian can have dependencies for any of a variety of reasons not > > relating those particular concepts. > I will grant you that the mapping between Debian dependencies and > "whole works" is not perfect. But it is pretty good. This doesn't make Eclipse a part of Kaffe, or of a work based on Kaffe. Which means that the GPL's "work as a whole" clauses don't come into play at all. Eclipse is associated with Kaffe, when it's associated at all, only in the context of running Kaffe, and the GPL explicitly states that the act of running Kaffe is not restricted. > > In other words, you can't answer the question is this thing an > > example of "the Program" or a "work based on the Program" with > > a condition which exists only for modified copies of "the Program" > > or a "work based on the Program". > > I don't see the relevance of this distinction. Debian patches Kaffe, > and reserves the right to patch it further. Otherwise, Kaffe could > not go into main. Debian, as a whole, is not a work based on Kaffe. The relationship of Debian, as a whole, to Kaffe, is covered in the GPL in the sentence that talks about "mere aggregation". Eclipse isn't a part of Kaffe. Eclipse isn't a part of a work based on Kaffe. Eclipse is a part of an aggregate work which includes Kaffe (but that's OK, according to the GPL).
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Tue, Jan 18, 2005 at 03:26:56PM -0700, Joel Aelwyn wrote: > (I, for one, have never bought the "magical exec() boundary" FSF argument; > an API is a natural barrier which can be fairly straightforwardly tested > and is covered by fairly well understood precedents already. *Especially* > if that API happens to be outside the domain of either of the parts > involved.) I think that the exec() boundary is a more accurate approximation than an ABI boundary, simply because it's a more constrained case (exec() being a small subset of all possible ABI features). However, fundamentally, technical details provide information about a situation but other kinds of information also exists. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
> On Tue, 18 Jan 2005 12:51:22 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > I still don't see how this sub-license construction satisfies the mandate > > that "the recipient automatically receives a license from the original > > licensor..." On Tue, Jan 18, 2005 at 01:08:57PM -0800, Michael K. Edwards wrote: > I think it's generally held that, say, a software retailer is moving > around boxes containing both software and license (in the intangible > sense, not just the paper with text on it), while a software publisher > is exercising authority to sublicense when making, boxing, and > distributing copies of the software. In either case, there's a > license from the copyright holder being transferred, but the retailer > isn't party to any contracts except in the most primitive sense of > common-law contracts of sale. The retailer has common-law authority > to transfer licenses around only as a component of the boxes he's > moving. I think you're confusing EULA with Copyright License. With copyright, the copyright holder grants license to the publisher to make copies and that's usually the end of the story. There are exceptions, of course (developer tools being a fairly classic one -- developer tools usually grant unlimited redistribution rights to some of the contained content). End User License agreements are something different and seem to be based more on contract law than on copyright law. Anyways, in this context it does make sense to consider the distributor as an agent of the publisher -- because the distributor has no license from the copyright holder, while the publisher does. [In the classic commercial model, this is also the case for developer tools (while some of the content has an unlmited redistribution license, most of the content typically does not).] But under the GPL, the distributor gets a license from the copyright holder, so the distributor does not have to act as an agent for the publisher. In any event, the way I see it you're talking about traditions which were developed to deal with an issue which is not present in the context of the GPL. And, furthermore, the GPL seems to contain explicit language conflicting with this application of that tradition. > In order for C to "automatically receive" a license under GPL from B > along with the physical (electronic) copy of the subject matter, B has > to have the authority to transfer license along with it. Ok... but let's first try to establish why C would need to receive it from B rather than from the original licensor (which is what the license says happens). So far you've only indicated that that's what happens with other licenses (which don't have this "receives a license from the original licensor" language). > Given that B is doing the copying, it seems natural to me to put B in > the position of the software publisher and to construe agency terms > from A to B. Grammatically, this ties "from the original licensor" > to the noun "license" (C has A's permission, which B has agency to > grant) rather than the verb "receives". I'm not following you here at all. A licensor is someone. But your grammatical argument seems to argue that the license is that someone. Is the license document (or legal abstraction) the agent now? You could argue that the recipient recieves the license from the original licensor via "B", which makes "B" be an agent for the purpose of passing the license on. But the end result of that argument is still a license granted directly from "A" to "C". > > > I think that's much cleaner as a basis for findings of fact than the > > > "contracts upon contracts" construction, and does a better job of > > > reaching the parties' intent, which is what judicial construction is > > > supposed to do. > > > > Ok, I understand that you have some kind of personal preference which > > favors the sublicensing construct. I'm not convinced that your preference > > accuratly reflects how the law would treat this issue, but I do understand > > that that is your opinion. > > It's not so much a personal preference as a guess. The commonly cited > precedent on when and how a right to sublicense can be construed is > Harris v. Emus Records 1984 (9th Circuit), but I haven't been able to > find a URL for it (and don't have other resources handy). That case > addressed a copyright under the 1909 act but is still cited for > guidance under current law, often in the same breath with Herbert v. > United States 1996 (Federal Claims Court), also hard to find. One thing I think you need to keep in mind: precedent is narrowly focussed on the i
Re: Questions about legal theory behind (L)GPL
On Mon, Jan 17, 2005 at 12:55:47PM -0800, Michael K. Edwards wrote: > > > As I understand it, generally speaking, a contract has two > > > parties -- offeror and offeree. On Mon, 17 Jan 2005 17:04:02 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > Ok. However, it's worth noting that these parties are distinct each > > time the [implied] contract is executed. On Mon, Jan 17, 2005 at 10:53:58PM -0800, Michael K. Edwards wrote: > That's one reason why I think the sublicensing interpretation is > more natural. How is that a reason? > > In other words, I see multiple implied contracts, but each contract > > is between the original copyright holder and the recipient. I don't > > see any grounds for thinking that there's any sublicensing. > > > > For that matter, sublicensing might be seen as an attempt to circumvent > > the requirement that the original licensor grant the license to the > > recipient. > > There's some reason to this, especially in light of GPL section 4. > But that would result in potential jeopardy for breach of contract > between each licensee and every copyright holder. That has nasty > consequences, which I wrote out in the draft I lost (don't use Google > Search in the same tab as your GMail session!) but will summarize as > "both sides become vulnerable to expensive to defend, quasi-frivolous > lawsuits in inappropriate jurisdictions". The doctrine of agency was > created to avoid this kind of nastiness and make complex business > relationships possible without an endless web of implied contracts. You've already got that with widespread distribution of popular programs. I'd need to see a pretty convincing precedent to imagine that this doctrine of agency has any relevence in the context of the GPL. > > > To get the same effect with "direct licensing", you'd have to read > > > separate offers of contract from each copyright holder to the recipient > > > into the single act of passing her a modified work, which is a little > > > far-fetched. > > > > The way I read it, those offers of contract from each copyright holder > > to the recipient are made each time the program is redistributed. > > > > I don't see why this is "far-fetched", and I don't see any reason to > > pretend that that's not what the license mandates. > > A mandate without an implementation is subject to construction. > Construing agency to issue sublicenses leaves the contract between > distributor and immediate recipient where it belongs, with subject > matter being the entire contents of the offered blob of software. I still don't see how this sub-license construction satisfies the mandate that "the recipient automatically receives a license from the original licensor..." > I think that's much cleaner as a basis for findings of fact than the > "contracts upon contracts" construction, and does a better job of > reaching the parties' intent, which is what judicial construction is > supposed to do. Ok, I understand that you have some kind of personal preference which favors the sublicensing construct. I'm not convinced that your preference accuratly reflects how the law would treat this issue, but I do understand that that is your opinion. > > > My guess (IANAL) is that a court would find that, when A offers > > > Project X under the GPL, B modifies and distributes it, and C accepts > > > license in the modified version, B and C have formed a contract and > > > A's participation is limited to the agency for sub-licensing purposes > > > implicit in the contract that it offered B. This is especially likely > > > to hold in a situation where B is Debian, since most users deal > > > directly with Debian for updates, bug reporting, etc., and can > > > reasonably claim that as far as they are concerned their license came > > > from Debian and the rest is between Debian and the upstream(s). > > > > I don't think a court case where this issue is relevant is likely. > > Suppose the FSF had gone beyond complaining and threatening when KDE > used Qt under the QPL and proceeded to sue, say, IBM for bundling > RedHat with some of their servers. Don't you think it would be > relevant whether IBM could claim reliance on RedHat as the FSF's > agent? I think I did more complaining on that one than the FSF. I maybe missed something, but I remember the FSF being fairly hands-off on that issue. But, that aside, I think suing IBM would be a dumb move. Talk about expensive lawsuits... Ok, if you've established sufficient precedent by suin
Re: Questions about legal theory behind (L)GPL
On Mon, Jan 17, 2005 at 05:41:26PM -0500, Glenn Maynard wrote: > Well, by the nature of free software, I can incorporate code into my > program from yours (or into a friend's program, eg. writing a patch for > lftp incorporating code from wget), without you necessarily being made > aware of it at all. It's not hard for an original author to legitimately > not become aware of such reuse for a long time. The "contributor" > of code isn't necessarily the copyright holder. True. Though I imagine a judge would be rather at amused some contributor who thought they could sue someone else for copyright violation for running a program that incorporated their GPLed code. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and Copyright Law (Was: Eclipse 3.0 Running ILLEGALY on Kaffe)
On Mon, Jan 17, 2005 at 02:16:37PM -0800, Michael K. Edwards wrote: > Summary: Canadian law has a few interesting differences from US law, > but I reach the same main conclusions -- the GPL is a valid offer of > contract; technical distinctions like "linking" vs. "interpretation" > are irrelevant to its legal force; and a judge is unlikely to permit > the GPL to reach across a published functional interface irrespective > of the FSF FAQ or of the GPL variants the FSF has created (LGPL, > Classpath, gcc, etc.) in order to relax the, in my opinion, imaginary > barrier to linking GPL code to code under other licences. Remember that the judge's primary interest functionality is going to be centered around determining the scope of the source code requirement from section 3. The judge would only care about determining which sources were required for the GPLed binaries in question. You're right that one technology being used instead of another won't make a difference if the same end is achieved. But, in the same way, "reach across a published functional interface" is a technical detail whose significance depends on the end which is achieved. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
> > > > The GPL is a license document, and "automatically receives" is a > > > > license grant. The GPL doesn't need to be law to grant license -- > > > > granting license is what copyright licenses do. > > On Sun, Jan 16, 2005 at 10:48:55PM -0800, Michael K. Edwards wrote: > > > "The GPL isn't law" was in response to "the GPL doesn't say this is an > > > authorization to sublicense". Under US law as I understand it, > > > there's no other way to implement the purported license grant > > > indicated by "automatically receives" other than the sublicensing > > > paraphrase that I gave. > On Mon, 17 Jan 2005 13:48:23 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > Why would direct licensing not work? On Mon, Jan 17, 2005 at 12:55:47PM -0800, Michael K. Edwards wrote: > As I understand it, generally speaking, a contract has two parties -- > offeror and offeree. Ok. However, it's worth noting that these parties are distinct each time the [implied] contract is executed. > To the extent that it binds other persons or entities, it does so > through the doctrine of agency -- either party A declares that non-party > B will fulfill some of A's obligations as an agent of A, or A agrees, > acting as an authorized agent of B, to commit to conduct on B's behalf. Until you've established that the GPL binds third parties through any means other than direct execution of the [implied] contract, this is begging the question. > The GPL appears to me to fall under the latter, authorizing the licensee > to offer a sub-license to all copyrights in the incoming GPL work. I disagree. The GPL states Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to ... This is very clearly a license from the original licensor (whoever that is) to the licensee. Of course a Program might have multiple copyrights, but the GPL has required (under section 2) that the people who have added such material have made it available under the GPL terms. In other words, I see multiple implied contracts, but each contract is between the original copyright holder and the recipient. I don't see any grounds for thinking that there's any sublicensing. For that matter, sublicensing might be seen as an attempt to circumvent the requirement that the original licensor grant the license to the recipient. > To get the same effect with "direct licensing", you'd have to read > separate offers of contract from each copyright holder to the recipient > into the single act of passing her a modified work, which is a little > far-fetched. The way I read it, those offers of contract from each copyright holder to the recipient are made each time the program is redistributed. I don't see why this is "far-fetched", and I don't see any reason to pretend that that's not what the license mandates. ... > > I imagine that (where two copyright holders differ from one another in > > their interpretation) the judge would look at the history of how these two > > copyright holders have acted. If one has recently changed their intent > > then the judge would need to consider their previously expressed intent. ... > On the question of sub-licensing, I doubt that you would be able to > find evidence of either copyright holder's stance in advance, and it > wouldn't matter much anyway, since as a matter of law (in the US) > ambiguities in contracts must be construed against the offeror and > there's no way to demonstrate the licensee's intent in a > non-negotiated, "standard form" contract. (That isn't necessarily > true if there's a history of correspondence between the parties and it > can be demonstrated that both interpreted the contract in the same > way.) I'm thinking that there will typically have been a history of correspondence between the parties. Most likely: an email archive, the changelog, release announcements, etc. And the basic question is: why was the material contributed in the first place? As a general rule, if someone had an objection to their content being distributed, they would speak up shortly after they find out about the issue. If some extended period of time has passed (for example: the time between Debian Stable releases), there's a very real question as to why the issue wasn't raised earlier. This issue, in concert with testimony about informal communication between the parties, should be sufficient in most if not all cases of "some free software developer decides to litigate about some old code". Of course, if the code has just recently been add
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Mon, Jan 17, 2005 at 08:07:56AM -0500, Michael Poole wrote: > That is clear about *a* copyright holder. It is not necessarily true > about all of them. There have been times where Linus's interpretation > was not shared by all: Linus has said he has no objection to > distributing binary firmware blobs in aggregation with the kernel, but > others who contribute to the kernel objected to that practice. Linus has tossed code out of the kernel in a few cases where the submitter has made it clear that they were unhappy about their code being in the kernel. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Questions about legal theory behind (L)GPL
> > The GPL is a license document, and "automatically receives" is a > > license grant. The GPL doesn't need to be law to grant license -- > > granting license is what copyright licenses do. On Sun, Jan 16, 2005 at 10:48:55PM -0800, Michael K. Edwards wrote: > "The GPL isn't law" was in response to "the GPL doesn't say this is an > authorization to sublicense". Under US law as I understand it, > there's no other way to implement the purported license grant > indicated by "automatically receives" other than the sublicensing > paraphrase that I gave. Why would direct licensing not work? > > The only thing needed to make sense of section 6 for the case where > > there are multiple copyright holders is recognition of "the original > > licensor" and "the recipient" both apply under the scope of section 6's > > "Each time". Since the terms are the same, regardless of the copyright > > holder and regardless of the recipient, there is no ambiguity here. > > This is sort of a "recursive closure" argument, which is reasonable as > a way to understand the drafter's intent, but doesn't guarantee that a > court will find that the license language accomplishes that intent. As a general rule, there are no guarantees about what a court will find. > It frequently happens that contract provisions are modified or struck > during interpretation by a judge because they conflict with statute. Yep. Of course, it also frequently happens that contract provisions stand, unmodiied. > US copyright statute, as interpreted by appeals courts to date, > appears to me to require that authorization to sublicense be pretty > explicit in a written contract. First, let's here why you think direct licensing isn't granted -- the clause appears to be stated rather clearly to grant licensing directly. I'll grant you that the GPL is a license which is unprecedented in many respects. But that doesn't make it invalid -- just different. > IANAL, and I can't say for certain how a court would weigh the GPL > drafters' intent (which I agree is reasonably clear on this particular > point) against precedents like Everex v. Cadtrak -- especially if two > copyright holders differ from one another on the interpretation. I imagine that (where two copyright holders differ from one another in their interpretation) the judge would look at the history of how these two copyright holders have acted. If one has recently changed their intent then the judge would need to consider their previously expressed intent. If there is no such change, then the judge would probably look at how the situation developed, to determine which parts of the copyrighted work belong to which party. > Suppose Ms. X contributes some code to Kaffe and then sues Debian for > distributing Kaffe and Eclipse together. Then suppose that the FSF > files an amicus brief saying that Debian is OK because GNU Classpath > has a special linking clause and Ms. X's code is part of an > interpreter, while the main copyright holder on Kaffe files an amicus > brief saying that as far as he is concerned the GPL doesn't propagate > across linking boundaries and that if Ms. X says different then she's > failing to extend the same license to Debian that he extended to her. > Whose interpretation wins? The answer could depend critically on what > implicit terms the court construes in order to implement the implied > authorization to sublicense -- or some other way around the problem > that I'm not seeing. Most likely, the judge would say that Ms X doesn't have standing. Eclipse is not a module of Kaffe. In the unlikely event that she did have standing, I'm sure the judge would ask her what she thought people would use Kaffe for, and why she contributed the code. [Also, if the FSF did get involved, I imagine they'd be able to cover a lot more ground in that brief -- I don't think they'd limit the scope to classpath.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Sun, Jan 16, 2005 at 10:21:23PM -0500, Walter Landry wrote: > The kernel has an exemption. This has been pointed out more than > once. Irrelevant: The kernel supplies kernel-specific #include files which are incorporated into C program. Kaffe doesn't supply any such thing -- no one has identified any GPL'd content which is a part of Eclipse. Some people have implied that the byte-code output which Kaffe generates is GPL'd content, but they've not said why this would be, and the GPL clearly states that program output must be considered on a case by case basis -- that whether or not program output is GPLed depends on what the program does. But no one thinks that Kaffe puts any GPLed content into its output, when compiling (or running) Eclipse. > > > Now, it is true that Eclipse will run with other JVMs. But if they > > > are not on the CD, then it doesn't matter. The GPL cares about what > > > it is distributed with, not about stuff it could be distributed with. > > > And the only thing allowed on the CD is stuff in main, because this > > > whole argument is over whether Eclipse can go into main. Not whether > > > Eclipse is distributable at all. > > > > The other VMs are on that CD, because they are in main already. As I said before "... it doesn't matter." > There are no JVM's on that CD that will run Eclipse. Irrelevant. We distribute the full source for Kaffe. The OS exeption would only be useful under certain cases where we did not distribute the full source to Kaffe (for example, if we distributed a version of Debian which was hosted on some other proprietary OS). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
> > [3] Debian dependencies. [The GPL doesn't seem to have any requirements > > in this area.] On Sun, Jan 16, 2005 at 09:06:31PM -0500, Walter Landry wrote: > Actually, it does. The GPL says (with some parts elided) > > If sections are separate works, then this License does not apply to > those sections __when you distribute them as separate works__. But > when you distribute the __same__ sections as part of a whole which > is a work based on the Program, the distribution of the whole must > be on the terms of this License. You seem to be begging the question. The GPL doesn't say that. I'm guessing that the paragraph you've rephrased is: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, ... This does not equate to debian's dependencies. The GPL has very clearly limited its scope (to "the Program" and/or a "work based on the Program") and debian can have dependencies for any of a variety of reasons not relating those particular concepts. In other words, you can't answer the question is this thing an example of "the Program" or a "work based on the Program" with a condition which exists only for modified copies of "the Program" or a "work based on the Program". > If I give you a CD with Eclipse and Kaffe on it, I have given you a > whole work which will edit programs. "which will edit programs" is: [a] Not an issue for Copyright law. (No one seems to question this.) [b] Not an issue for the GPL. (The GPL explicitly states that it does not restrict running the program.) > You may not even know what Kaffe is, but if you don't have it, Eclipse > is not going to run. (Unless you have another JVM installed. Which you may or may not know about.) > That sure sounds like it makes up part of the whole which is an IDE. Which is a functional issue, and does not appear to be an issue under either copyright law, or the GPL. This is further underlined by the fact that Kaffe is not an IDE. > This relationship is well expressed by Debian dependencies. Sure, but this relationship doesn't matter in the context of the GPL. Kaffe is a Java Virtual Machine. You run Java programs on it. That's what it does. Java programs are almost never derivative works of Kaffe any more than text files are derivative works of emacs. > Now, it is true that Eclipse will run with other JVMs. But if they > are not on the CD, then it doesn't matter. By "it doesn't matter", I presume you mean "they won't be available for the user to install from that CD, and if they haven't already been installed on the user's system they won't be available for that user." In other words, you're still talking about running the program. If you meant something else, please say it less ambiguously. > The GPL cares about what it is distributed with, not about stuff it > could be distributed with. The only context where the GPL cares about what it is section 3. There are two cases which matter there: [1] There's the issue of distributing the source code which goes with the binary (for a GPL'd work). [2] There's the special OS exception from the source code requirement (when parts of a GPLed work require something always available with the OS, you don't need to distribute the source code for those parts of that OS). But we're trying to answer the question of whether or not this is a GPLed work... > And the only thing allowed on the CD is stuff in main, because this > whole argument is over whether Eclipse can go into main. Not whether > Eclipse is distributable at all. If the GPL restricts Kaffe from being distributed with Eclipse then the GPL does so regardless of whether Eclipse is in main. So if Eclipse can't go in main because the GPL says that it's illegal to distribute Kaffe when we distribute Eclipse, then this is the case regardless of whether Eclipse is in main or in contrib. Now, if Eclipse was the GPLed work, and Kaffe was GPL incompatible, we'd have other problems with section 3. But no one is claiming that Eclipse is a part of Kaffe. > > If you're simply going to assert that "this is not mere aggregation" > > and are not going to provide any good reasons for that assertion, what > > is it that you're contributing to this discussion? > > I feel like there are an awful lot of people that want to get Eclipse > into main ASAP, and are not fond of thinking through licensing issues. > It is hardly the first time. Which licensing terms? The only one you've presented for consideration was an almost unrecognizable paragraphrase of a part of the GPL which is ir
Re: Questions about legal theory behind (L)GPL
On Sun, Jan 16, 2005 at 02:09:09PM -0800, Michael K. Edwards wrote: > The GPL isn't law, and its characterization of what's happening under > law when you distribute a modified work is pretty bogus. (The > recipient "automatically receives"?) The GPL is a license document, and "automatically receives" is a license grant. The GPL doesn't need to be law to grant license -- granting license is what copyright licenses do. The only thing needed to make sense of section 6 for the case where there are multiple copyright holders is recognition of "the original licensor" and "the recipient" both apply under the scope of section 6's "Each time". Since the terms are the same, regardless of the copyright holder and regardless of the recipient, there is no ambiguity here. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
