Big development in the GUI realm

[JanC]

Re: Big development in the GUI realm

Kartic schreef:
[color=blue]
> In any case, let's say I use Python to create an application that uses
> some module that is GPL. So what are my options?[/color]

For your own personal use: doesn't mather.

If you want to distribute it, your application must be GPL'ed, so *all*
source code must be made available for those you distribute it to.

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Mike Meyer]

Re: Big development in the GUI realm

"Kartic" <kartic.krishna murthy@gmail.co m> writes:
[color=blue]
> Is there a "GPL for Dummies" out there??? :-)
>
> Sorry if I am asking a question that has already been asked/answered in
> another form.
>
> In any case, let's say I use Python to create an application that uses
> some module that is GPL. So what are my options?
> 1. Distribute my app as closed source but with source, available upon
> request and clearly stated so in my license, for the GPL'ed module. But
> the code to my app only is not available as it is closed source.[/color]

You can't do this one. At least, that's the stand that the FSF is
taking.

I wonder about distributing an installation tool that grabs the GPL'ed
module from it's "standard" location and just installing it? That way,
you're not distributing any GPL'ed code, so your code can be
distributed however you want. It would seem that that would have to be
legal, otherwise apt-get and CPAN would be legally problematical.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Alex Martelli]

Re: Big development in the GUI realm

Dennis Lee Bieber <wlfraed@ix.net com.com> wrote:
[color=blue]
> hassle to code, but if your application could dynamically select from
> whatever toolkit is available on the machine, you (and I should emphasis
> that this is an impersonal/generic "you" I reference) might be able to
> argue an exemption from the QT license.[/color]

So maybe it's time to resurrect anygui, maybe in a simplified version
which can only interface to, say, PyQt or Tkinter -- 'eithergui' maybe.


Alex

[Gabriel B.]

Re: Big development in the GUI realm

> > users. For example, from their FAQ, it seems that no precompiled[color=blue][color=green]
> > binaries will be provided. Support for comercial compilers will not be
> > built in, only for gcc (through Cygwin?).[/color]
>
> Isn't this just the same thing with a different spin. There was always
> an available distribution for linux for non-commercial use. Windows was
> always the problem. You still can't use it for windows without knowing
> how to compile the thing on windows.[/color]

Well, if it's GPLed, can't i simply compile it and distribute a GPLed
..DLL with the source code for everyone?

[Gabriel B.]

Re: Big development in the GUI realm

> >>Considering the fact that the Qt DLL exist by themselves, that the[color=blue][color=green][color=darkred]
> >>version used is the one provided by Qt, and that the EXE uses a
> >>standard, open way to communicate with it, the above does seem to say
> >>this use would be valid.
> >>
> >>[/color]
> >
> > http://www.gnu.org/licenses/gpl-faq....ereAggregation
> >
> > "/.../ If modules are designed to run linked together in a shared address
> > space, that almost surely means combining them into one program.
> >
> > By contrast, pipes, sockets and command-line arguments are
> > communication mechanisms normally used between two separate
> > programs. So when they are used for communication, the modules
> > normally are separate programs. But if the semantics of the
> > communication are intimate enough, exchanging complex internal
> > data structures, that too could be a basis to consider the two parts
> > as combined into a larger program."
> >
> ></F>[/color][/color]

This is odd. They claim it's a GPL'ed version, but it's a trolltech
license that forces you to release your code under gpl even tought
their's not!

I'm not against a company getting it's share with their product.
that's what motivated them in the first place. but DONT LIE! don't
call it gpl when it's not.

Gpl make it very explicity it deals with the program as a whole, in
the meaning of a executable code. What they're trying to achive here
is that, by adding this paragraph, they will cover the "dll use" under
the gpl.

By that cover-all definition they came up, i can't use Internet
Explorer to see a site hosted with a gpl'ed server! i can't even use a
BSD program to grep a file!

anyway... it will only mater when people with money cares. I already
have 3 choices.

[Maciej Mróz]

Re: Big development in the GUI realm

Grant Edwards wrote:[color=blue]
> My understanding is that what you propose is not valid. An EXE
> that uses a GPL'd DLL must be distributed according to the
> terms of the GPL. Were that not the case, the LGPL would not
> have been needed.
>[/color]

I believe this is the case only in simple situation where gpl-ed dll is
_required_ to run exe or exe has some specific support code to work with
gpl-ed dll.

However, imagine simple situation:
1. I write proprietary program with open plugin api. I even make the api
itself public domain. Program works by itself, does not contain any
GPL-ed code.
2. Later someone writes plugin using the api (which is public domain so
is GPL compatible), plugin gets loaded into my software, significantly
affecting its functionality (UI, operations, file formats, whatever).
3. Someone downloads the plugin and loads it into my program

