Question Regarding GPL

[Ben Tilly]

On 1/20/06, Lawrence Rosen <lrosen at rosenlaw.com> wrote:
> > > 1(b): to translate, adapt, alter, transform, modify, or
> > > arrange the Original Work, thereby creating derivative works
> > > ("Derivative Works") based upon the Original Work;
> >
> > According to the Microstar case it is possible to wind up
> > with a derivative work even though they did not translate,
> > adapt, alter, transform, modify, or arrange the Original
> > Work.  Are those derivative works banned by your license?
>
> Read the OSL 3.0 language carefully. Actions other than those simply aren't
> allowed by the license at all. Other verbs not listed aren't allowed, and
> those verbs that are listed "thereby" create derivative works.

I did, and the way that I read it suggests that there is no permission
for to someone re-implement your program, borrowing enough creative
ideas from yours that the result is a derivative work under copyright.
 I'm trying to verify whether this is truly the case, and if it is
then whether it is an oversight.

It seems silly to me to say, "You may only write that program if you
start with my publically available source-code!"  (I may be severely
misunderstanding what the Microstar case said.)

> Of course, §1(a) says you can also copy the work [e.g., without any
> changes!] into collective works.
>
> In this respect, OSL 3.0 resembles the LGPL and the MPL.

And the GPL for that matter.  Egads, I can see why John Cowan thinks
that Microstar is a horrible decision!

> > My understanding of Galoob says that there should be no
> > copyright issues involved with linking as long as the result
> > is not saved.
>
> Wonderful.

Note that my understanding of Galoob is based on what is said about it
in the Microstar case, and at least one person has said that that was
a bad decision.  So add appropriate amounts of salt.

> > 2. The change runs counter to the stated goals of the FSF.
>
> One of which appears to be license ambiguity about linking. That is their
> right. But as I read statements by Linus, that is not his goal with Linux.
> That's where we started this, trying to understand the goal being enunciated
> by Linus' exception to the GPL. I'm asking if different license language
> could better satisfy the goals for Linux.

License ambiguity about linking is NOT a stated goal of the FSF.  They
want things to be very clear.  They want linking to GPLed code to only
be possible if you GPL your own code.

Rather it is _Linus_ who benefits from ambiguity here.  In general he
likes the GPL, and has publically expressed his satisfaction with
using it for Linux on several occasions.  However he has two big
problems:

1. Linux needs drivers.

2. He strongly prefers GPLed drivers.

Maintaining ambiguity meets both needs.  The ambiguity allowed (and
still allows) drivers to be provided for Linux that would not be
otherwise provided.  Uncomfortableness about the ambiguity pushes
people to provide them in GPLed form.

It is worth comparing the statements at
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in
view of this.  In 1995 when driver support was a bigger issue, he
played up the fact that you could provide non-GPLed drivers.  In 2002
when Linux had a fairly good driver support, he hits hard on the
reasons to be scared if your driver wasn't GPLed.

Cheers,
Ben