Amazing GUI toolkit with visual designer & Ruby Integration

J

Jim Weirich

H. Simpson said:
QUOTE FROM LGPL:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

MY TRANSLATION: If you statically link to LGPL library, then your
application is considered a "derivative of the Library" rather than a
"work that uses the library".

Correct. And section 6 of the LGPL covers distributing such a work.
One of your options is to provide the source and object code of the
library (only the library) and the object code of your proprietary work
(LGPL: 'with the complete machine-readable "work that uses the Library",
as object code and/or source code').

Source code is not required for your proprietary code (only
modifications to the library itself require source). The intent is that
the end user may modify the library (which is open source after all) and
relink your application with it. Now providing your proprietary code in
an object linkable format may still be objectionable to you, but the
LGPL never makes you provide the source to your own code[1].

--
-- Jim Weirich (e-mail address removed) http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

[1] Well, ok, I guess that statement assumes that there is a non-source
linkable version of the code.
 
H

H. Simpson

Lyle said:
FOX's license absolutely does *not* require you don't have to give
away the source code to your commercial application(s) that link to it
(statically or otherwise). I know for a fact that this was not
Jeroen's intent. To help clear things up, could you point me to the
part(s) of FOX's license that led you to believe this was the case?

Lyle, thanks for clarifying.

From SECTION 6 of LGPL which applies to any application that is
statically linked to a modified version of the Fox-Toolkit:

"[...] and distribute that work under terms of your choice, provided
that the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications."

The terms of the LGPL does not allow software that are derivatives of
LGPL libraries to prohibit reverse engineering.

Selling software usually means licensing it. And the terms of the
license almost always explicitely prohibit reverse engineering. There
have been landmark court cases where that particular clause about
reverse engineering was very crucial in the outcome of disputes between
companies.

To me, if I cannot lawfully prohibit customers from reverse-engineering
my product in my license agreement or terms of sale, it is practically
the same as giving them my source code. I don't mind giving away the
source code on my hobby projects but I cannot do so on commercial
products that I depend on to pay my family's rent and food. With
programming jobs being shipped overseas and so-called "free trade"
agreements designed to provide *access to cheaper labor* (rather than
"opening overseas markets to USA" as advertised to the misinformed
public), we simply don't have the luxury to share as much as we'd like
under different circumstances.

Further, there is no way I wish to be bound by the remaining portions of
LGPL Section 6(a, b, c, d, or e) when there is an alternative product
that not only frees me from ANY such obligations on my app, but makes me
more productive, have more fun coding AND produces a smaller executable
to boot.
 
H

H. Simpson

Jim said:
H. Simpson said:
QUOTE FROM LGPL:

"However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

MY TRANSLATION: If you statically link to LGPL library, then your
application is considered a "derivative of the Library" rather than a
"work that uses the library".


Correct. And section 6 of the LGPL covers distributing such a work. One
of your options is to provide the source and object code of the library
(only the library) and the object code of your proprietary work (LGPL:
'with the complete machine-readable "work that uses the Library", as
object code and/or source code').

Source code is not required for your proprietary code (only
modifications to the library itself require source). The intent is that
the end user may modify the library (which is open source after all) and
relink your application with it. Now providing your proprietary code in
an object linkable format may still be objectionable to you, but the
LGPL never makes you provide the source to your own code[1].

Section 6 clearly states you have to give permission for reverse
engineering your work. This is not acceptable in most commercial
software products that rely on that restriction within the licensing
terms to help protect intellectual property such as trade secrets--look
at the landmark lawsuits that heavily relied on the "you may not
reverse-engineer" restriction within the licensing agreements.

You also left out a very important part of Section 6a which states:

"so that the user can modify the Library and then relink to produce
a modified executable containing the modified Library."

The complete LGPL Section 6a states:

"a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)"

So if you statically link to a modified version of Fox-Toolkit, then you
have to give users permission to reverse engineer your application AND
also comply with the terms in LGPL Section 6 (such as 6a quoted above).
Simply not an option for me except on hobby projects. Others might
not care.
 
S

Sander Jansen

QUOTE FROM FLTK LICENSE
"3. Static linking of applications and widgets to the FLTK library
does not constitute a derivative work and does not require the author to
provide source code for the application or widget, use the shared FLTK
libraries, or link their applications or widgets against a user-supplied
version of FLTK.

If you link the application or widget to a modified version of FLTK,
then the changes to FLTK must be provided under the terms of the LGPL in
sections 1, 2, and 4."

MY TRANSLATION: The first paragraph (3) makes apps statically linked to
FLTK exempt from the license. Then the second paragraph states that if
we link to a modified version of FLTK, the "changes to FLTK" must be
provided under the terms of the license. Therefore, the application is
still exempt from the license when linked statically to a modified FLTK
because nothing stated takes the exemption away.

Uhhh I disagree.

The first paragraph is talking about linking to the FLTK library statically.
The second paragraph is talking about statically linking to a MODIFIED fltk
librarry (a work based on the library. which should fall under LGPL, sections
1, 2 & 4.) Basically FOX and FLTK are probably saying the same things.

Anyway, I don't want to make this an issue and I really don't care what you do
with FLTK, but a smart thing to do, is just mail the FLTK guys if this is
what they intended with the license.

Good Luck,

Sander
 
H

H. Simpson

Sander said:
Uhhh I disagree.

The first paragraph is talking about linking to the FLTK library statically.
The second paragraph is talking about statically linking to a MODIFIED fltk
librarry (a work based on the library. which should fall under LGPL, sections
1, 2 & 4.) Basically FOX and FLTK are probably saying the same things.

Anyway, I don't want to make this an issue and I really don't care what you do
with FLTK, but a smart thing to do, is just mail the FLTK guys if this is
what they intended with the license.

Good Luck,

Sander

IMHO, Fox-Toolkit and FLTK are very clearly not saying the same things.

Fox-Toolkit specifically and clearly identifies the exemption for
"UNMODIFIED FOX-TOOLKIT". The use of the word "UNMODIFIED" makes it
clear the exemption does not apply to modified Fox-Toolkit.

To make this even clearer, the author of Fox-Toolkit goes on to explain:

"Static linking with a modified copy of the Library, however, would
deny the community the benefit of these modifications, as these
modifications would now be locked up inside a closed binary executable,
so therefore we must insist on the original GNU Lesser General Public
License when the Library has been modified."

On the other hand, FLTK identifies the exemption for "FLTK" without
qualifying adjective such as the word "UNMODIFIED". They clearly state
exactly *WHAT* must fall under the license when the app is statically
linked to a modified FLTK in the following sentence:

"If you link the application or widget to a modified version of FLTK
then the changes to FLTK must be provided under the terms of the LGPL in
sections 1, 2, and 4."

The phrase "changes to FLTK" is used to identify what must be provided
under the terms of the LGPL in cases where "application or widget" is
statically linked to FLTK. Since they used the term "application or
widget" in the same sentence, it is very clear the application itself
doesn't fall under the description of "changes to FLTK".
 
D

David Ross

The terms of the LGPL does not allow software that
are derivatives of
LGPL libraries to prohibit reverse engineering.

One of the main reasons I don't use GPL/LGPL toolkits
anymore. I like my anti-debugging/disassembler code in
my applications. People are 1) blind and dont think
about this or 2) don't care for software piracy. One
of the better ways in getting piracy reports is making
"ET phone home" to servers :)
To me, if I cannot lawfully prohibit customers from
reverse-engineering
my product in my license agreement or terms of sale,
it is practically
the same as giving them my source code. I don't
mind giving away the
source code on my hobby projects but I cannot do so
on commercial
products that I depend on to pay my family's rent
and food. With
programming jobs being shipped overseas and
so-called "free trade"
agreements designed to provide *access to cheaper
labor* (rather than
"opening overseas markets to USA" as advertised to
the misinformed
public), we simply don't have the luxury to share as
much as we'd like
under different circumstances.