They become effectively larger program, where one part is not GPL (which
is exactly what GPL wants to avoid)
Am I bound by GPL? Certainly not, I did not sign or agree to it in way.
Is the plugin programmer bound by GPL in a way that prohibits writing
GPL plugin to non-GPL program. Not sure, but I don't think so - plugin
is based on API which is public domain
Is end user violating GPL? In the end this is when combining happens. I
don't think so, in my understanding GPL only affects only the
distribution - downloading the plugin means ability to obtain source
code, but does not limit what you do with source as long as you do not
redistribute any derivative works.

I think it does not really matter if plugin programmer and main program
programmer are the same person/organization or not ... it might however
get tricky if GPL plugin is distributed as part of main program.

Unfortunately, GPL faq is extremely vague on such border cases, instead
of simple "yes/no" answers faq is filled with some advocacy talks ...

regards,
Maciej Mróz

[Jeremy Bowers]

Re: Big development in the GUI realm

On Tue, 08 Feb 2005 19:55:01 +0100, Maciej Mróz wrote:[color=blue]
> Unfortunately, GPL faq is extremely vague on such border cases, instead
> of simple "yes/no" answers faq is filled with some advocacy talks ...[/color]

To re-iterate a point I made on a thread last week, nobody really knows
what the GPL says and means on this topic. We can *barely* outline our
ignorance, but even our ignorance is pretty fuzzy.

Copyright-based models can't handle modern computer programs, and the GPL
is still copyright-based. As such, it is hosed.

