Board index » delphi » Re: Problem with MPL

Re: Problem with MPL


2007-11-12 04:38:51 PM
delphi89
Marco van de Voort expressed precisely :
Quote
On 2007-11-09, Ryan J Mills <XXXX@XXXXX.COM>writes:
>The Problem with GPL is that you can not use GPL code in close source
>commercial software. That is where the MPL shines over the GPL, IMO.
>Ryan.

The LGPL is pretty much the same as MPL, but it _does_ play nice with the
GPL.

But for me these are just politics, I really don't care which one is better
or not. I just witness the Delphi/Pascal opened source being divided by this
sterile difference unnecessarily.

See also
wiki.freepascal.org/licensing

and then the Lazarus related paragraphs, to get a somewhat bigger treatise
of the problem.
Actually if I remember correctly LGPL does not allow static linking of
the code inside your own. When used on components specially Delphi
components which are build inside your exe and do not have a DLL like
activeX components you are not allowed to have a closed source
application.
I have taken a not so close look on GPL/LGPL a couple of years back and
since then I stay away from this licenses at all cost.
regards
Yannis.
 
 

Re: Problem with MPL

Marco van de Voort writes:
Quote
The only major problem could be the JVCL. Afaik JVCL is also a patchwork of
many contributors without explicit signing over the rights to some
foundation( which would allow the foundation to relicense), thus both
Lazarus and JVCL can not relicense. Which is a pity, since that seems to
exclude easy windows installers with JVCL components preinstalled.
Why would it prevent to have JVCL components preinstalled?
 

Re: Problem with MPL

Peter Morris formulated on ÄåõôÝñ?:
Quote
>What I am asking is to dual license to "LGPL with linking exception" that
>FPC
>uses.

So what does that mean exactly?

As I understand it S/He asks for the author to say that his code can be
used in two ways 1) MPL licensed and 2)LGPL with link Exception. The
choises remains to the end user to use what ever license suits him/her.
This imposes a problem though. What happens when a contributor that
uses LGPL license decides to contribute back some code (bug fix,
enhancement etc) will this piece of code be shared as dual licensed or
it should be shared only with the LGPL license? How hard it will be to
maintane a common code under this contition and how silly would be to
have different abilities from license to lincense.
regards
Yannis.
 

Re: Problem with MPL

none writes:
Quote
Rudy Velthuis [TeamB] writes:
>Fine. But is "linkable with GPL" really something that has such high
>value?

Yes.
Because these days, any major project is likely to be using a fair bit
of GPL material.
Hmmm... any major open source project, then. Closed source projects
can't.
--
Rudy Velthuis [TeamB]
"Sometimes, the best answer is a more interesting question"
-- Terry Pratchett
 

Re: Problem with MPL

none writes:
Quote
>Hey, use whatever you want. I just replied to the FSF recommending
>not to use MPL that one could just as well recommend not use GPL.
><g>

I take the FSF and Stallman's reccomendation more seriously
Your prerogative. I will keep on avoiding the GPL like the plague.
--
Rudy Velthuis [TeamB]
"Not only is there no God, but you try getting a plumber at
weekends." -- Woody Allen.
 

Re: Problem with MPL

Daniël Mantione writes:
Quote

"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>writes:
>Daniël Mantione writes:
>
>>Most code with a strong copyleft is GPL, apparently people
>>seem pretty happy with the GPL as a strong copyleft license,
>>and so am I, as the GPL does this rather well.
>
>Apparently people who chose the GPL are happy with the GPL.

That is not what I said. I said people who decide to use
strong copyleft tend to choose for the GPL, which shows that
it suits peoples needs well.
Oh, sure. But many people don't WANT strong copyleft. Closed source
projects will rather use MPL or similarly licensed sources.
--
Rudy Velthuis [TeamB]
"Men and nations behave wisely once they have exhausted all the
other alternatives." -- Abba Eban (1915-2002)
 

Re: Problem with MPL