Its like the LGPL welcomes program cracking. It is
very easy to do if you know assembly. A bit difficult
if there is a generator for a registration box though.
This point is very good. Software piracy is a big
issue. So.. /me *hugs* BSD/MIT/PD licensed libraries.


--David Ross



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
 
H

H. Simpson

David said:
One of the main reasons I don't use GPL/LGPL toolkits
anymore. I like my anti-debugging/disassembler code in
my applications. People are 1) blind and dont think
about this or 2) don't care for software piracy. One
of the better ways in getting piracy reports is making
"ET phone home" to servers :)




Its like the LGPL welcomes program cracking. It is
very easy to do if you know assembly. A bit difficult
if there is a generator for a registration box though.
This point is very good. Software piracy is a big
issue. So.. /me *hugs* BSD/MIT/PD licensed libraries.


--David Ross



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Reverse-engineering is only one aspect. LGPL forces us to ALLOW
MODIFICATIONS to our program by users.

Imagine selling a version of software limited to 2 CPUs to a bank. And
then the bank modifies your software to run on 32 CPU servers.

Or selling a standard edition of your product at a huge discount and
then having customers modify it to work just like the professional or
enterprise versions.

Soo....statically link your commercial app to Fox-Toolkit and you're
required to allow reverse engineering of your app and allow users to
modify your app (per Section 6 of LGPL).
 
