> That is the point: the result is not a single work. It is a
> collection or compilation of works, just like an anthology. If
> there is any creativity involved, is in choosing and ordering
> the parts. The creation of works that "can be linked together"
> is not protected by copyright: the liter
> 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?
If you do not agree with the
> >Would you agree that compiling and linking a program that
> >uses a library creates a derivative work of that library?
> No. Compiling and linking are mechanical,
> non-intellectually-novel acts. At most, you have a collective
> work where the real intellectually-novel work was to select
> w
> > > The EULA is irrelevant in germany and in many parts of the USA.
> > Really? I was under the impression EULA's were routinely
> > upheld in the USA.
> > If you have any references for that, I'd love to hear them.
> http://www.freibrunlaw.com/articles/articl22.htm
This wasn't a
> On Tue, 12 Apr 2005, David Schwartz wrote:
> > > If you buy a W*nd*ws install CD, you can create a derived work,
> > > e.g. an image
> > > of your installation, under the fair use rights (IANAL). Can you
> > > distribute
> > > that image freel
> 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 tra
> David Schwartz wrote:
>
> > This would, of course, only make sense if you *had* to agree to the
> > license to *create* the derivative work. If you were able to create
> > the derivative work under first sale or fair use rights, then the
> > restrictions in t
> David Schwartz <[EMAIL PROTECTED]> wrote:
>
> >>Copyright law only _explicitly_ grants a monopoly on preparation of
> >>derivative works. However, it is trivial, and overwhelmingly common,
> >>for a copyright owner to grant a license to create a derivat
> > 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.
> Wrong, sorry. Copyright is a *monopoly* on some act
> On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote:
> > Well that's the problem. While copyright law does permit
> > you to restrict
> > the right to create derivative works, it doesn't permit you to
> > restrict the
> > distribut
> > The GPL applies to distributing a Linux binary I just made even
> > though nobody ever chose to apply the GPL to the binary I just made
> > only because the binary I just made is a derivative work of the
> > Linux kernel, and the authors of that work chose to apply the GPL to
> > it.
> How ca
> On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
> > The way you stop someone from distributing part of your
> > work is by arguing
> > that the work they are distributing is a derivative work of
> > your work and
> > they had no right to
> Scripsit "David Schwartz" <[EMAIL PROTECTED]>
> >> I think the "derivative work" angle is a red herring. I do not think
> >> that either of the two parts that are being linked together (i.e. the
> >> driver and the firmware) are
> I think the "derivative work" angle is a red herring. I do not think
> that either of the two parts that are being linked together (i.e. the
> driver and the firmware) are derivates of the other. The relevant
> point is that distribution of the linked _result_ is nevertheless
> subject to the c
> > No-one is saying that the linker "merely aggregates" object
> > code for the driver; what *is* being said is: in the case of
> > firmware, especially if the firmware is neither a derivative
> > work on the kernel (see above) nor the firmware includes part
> > of the kernel (duh), it is *fairly
> 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 aggr
> Well whoever wrote that seems to have taken the stand that the
> openfirmware package was were the firmware came from. The person
> obviously made a lot of statements without bothering checking out the
> real source. Well it didn't come from there, I got it from Alteon
> under a written agreemen
> But wait; firmware is *not* linking with the kernel, as the icons
> are *not* linking with emacs. Or are they? What is linking? If you
> consider linking to give names fixups and resolving them, well, the
> char tg3_fw[] = ... is linked with the kernel all right. If you
> consider that a call (
18 matches
Mail list logo
