Can Java code EVER be GPLd, at all?
Jules Bean
jmlb2 at hermes.cam.ac.uk
Mon Nov 15 09:30:59 UTC 1999
On Sun, 14 Nov 1999, Arandir wrote:
> On Sun, 14 Nov 1999, David Starner wrote:
> > On Sun, Nov 14, 1999 at 06:39:55PM -0800, Arandir wrote:
>
> Take Corel as an example. They wrote a GPL application that linked to both the
> GPL'd lib-apt library and the Qt library. Nothing in the GPL says you can't do
> this. Nothing Corel was doing would make lib-apt derivitive of Qt. Only a very
> narrow reading of the GPL from a particular viewpoint would argue otherwise.
> Well, you know what happened... The author of lib-apt gave them an exception,
> but it was slashdot anonymous cowards who pilloried Corel.
Well, the stance is that they created a derived work - the whole package -
which contained some GPL code, so it [may be] is a derived work of
lib-apt. Now, the license for lib-apt says 'you may only create derived
works of this if the derived work is distributable as free software', and
it's not - since I couldn't modify Qt to make the app better and
distribute the result - so a license violation occured. It's a bit of a
bad example, since Qt is going totally free at the next release (although,
not GPL-compatible, of course. *sigh*).
And, I'm not responsible for slashdot anonymous cowards ;-) Try moving
your threshold to 1.
>
> > > Think on this: You have every freedom in the world to write Free Software that
> > > uses Microsoft's MFC, Borland's OWL, Rogue's Tools++, etc.
> > Free software that can only be compiled with non-free libraries isn't all that
> > free.
>
> For a developer who does not have the skill, interest or inclination to modify
> or alter a huge complex library like MFC, they will be freer using MFC
> than a GPL'd library.
Debatable. When something goes wrong with the MFC they're stuck. If
something goes wrong with the GPL'ed library, the community can help. This
is the central point - it's a question of weighing freedoms up against
each other, which will always be difficult.
>
> > >But in the land of
> > > the Free, you are not free to write BSD applications that link to GPL libraries.
> > Right, providing we're talking the BSD license versus the XFree86 license.
>
> Wrong. The MIT (X) license does not give you the right to change the
> license. I can dynamically (and statically) link a GPL application to
> a MIT library. But I cannot do the reverse, according to some.
Uh. Nope. The GPL doesn't tell you you have to distribute everything
actually 'under the GPL'. It says 'under the terms of the GPL'. The point
here is that (as you say) I can't change the license of MIT-licensed
stuff. But, I can certainly give you all the permissions the GPL gives
(since the GPL gives a strict subset of those permssions).
Now, as you point out in another message in this thread, I can't actually
restrict what you do with the MIT code, except to the extent that it's a
derived work of mine. So, if you separate out the MIT code and make it
work without mine, you can do whatever the authors say you can. For as
long as the MIT code and mine are together in a derived work, you have to
satisfy both of us. Since the MIT is so permissive, it is possible to
satisfy both of us. This is what the GPL is all about.
Compare GPL - Qt. This isn't possible, since the GPL requires you to make
the source code available and modifiable, while the Qt forbids you from
making it modifiable. You can't simultaneously satisfy both licenses, so
you can't copy it at all. (You can still use it, of course)
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules at jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules at debian.org | Richmond, Surrey |
| Julian Bean | jmlb2 at hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
More information about the License-discuss
mailing list