D

David Ross

Reverse-engineering is only one aspect. LGPL forces
us to ALLOW
MODIFICATIONS to our program by users.

Imagine selling a version of software limited to 2
CPUs to a bank. And
then the bank modifies your software to run on 32
CPU servers.

This is why I will never ever use LGPL in commercial
non-open software that I care about.
Or selling a standard edition of your product at a
huge discount and
then having customers modify it to work just like
the professional or
enterprise versions.

Yep, there are tons of great assembly coders who can
easily do this(*despite how much assembly code there
is to write).
Soo....statically link your commercial app to
Fox-Toolkit and you're
required to allow reverse engineering of your app
and allow users to
modify your app (per Section 6 of LGPL).

Yes, you might as well have it opensource :)

This was the intention of the LGPL. It is so
commercial application are still considered "free to
public" for making any modifications.

--David Ross



_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
 
D

David Naseby

-----Original Message-----
From: H. Simpson [mailto:[email protected]]
Reverse-engineering is only one aspect. LGPL forces us to ALLOW
MODIFICATIONS to our program by users.

Imagine selling a version of software limited to 2 CPUs to a bank. And
then the bank modifies your software to run on 32 CPU servers.

Imagine the bank asking for support afterwards. I don't really see you
supporting a "rogue" version of an app, therefore they strand themselves,
alone and adrift. So I don't see that happening at all.
Or selling a standard edition of your product at a huge discount and
then having customers modify it to work just like the professional or
enterprise versions.

If they can modify it this far, they probably didn't need to buy it. Most
customers don't have the tech skills. And again, they cut off any chance of
ever receiving support. If they do all this, they are then stuck when you
release an update, as they have to integrate it all. Generally, its too big
a problem to even imagine starting down that path.
Soo....statically link your commercial app to Fox-Toolkit and you're
required to allow reverse engineering of your app and allow users to
modify your app (per Section 6 of LGPL).

...And thereby, sign the software project death warrant themselves. Of
course, this is just a hypothetical, and it should be your choice, and I
don't want to argue your needs and experiences versus my own, because its
fruitless. But I'm just stating that my straw man can kick your straw man's
butt ;)

David
http://homepages.ihug.com.au/~naseby/
 
G

Gennady

Now, guys, that you found each other you can take your discussion of
scary hacker stories off list ;-)

Gennady.
 
D

David Ross

Dicussions from GUI Threads include
"why not to use (L)GPL software unless specific
exceptions"

1. Must release *object* code in statically linked
applications
2. statically - You are forced to say your application
was made with the specified library
3. You *must* allow reverse engineering and
modifications to the code
4. *must* have any modifications you made to the
library open


--------------------------------------------------------
Did I miss anything?

--David Ross




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
 
D

David Ross

If they can modify it this far, they probably didn't
need to buy it. Most
customers don't have the tech skills. And again,
they cut off any chance of
ever receiving support. If they do all this, they
are then stuck when you
release an update, as they have to integrate it all.
Generally, its too big
a problem to even imagine starting down that path.