(For an expansion of that idea, see
http://www.jerf.org/writings/communi...ics/node7.html ; note the
next chapter tries to solve this problem in the context of more
conventional communication, but even with my refinements I'm *still* not
sure how to handle something like the GPL reasonably. I think you'd have
to re-define what the GPL covers almost from scratch; I think it could be
done, but I'm not sure you can fully rationally create an LGPL that
doesn't have critical exceptions.)

[Damjan]

Re: Big development in the GUI realm

> However, imagine simple situation:[color=blue]
> 1. I write proprietary program with open plugin api. I even make the api
> itself public domain. Program works by itself, does not contain any
> GPL-ed code.
> 2. Later someone writes plugin using the api (which is public domain so
> is GPL compatible), plugin gets loaded into my software, significantly
> affecting its functionality (UI, operations, file formats, whatever).
> 3. Someone downloads the plugin and loads it into my program[/color]

I don't think it is legal to distribute the plugin in binary form.
OTOH it should be legal to distribute it as source code.
[color=blue]
> Am I bound by GPL? Certainly not, I did not sign or agree to it in way.[/color]

correct


--
damjan

[Jeff Shannon]

Re: Big development in the GUI realm

Maciej Mróz wrote:
[color=blue]
> However, imagine simple situation:
> 1. I write proprietary program with open plugin api. I even make the api
> itself public domain. Program works by itself, does not contain any
> GPL-ed code.
> 2. Later someone writes plugin using the api (which is public domain so
> is GPL compatible), plugin gets loaded into my software, significantly
> affecting its functionality (UI, operations, file formats, whatever).
> 3. Someone downloads the plugin and loads it into my program[/color]

I believe that in this case, the key is *distribution*.

You are not violating the GPL, because you are not distributing a
program that is derived (according to the GPL's definition of derived)
from GPL code.

The plugin author *is* distributing GPL-derived code, but is doing so
under a GPL license. That's fine too.

The end user is now linking (dynamically) GPL code with your
proprietary code. However, he is *not* distributing the linked
assemblage. This is allowed under the GPL; its terms only apply when
distribution takes place.

If the end user is a repackager, and then turns around and distributes
both sets of code together, then that would (potentially) violate GPL
terms. But as long as they're not distributed together, then it's
okay. This should even extend to distributing a basic (proprietary)
plugin and including a document describing where & how to get the
more-featureful GPL replacement plugin. (Distributing both programs
as separate packages on a single installation medium would be a tricky
edge case. I suspect it *could* be done in a GPL-acceptable way, but
one would need to take care about it.)

Of course, this is only my own personal interpretation and opinion --
IANAL, TINLA, YMMV, etc, etc.

Jeff Shannon
Technician/Programmer
Credit International

[Gabriel B.]

Re: Big development in the GUI realm

> However, imagine simple situation:[color=blue]
> 1. I write proprietary program with open plugin api. I even make the api
> itself public domain. Program works by itself, does not contain any
> GPL-ed code.[/color]

No need to continue. You write something that uses a plugin, Eolas
sues you. Don't have to mind about trolltech

[John Lenton]

Re: Big development in the GUI realm

On Tue, Feb 08, 2005 at 09:19:58PM -0200, Gabriel B. wrote:[color=blue][color=green]
> > However, imagine simple situation:
> > 1. I write proprietary program with open plugin api. I even make the api
> > itself public domain. Program works by itself, does not contain any
> > GPL-ed code.[/color]
>
> No need to continue. You write something that uses a plugin, Eolas
> sues you. Don't have to mind about trolltech[/color]

not if you live in a sane country.

--
John Lenton (john@grulic.or g.ar) -- Random fortune:
Preserve wildlife -- pickle a squirrel today!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCCUvGgPq u395ykGsRApXAAJ 4yh+M42naJ9xzqD DxZpJ3zK/cnfgCdERyz
3HiV7iHkOzT+dbs oJ9715Jw=
=QZwp
-----END PGP SIGNATURE-----

[Mike Meyer]

Re: Big development in the GUI realm

"Gabriel B." <gabriel.barros @gmail.com> writes:
[color=blue][color=green][color=darkred]
>> >>Considering the fact that the Qt DLL exist by themselves, that the
>> >>version used is the one provided by Qt, and that the EXE uses a
>> >>standard, open way to communicate with it, the above does seem to say
>> >>this use would be valid.
>> >>
>> >>
>> >
>> > http://www.gnu.org/licenses/gpl-faq....ereAggregation
>> >
>> > "/.../ If modules are designed to run linked together in a shared address
>> > space, that almost surely means combining them into one program.
>> >
>> > By contrast, pipes, sockets and command-line arguments are
>> > communication mechanisms normally used between two separate
>> > programs. So when they are used for communication, the modules
>> > normally are separate programs. But if the semantics of the
>> > communication are intimate enough, exchanging complex internal
>> > data structures, that too could be a basis to consider the two parts
>> > as combined into a larger program."
>> >
>> ></F>[/color][/color]
>
> This is odd. They claim it's a GPL'ed version, but it's a trolltech
> license that forces you to release your code under gpl even tought
> their's not!
>
> I'm not against a company getting it's share with their product.
> that's what motivated them in the first place. but DONT LIE! don't
> call it gpl when it's not.
>
> Gpl make it very explicity it deals with the program as a whole, in
> the meaning of a executable code. What they're trying to achive here
> is that, by adding this paragraph, they will cover the "dll use" under
> the gpl.
>
> By that cover-all definition they came up, i can't use Internet
> Explorer to see a site hosted with a gpl'ed server! i can't even use a
> BSD program to grep a file![/color]

Now the latter isn't true, because the BSD license isn't viral.

On the other hand, you're conflating data and code. If that stands,
then you'd be only be allowed to distribute code written with GNU
Emacs under the GPL, which is goes against long-standing position of
the FSF on GNU Emacs.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[JanC]

Re: Big development in the GUI realm

Jeremy Bowers schreef:
[color=blue]
> Copyright-based models can't handle modern computer programs,[/color]

Most countries have computer program specific parts in their copyright
laws...

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Carlos Ribeiro]

Re: Big development in the GUI realm

On Tue, 8 Feb 2005 11:44:10 +0100, Alex Martelli <aleaxit@yahoo. com> wrote:[color=blue]
> Dennis Lee Bieber <wlfraed@ix.net com.com> wrote:
>[color=green]
> > hassle to code, but if your application could dynamically select from
> > whatever toolkit is available on the machine, you (and I should emphasis
> > that this is an impersonal/generic "you" I reference) might be able to
> > argue an exemption from the QT license.[/color]
>
> So maybe it's time to resurrect anygui, maybe in a simplified version
> which can only interface to, say, PyQt or Tkinter -- 'eithergui' maybe.[/color]

'onegui' to rule them all...

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro@gmai l.com
mail: carribeiro@yaho o.com

[Cappy2112]

Re: Big development in the GUI realm

Damjan wrote:[color=blue][color=green]
> > For all you GUI developers, things just got a little more[/color][/color]
interesting.[color=blue][color=green]
> > Trolltech will soon be offering the QT GUI toolkit for Windows[/color][/color]
under[color=blue][color=green]
> > the GPL license. That means that PyQt may become a much more[/color][/color]
popular[color=blue][color=green]
> > option in the near future.[/color]
>
> This applies to QT-4 only.
> I wonder how much of PyQT is ready for QT4?
>
> Anyway its time for a PyQT based VB-killer [ a GPL one :) ].[/color]

[color=blue]
> Anyway its time for a PyQT based VB-killer [ a GPL one :) ].[/color]
I aggree, and for now, it's Eric3, AND it can be compiled & run under
windows, without Cygwin.

Ok, it's not exactly a VB-Killer, but it's the closest thing for now.

VB has it's drawbacks, but can you image the how much more acceptance
python would get, if we had *more* a VB-like designer, for multiple GUI
toolkits, no less?