none writes:
Quote
Rudy Velthuis [TeamB] writes:

>No doubt confusing. But I doubt a Californian court has any
>jurisdiction over non-residents.

Since the MPL explicity states that "disputes to be fought before a
Californian court" then you are stuffed.
Did you read it in its entirety?
--
Rudy Velthuis [TeamB]
"He is one of those people who would be enormously improved by
death." -- H. H. Munro (Saki) (1870-1916)
 

Re: Problem with MPL

"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>writes:
Quote
Daniël Mantione writes:

>
>"Rudy Velthuis [TeamB]" <XXXX@XXXXX.COM>writes:
>
>That is not what I said. I said people who decide to use
>strong copyleft tend to choose for the GPL, which shows that
>it suits peoples needs well.

Oh, sure. But many people don't WANT strong copyleft. Closed source
projects will rather use MPL or similarly licensed sources.
I know, but closed source projectswant to take, not give.
Nothing wrong with with closed source projects, but that is why
some people do WANT strong copyleft :)
Anyway, the fact that some people want and people don't want
weak or strong copyleft is old news and only distracts from the
actual discussion.
Daniël Mantione
 

Re: Problem with MPL

On 2007-11-11, Peter Morris <XXXX@XXXXX.COM>writes:
Quote
>So not pure LGPL, and linking with static libraries is perfectly
>allowed.

People would most likely want to compile the source code directly into their
applications. This wouldn't class as linking to a static library would it?
Yes it would class as such. A static library is roughly a set of .o's. Which
is equal the code part of a set of .dcu's.
So to say it explicitely again: It is perfectly legal to link parts of the
LGPL-with-exceptioned FPC RTL/FCL into your Delphi application.
I do so regularly even in my job.
(mostly to set up my Delphi projects shared source between FPC and Delphi)
And this license goes for every library the FPC+Lazarus projects has. And we
like to keep it that way, and not confuse it with a patchwork of libraries.
(but some parts are already duallicensed to MPL, like some Jedi projects)
The other parts (compiler itself, the IDE itself, a bunch of small tools
like doc tools, pretty printers etc) are under strict GPL. But in normal use
you don't link against them.
 

Re: Problem with MPL

On 2007-11-12, yannis <XXXX@XXXXX.COM>writes:
Quote
Peter Morris formulated on ÄåõôÝñ?:
>>What I am asking is to dual license to "LGPL with linking exception" that
>>FPC
>>uses.
>
>So what does that mean exactly?

As I understand it S/He asks for the author to say that his code can be
used in two ways 1) MPL licensed and 2)LGPL with link Exception. The
choises remains to the end user to use what ever license suits him/her.
Correct.
Quote
This imposes a problem though. What happens when a contributor that
uses LGPL license decides to contribute back some code (bug fix,
enhancement etc) will this piece of code be shared as dual licensed or
it should be shared only with the LGPL license?
We will reject the patch, and require it to be dual licensed too. We already
do this for the dual licensed Jedi projects (Math +SDL)
Quote
How hard it will be to maintane a common code under this contition and how
silly would be to have different abilities from license to lincense.
Peanuts. A small disclaimer that submitted patches are assumed to comply
with the license of the said package, and a polite request to contact
separately in the case of deviations (in which they are kept apart from the
normal, run of the mill patching).
This is not watertight, as no scheme that doesn't require a signed paper
isn't. But that is not a problem of the dual licensing.
(GNU requires wannabe developers to sign and mail such license btw, which
greatly hampers the smaller contributors)
 

Re: Problem with MPL

On 2007-11-12, OBones <XXXX@XXXXX.COM>writes:
Quote
Marco van de Voort writes:

>The only major problem could be the JVCL. Afaik JVCL is also a patchwork of
>many contributors without explicit signing over the rights to some
>foundation( which would allow the foundation to relicense), thus both
>Lazarus and JVCL can not relicense. Which is a pity, since that seems to
>exclude easy windows installers with JVCL components preinstalled.