Umm, no. You misunderstand the assembly code, its a
simple test one liner using cmp. Maybe 2 lines. It
really isn't that big of a deal to modify. You should
go learn how to code assembly for 1) fun, or 2) PIC,
or Atmel programming :)


...And thereby, sign the software project death
warrant themselves. Of
course, this is just a hypothetical, and it should
be your choice, and I
don't want to argue your needs and experiences
versus my own, because its
fruitless. But I'm just stating that my straw man
can kick your straw man's
butt ;)

Generally the restrictions of reverse engineering are
for a good cause. If you have a really good and fast
library like the OptimaNumerics. You certainly don't
want people reversing the code. Its unhealthy and
unethical, but then again.. Pirates don't have rules
or ethics, which is why there are nice people who
throw them in jail and sue them for everything they've
got. :)

And to the misconception of client software being more
secure closed source. No, its not. Most VXers don't
need source code to exploit programs like Outlook
express. They just read the assembly code, a good
assembly coder recognizes flaws.

btw, for those who don't know what a VXer is..
a VXer, a "coder". For the lay person, a VXer codes
(writes) virii

--David Ross



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
 
L

Lyle Johnson

Lyle, thanks for clarifying.

From SECTION 6 of LGPL which applies to any application that is
statically linked to a modified version of the Fox-Toolkit:

"[...] and distribute that work under terms of your choice, provided
that the terms permit modification of the work for the customer's own
use and reverse engineering for debugging such modifications."

The terms of the LGPL does not allow software that are derivatives of
LGPL libraries to prohibit reverse engineering.
True.

Selling software usually means licensing it...

<snip>

OK, and these are perfectly reasonable objections on your part. The
only reason I expended all of this effort was a previous statement
(many posts past now) in which you said, "I don't mind giving away
changes I make to Fox-Toolkit but being required to give away the
commercial application source that statically links to a modified
Fox-Toolkit is something that bars me from using it."

As I and others have noted, statically linking a commercial
application to an LGPL'd library does *not* require you to give away
the source code for that commercial application. You are, however,
absolutely correct to note (in your follow-up posts) that the LGPL
does require some degree of reverse-engineering which may be
unacceptable.

Thanks for letting me clarify my position (and for expanding on
yours). Best of luck with your project(s).
 
H

Hal Fulton

Paul said:
I think that's called Cyrillic. It's probably closer to Greek than it
is to Tengwar.

Oh, those Russian elves... yes, Cyrillic was invented by Christian monks
(principally Cyril) who knew Greek.

Hal
 
B

Ben Giddings

H. Simpson, please calm down. Take a few deep breaths. Think before
posting. Don't use personal attacks. Your email was inflammatory and
rude. It was also proposing a pretty improbable scenario. If someone
spent their life savings building an application, I would hope they
wouldn't use some random comments from some internet user as a
substitute for legal advice.

Having said that, Lothar is incorrect.

The GPL and LGPL require you to do much more than place a diff file on a
website. I read through the LGPL, and I won't pretend to understand
exactly what it requires, but here are some relevant sections:

"4. You may copy and distribute the Library (or a portion or derivative
of it, under Section 2) in object code or executable form under the
terms of Sections 1 and 2 above provided that you accompany it with the
complete corresponding machine-readable source code, which must be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange.

"If distribution of object code is made by offering access to copy from
a designated place, then offering equivalent access to copy the source
code from the same place satisfies the requirement to distribute the
source code, even though third parties are not compelled to copy the
source along with the object code."

In other words, you have to supply more than just diff output, you have
to supply the entire source code.

It also mentions:

"For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception, the
materials to be distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

I'm pretty sure that the intention of the GPL and LGPL is that the part
of the code for which that license applies has to be distributed in the
same form you receive it. If you receive it as a "configure" script, a
bunch of Makefiles, and some .c and .h files, that's how you have to
provide it.

But from reading the rest of the LGPL, it looks as though if you
dynamically link to an LGPLed library, you are required to provide
notice that you do so, and provide a source code distribution for the
library. The application itself can be distributed under any terms that
don't violate the LGPL for the library part. Statically linking is a
different matter entirely.

But, like I said, I don't fully understand the LGPL or the GPL and would
suggest that anybody who is thinking of using them and wants to avoid
redistribution of their source code under the same license should be
careful and probably consult a lawyer.

Ben
 
L

Lothar Scholz

Hello Ben,


BG> Having said that, Lothar is incorrect.

Yes. I was wrong.

BG> The GPL and LGPL require you to do much more than place a diff file on a
BG> website. I read through the LGPL, and I won't pretend to understand
BG> exactly what it requires, but here are some relevant sections:

Okay, lets talk about dynamically linked libraries. Static ones seems
to have a huge problem.

With this i think i could supply only the diff, the original tgz file
and put a paragraph like this on the website.

--------------------
If you want to use your own FOX library with this program you can substitute the
delivered "fox.so" by downloading the files "patch.diff" and
"fox-1.1.51.tgz" (or your compatible one) from my website and then build
it with the following command line:

tar -xzf fox-1.1.52.tgz ; patch "patch.diff" "fox-1.1.51" ; cd fox-1.1.52; .configure ; make

Replace "fox.so" in the program directory with the freshly build
".lib/fox.so" file.
--------------------

And then i put a small comment to all the other things i tell my user
in the About box.

Is this okay ?

... snip ......

BG> "For an executable, the required form of the "work that uses the
BG> Library" must include any data and utility programs needed for
BG> reproducing the executable from it. However, as a special exception, the
BG> materials to be distributed need not include anything that is normally
BG> distributed (in either source or binary form) with the major components
BG> (compiler, kernel, and so on) of the operating system on which the
BG> executable runs, unless that component itself accompanies the executable."

This could be a show stopper for LGPL libraries, especially on windows.