Why would it prevent to have JVCL components preinstalled?
(assuming they are still MPL mono-licensed, main link: wiki.freepascal.org/licensing )
because that would constitute linking MPL code (Jedi designtime packages)
with a GPL codebase (Lazarus). Which is not allowed according to FSF.
However since the GPL only applies to distribution, it is not problem if the
user does it himself (the final link), since the user doesn't distribute the
result. (only the product made by it, which doesn't contain GPLed parts).
It's all messy, and it is a pity that AOL/Netscape decided to roll their own,
with LGPL-with-exception being there at least since the early nineties that
I know of. And that neither organisation (AOL/FSF) tried to resolve it.
However licensing is not our corebusiness, so we simply hope to avoid the
pitfalls a bit by these kinds of duallicensing requests.
 

Re: Problem with MPL

Rudy Velthuis [TeamB] writes:
Quote
>Not true. Try enforcing that clause in Europe. ;)

Exactly.
Why is it so hard for people to understand that contract claims are
subordinate to the laws of the jurisdition in which the contract is
concluded?
As an example, most EULAs disclaim warranties of merchantability and
fitness of purpose, though most American states do not permit those
warranties to be waived. So why include them? Because a) they're
boilerplate, and b) in the few states where they are effective, they
may save some money. But declaring them, and declaring California as
the state where disputes must be resolved, will not trump local laws.
If a company wishes to avoid the laws of a particular jurisdiction,
they have one remedy only: don't sell the product there.
--
Bill
 

Re: Problem with MPL

On 2007-11-12, Rudy Velthuis [TeamB] <XXXX@XXXXX.COM>writes:
Quote
>>>Most code with a strong copyleft is GPL, apparently people
>>>seem pretty happy with the GPL as a strong copyleft license,
>>>and so am I, as the GPL does this rather well.
>>
>>Apparently people who chose the GPL are happy with the GPL.
>
>That is not what I said. I said people who decide to use
>strong copyleft tend to choose for the GPL, which shows that
>it suits peoples needs well.

Oh, sure. But many people don't WANT strong copyleft.
Well, in our case there was maybe some cause to want this; with an US
multinational breathing down our neck, having the FSF to back you up legally
if necessary is some form of safety net.
Also the point that Daniel made about the Californian court is not to be
underestimated. It is nearly impossible to insure yourself against US legal
costs in Europe. You'd be bankrupt before trial, even if you were right.
 

Re: Problem with MPL

On 2007-11-12, Rudy Velthuis [TeamB] <XXXX@XXXXX.COM>writes:
Quote
I'll keep on avoiding the GPL like the plague.
I do too for libraries and programming, except if they are part of *nix userland (1).
The only exception if I just want to contribute some unrelated code back.
(1) exception in the GPL, if a GPL package comes with the OS, the viral
clause doesn't apply.
 

Re: Problem with MPL

On 2007-11-12, yannis <XXXX@XXXXX.COM>writes:
Quote
>>commercial software. That is where the MPL shines over the GPL, IMO.
>>Ryan.
>
>The LGPL is pretty much the same as MPL, but it _does_ play nice with the
>GPL.
>
>But for me these are just politics, I really don't care which one is better
>or not. I just witness the Delphi/Pascal opened source being divided by this
>sterile difference unnecessarily.
>
>See also
>wiki.freepascal.org/licensing
>
>and then the Lazarus related paragraphs, to get a somewhat bigger treatise
>of the problem.

Actually if I remember correctly LGPL does not allow static linking of
the code inside your own. When used on components specially Delphi
components which are build inside your exe and do not have a DLL like
activeX components you are not allowed to have a closed source
application.

I have taken a not so close look on GPL/LGPL a couple of years back and
since then I stay away from this licenses at all cost.
You are right. It was worded too quickly and caused confusion. Substitute
LGPL_with_exception (what we actually use) for LGPL in the above text.