How can i include a commercial compiler like MSVC (it's free for
download but you can't distribute it on you own website) into my
modified library ?
There are LGPL'ed Delphi libraries available, how can they confirm
with the license.

Can i now sue Jeroen as a revenge because he don't give away
micrsosofts c compiler ? I mean version 1.1 of FOX is of course a
modified version of 1.0.

What happened when in 4 years someone want to compile the program and
the compiler evolved backward incompatible ?

BG> But, like I said, I don't fully understand the LGPL or the GPL and would
BG> suggest that anybody who is thinking of using them and wants to avoid
BG> redistribution of their source code under the same license should be
BG> careful and probably consult a lawyer.

Right i wish that more people would offer there libraries under a BSD
license. I guess that most people would stop using LGPL libraries if
they knew all the problems that can raise from the simple use.
But as far as i know no court in the world had ever accepted the LGPL,
there are only a few cases for the GPL and this license seems to be
compatible with the current law (at least in the USA and in Germany).

Reading only a few sections of the LGPL then i think that it is just
an invalid license.
 
R

Rando Christensen

Lothar said:
BG> "For an executable, the required form of the "work that uses the
BG> Library" must include any data and utility programs needed for
BG> reproducing the executable from it. However, as a special exception, the
BG> materials to be distributed need not include anything that is normally
BG> distributed (in either source or binary form) with the major components
BG> (compiler, kernel, and so on) of the operating system on which the
BG> executable runs, unless that component itself accompanies the executable."

This could be a show stopper for LGPL libraries, especially on windows.

How can i include a commercial compiler like MSVC (it's free for
download but you can't distribute it on you own website) into my
modified library ?
There are LGPL'ed Delphi libraries available, how can they confirm
with the license.

You read that wrong. It says that you do NOT need to include anything
that is normally distributed with the compiler, kernel, etc, of an
operating system.
 
B

Ben Giddings

Lothar said:
With this i think i could supply only the diff, the original tgz file
and put a paragraph like this on the website.

--------------------
If you want to use your own FOX library with this program you can substitute the
delivered "fox.so" by downloading the files "patch.diff" and
"fox-1.1.51.tgz" (or your compatible one) from my website and then build
it with the following command line:

tar -xzf fox-1.1.52.tgz ; patch "patch.diff" "fox-1.1.51" ; cd fox-1.1.52; .configure ; make

Replace "fox.so" in the program directory with the freshly build
".lib/fox.so" file.
--------------------

And then i put a small comment to all the other things i tell my user
in the About box.

Is this okay ?

I think that's ok, but like I said, I don't fully understand the
license. I don't think you could get away with linking to
fox-1.1.51.tgz on another website. I think the intent of the LGPL is to
ensure that if you're using an LGPLed library, other people can build it
too. If somehow the original fox-1.1.51.tgz got moved or removed, you
would still have a full and complete distribution on your site.
BG> "For an executable, the required form of the "work that uses the
BG> Library" must include any data and utility programs needed for
BG> reproducing the executable from it. However, as a special exception, the
BG> materials to be distributed need not include anything that is normally
BG> distributed (in either source or binary form) with the major components
BG> (compiler, kernel, and so on) of the operating system on which the
BG> executable runs, unless that component itself accompanies the executable."

This could be a show stopper for LGPL libraries, especially on windows.

How can i include a commercial compiler like MSVC (it's free for
download but you can't distribute it on you own website) into my
modified library ?
There are LGPL'ed Delphi libraries available, how can they confirm
with the license.

As someone else posted, I think that paragraph says that you don't need
to include components that are normally distributed with the compiler or
kernel of the operating system on which the executable runs.

In other words, in your example above, you use "patch", but since
"patch" is normally provided with a development environment, you don't
need to provide it. If, on the other hand, you used some very
specialized tool that doesn't normally come with the compiler (say a
custom C preprocessor) then you may need to redistribute it.
What happened when in 4 years someone want to compile the program and
the compiler evolved backward incompatible ?

I don't think that's your problem to solve. If the original tarball you
modified wouldn't work with the new compiler, it's not up to you to make
it work. If you happen to know that there are specific dependencies in
your modifications so they only work with one compiler, you might need
to document that.
Right i wish that more people would offer there libraries under a BSD
license. I guess that most people would stop using LGPL libraries if
they knew all the problems that can raise from the simple use.
But as far as i know no court in the world had ever accepted the LGPL,
there are only a few cases for the GPL and this license seems to be
compatible with the current law (at least in the USA and in Germany).

Reading only a few sections of the LGPL then i think that it is just
an invalid license.

There's a fundamental difference in the BSD and LGPL licenses. The BSD
license is as close as you can say to "Here's something I created, do
what you want with it, just don't blame me if it's broken." The GPL is
fundamentally different. It says "Here's something I created. Do what
you want with it, but don't try to use it in a selfish way. If you make
fixes or add features, share them! Oh, and don't blame me if it's broken".

I think the BSD license is fundamentally more generous. If someone
wants to be completely selfish, they're free to do so. If they want to
share their fixes, they can do that as well. It's obvious why
commercial developers prefer to use BSD licensed code. They have very
few obligations when they use it. They can basically be as unscrupulous
as they want with it.

The GPL is an extension of political beliefs. The people behind it
think the world would be a better place if information were shared
freely. They don't mind anybody in the world sharing the fruits of
their labour. They just want to make sure that if you benefit from
their hard work, that they benefit from your hard work as well. They
want to make sure the exchange is a 2-way one, where you can't take
something without giving back.

With my stuff, the license I would use would depend on what it was I had
made. If it was some nifty little tool that was generally useful and
not terribly complex, I'd be happy to use a BSD like license, to make
sure that as many people as possible could benefit. On the other hand,
if I spent a really long time on something, pouring hours of work into
it, and decided to give it away, I'd want to make sure that someone
couldn't turn around and refuse to share. I'd want to make sure that if
someone created some product that was 95% my work and 5% their work,
they couldn't reap 100% of the rewards. In that case, I'd consider the GPL.

What is it that makes you think the LGPL is invalid? Are there
contradictory terms in the license?

The thing to remember about the LGPL and GPL is that they each mention
one thing: "You don't have to accept these terms, but nothing else gives
you the right to modify and redistribute this software". Really, I
think the GPL and LGPL are great. They give you the option of using all
kinds of software that otherwise might not exist. Sure, sometimes it's
annoying because if you want to make use of the software, you all of a
sudden have to follow all kinds of rules, but if that outweighs the
usefulness of the software, there's nothing forcing you to use it.

Ben
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top