Thanks, Mike,
This "...may publish revised and/or new versions of the license from time to
time...."
looks suspicious and I will remove this statement completely.
So it will become just a BSD style license (I guess).

Andrew.


"Mike Capp" <mike.capp@gmail.com> wrote in message news:d5qr1q$1ih6$1@digitaldaemon.com...
> In article <d5qk06$1bhl$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>Thanks a lot, Mike,
>>
>>As I mentioned there, we can change
>>license in the future.
>
> Do bear in mind that changing license in the future may prove to be *far*
> more
> work than changing it now. For starters, you'd probably need to track down
> everybody who's contributed code to the project in the meantime and get
> their
> permission for the license change. And if you can't track them down, you
> have to
> identify, remove and reimplement all their contributions. The Mozilla guys
> had a
> hell of a time getting their NPL/MPL codebase relicensed to MPL/GPL/LGPL
> after
> the FSF declared NPL/MPL incompatible with the GPL. (Do I win the 2005
> 'most
> acronyms in one sentence' award?)
>
> cheers
> Mike
>
> 

For programs such as gprof, and gcc, you are correct... it doesn't really make that much of a difference.  The big problem is licensing on libraries.  If you use a non GPL compliant license (basically non OSI) then people writing a GPL application cannot use your library.  I don't know the specifics, but there are probably also issues with someone writing any program that uses your license along with a library that uses GPL- they probably wouldn't be allowed to do it.  In short, when one uses a license that's not on the OSI-approved list for a library, a whole host of potential problems emerge.  Plus, the list has so many licenses, there's probably one that's acceptable.

It is also worth noting that in D context (in Linux, at least) that there is no significant differences between the GPL and LGPL, since the LGPL just makes allowances for dynamically linked libraries.  On cannot dynamically link D libraries on Linux (to my knowledge.)

John Demme

On Tue, 2005-05-10 at 11:44 -0700, Andrew Fedoniouk wrote:
> One more question about following:
> 
> > In particular, the PHPv3 license you're using as a base is incompatible
> > with the
> > GPL:
> >
> > "It is a non-copyleft free software license which is incompatible with the
> > GNU
> > GPL. We recommend that you not use this license for anything except PHP
> > add-ons."
> 
> Why I (as anyone else) should stay with GPL?
> What it can give to community and to me pesrsonally "en principle"?
> Will Harmonia GPL license, if it will be applied, help spreading D and
> Harmonia
> in all developer communities or only in some particular?
> 
>  I am just wondering.... I did not have a chance to write GPL software
> before.
>  I am occasionally using gcc and gperf and
>  personally don't care what type of license they have.
>  So I *really* would like to know is GPL so worth it? May be I missed
> something
>  critical here?
> 
> Beg my pardon if my questions look naive.
> I've seen a lot of flames of holy wars about the subject so
> I just *realy* want to hear real arguments finally.
> 
> Andrew.
> 
> 
> 
> 
> 
> 
> 
> 

> ... writing any program that uses your license along with a library that uses GPL- they probably wouldn't be allowed to do it....

"wouldn't be allowed" - Why?
For some political reasons? I don't care about
such motivations in general.

And what about non-GPL software which is (my guess) is
95% or even more over there?

Again, I am not against GPL or against non-GPL.
I just don't care.
I do know that distribution of libraries of common use should be in open
source.
But Open Source is far not GPL as I was told....

Andrew.


"John Demme" <me@teqdruid.com> wrote in message news:1115752102.2831.6.camel@localhost.localdomain...
> For programs such as gprof, and gcc, you are correct... it doesn't really make that much of a difference.  The big problem is licensing on libraries.  If you use a non GPL compliant license (basically non OSI) then people writing a GPL application cannot use your library.  I don't know the specifics, but there are probably also issues with someone writing any program that uses your license along with a library that uses GPL- they probably wouldn't be allowed to do it.  In short, when one uses a license that's not on the OSI-approved list for a library, a whole host of potential problems emerge.  Plus, the list has so many licenses, there's probably one that's acceptable.
>
> It is also worth noting that in D context (in Linux, at least) that there is no significant differences between the GPL and LGPL, since the LGPL just makes allowances for dynamically linked libraries.  On cannot dynamically link D libraries on Linux (to my knowledge.)
>
> John Demme
>
> On Tue, 2005-05-10 at 11:44 -0700, Andrew Fedoniouk wrote:
>> One more question about following:
>>
>> > In particular, the PHPv3 license you're using as a base is incompatible
>> > with the
>> > GPL:
>> >
>> > "It is a non-copyleft free software license which is incompatible with
>> > the
>> > GNU
>> > GPL. We recommend that you not use this license for anything except PHP
>> > add-ons."
>>
>> Why I (as anyone else) should stay with GPL?
>> What it can give to community and to me pesrsonally "en principle"?
>> Will Harmonia GPL license, if it will be applied, help spreading D and
>> Harmonia
>> in all developer communities or only in some particular?
>>
>>  I am just wondering.... I did not have a chance to write GPL software
>> before.
>>  I am occasionally using gcc and gperf and
>>  personally don't care what type of license they have.
>>  So I *really* would like to know is GPL so worth it? May be I missed
>> something
>>  critical here?
>>
>> Beg my pardon if my questions look naive.
>> I've seen a lot of flames of holy wars about the subject so
>> I just *realy* want to hear real arguments finally.
>>
>> Andrew.
>>
>>
>>
>>
>>
>>
>>
>>
> 

In article <d5qve8$1li9$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>One more question about following:
>
>> In particular, the PHPv3 license you're using as a base is incompatible with the GPL:
>
>Why I (as anyone else) should stay with GPL?

I'm carefully not saying you should. It's your code, you can do whatever you like with it. That said, there are major benefits to a GPL-compatible license, which you might want to consider.

Note that's "GPL compatible", not necessarily the GPL itself. "Compatible" means that someone can create and distribute a program which links in both Harmonia and, for example, some GPLed 'C' library. (The whole thing is then covered by the GPL.) "Incompatible" means they can't. Therefore, GPL-compatibility would make Harmonia more attractive to developers, because it doesn't take away their ability to use any of the huge number of GPL libraries out there.

Huge number? Yup. Take a look at Sourceforge's breakdown of projects by license. (http://sourceforge.net/softwaremap/trove_list.php?form_cat=14) At #1 is the GPL with 43616 projects. At #2 is the LGPL ("Lesser" or "Library" GPL) with 7106. At #3 is the BSD license with 4545. The rest are down in the noise. (PHPv3 has 138.)

>What it can give to community and to me pesrsonally "en principle"?
[...]
> So I *really* would like to know is GPL so worth it? May be I missed
>something critical here?

Again, the big issue (aside from avoiding yet another hand-rolled license) is being *compatible* with the GPL, not necessarily *using* the GPL. As for (L)GPL versus BSD, it really comes down to a simple choice on your part: what are you trying to achieve?

If someone takes Harmonia under the GPL or LGPL licenses and improves it somehow, they have to release the source for those improvements back to you (and the rest of the world) under that same license. This is good if your goal is to get Harmonia improved as much as possible for everybody's benefit.

Under the GPL (but *not* the LGPL), they *also* have to release under GPL any source code which is linked to Harmonia. This is good if you believe that open source (or "Free Software") is a Good Thing and there should be more of it. It encourages people to make their own sofware open/Free because by doing so they can benefit from all the GPL code out there. However, it will put many commercial developers off, because they don't want to open up their own code.

(Note: contrary to what John Demme wrote, the GPL/LGPL distinction applies to all libraries, not just dynamic ones. In fact, dynamic linking is more of a grey area than static, because it can be deferred until runtime using dlopen/dlsym or LoadLibrary/GetProcAddress.)

The BSD license doesn't require any of the above; it really just says that anyone using your library has to acknowledge your copyright, and can't use your name for advertising etc without permission. However, anyone can take the code, modify it, and sell modified binaries without releasing the modified source. For obvious reasons, commercial folk love it; Microsoft has pulled many an "embrace and extend" on BSD-licensed code. (You may remember the Kerberos fiasco.) Therefore, this is good if you just want Harmonia to be used by as many people as possible and aren't too concerned about having improvements contributed back to the community.

If you do decide to go with one of the standard licenses, I would suggest that you call it what it is, rather than "The Harmonia License". Many developers won't take the time to read (or, worse, have a lawyer read) the license text to work out what it means, they'll just look for another library with a license they already understand. I'd suggest avoiding "tweaks" to the license for the same reason, however minor they may look.

>Beg my pardon if my questions look naive.

Not in the least.

I don't know how strict this forum is about threads drifting off topic, but if you want to follow up via email, that's fine.

cheers
Mike

Andrew Fedoniouk wrote:

>>... writing any program that uses your license along with a library that
>>uses GPL- they probably wouldn't be allowed to do it....
> 
> 
> "wouldn't be allowed" - Why?
> For some political reasons? I don't care about
> such motivations in general.

Supposedly you would be able to sue them and collect damages.  <shrug> Who knows?

> And what about non-GPL software which is (my guess) is
> 95% or even more over there?
> 
> Again, I am not against GPL or against non-GPL.
> I just don't care.
> I do know that distribution of libraries of common use should be in open source.
> But Open Source is far not GPL as I was told....

If you don't care, then I recommend public domain.  Neatly sidesteps all the politics and, as far as I know, has never resulted in an author's code being used in ways he doesn't approve of - and anyone who ever did do anything like stealing code and claiming it was his would be outed and ostracized for life (unless if it were a child, which it almost certainly would be).  It's a big bunch of hullaballoo about nothing if you ask me.

Getting back to the material portion of this thread, an example is a good gesture but I think you should devote your efforts to the documentation and ironing out any wrinkles in the interface.  And an SVN repository.  :)

On Tue, 2005-05-10 at 21:00 +0000, Mike Capp wrote:
> (Note: contrary to what John Demme wrote, the GPL/LGPL distinction applies to all libraries, not just dynamic ones. In fact, dynamic linking is more of a grey area than static, because it can be deferred until runtime using dlopen/dlsym or LoadLibrary/GetProcAddress.)

You're saying that if I create a static LGPL library, it can be linked into non-F/OSS libraries?  If so, then good... I though there was some issue in the wording that prevented that.

John Demme

In article <1115763427.2831.13.camel@localhost.localdomain>, John Demme says...
>
>You're saying that if I create a static LGPL library, it can be linked into non-F/OSS libraries?

Yes, you can, and no, you don't have to distribute the source of the non-F/OSS libs.

There's a "but", however. The wording of the license itself is a little hairy here; it's a lot easier to understand if you look at the INTENT. The intent of the LGPL is this:

Suppose Andrew releases the Harmonia library under the LGPL. You come along and create an app - let's say it's an IDE for D - which uses that library. It's closed-source, you're raking in cash for it, whatever. Fine. Now, suppose Andrew (or anyone else) buys your IDE at vast expense, and in the course of using it hits a bug in Harmonia which seriously reduces the app's usefulness to him. He fixes the bug and asks you to rebuild with the fixed library. You do so, and make the new build available... for the trifling "upgrade price" of $20,000.

This is what it's all about. This is exactly the sort of vendor behaviour that led Richard Stallman to create the Free Software movement in the first place.

The GPL says: if you use ANY of my code, you don't get to dictate terms like that. Period. The more limited LGPL says: if you use ANY of my code, you don't get to dictate terms ON THAT BIT OF CODE.

So how does this apply to the static/dynamic distinction? Go back to our hypothetical situation. Andrew must be able to fix the Harmonia bug in his IDE without being dependent on you. For a dynamic library, that's easy. Build a new dll/.so, drop it in, job done. For a static library, though, he has to build a new .lib and then relink the whole IDE app. To do that, you'd have to have distributed the object files - object, not source - which make up that app.

And this is exactly what the LGPL requires. If you static-link to an LGPLed lib, you have to distribute linkable object code for the rest of your app. If you dynamic-link, you don't. Same goal, just a different mechanism.

cheers
Mike

That clears it up a lot.  I realize that this was the intent, but how hairy is the wording (I've never spent a ton of time combing through the legalese)?  Hairy enough that one should be cautious using LGPL and static libs?

John Demme

On Tue, 2005-05-10 at 23:25 +0000, Mike Capp wrote:
> In article <1115763427.2831.13.camel@localhost.localdomain>, John Demme says...
> >
> >You're saying that if I create a static LGPL library, it can be linked into non-F/OSS libraries?
> 
> Yes, you can, and no, you don't have to distribute the source of the non-F/OSS libs.
> 
> There's a "but", however. The wording of the license itself is a little hairy here; it's a lot easier to understand if you look at the INTENT. The intent of the LGPL is this:
> 
> Suppose Andrew releases the Harmonia library under the LGPL. You come along and create an app - let's say it's an IDE for D - which uses that library. It's closed-source, you're raking in cash for it, whatever. Fine. Now, suppose Andrew (or anyone else) buys your IDE at vast expense, and in the course of using it hits a bug in Harmonia which seriously reduces the app's usefulness to him. He fixes the bug and asks you to rebuild with the fixed library. You do so, and make the new build available... for the trifling "upgrade price" of $20,000.
> 
> This is what it's all about. This is exactly the sort of vendor behaviour that led Richard Stallman to create the Free Software movement in the first place.
> 
> The GPL says: if you use ANY of my code, you don't get to dictate terms like that. Period. The more limited LGPL says: if you use ANY of my code, you don't get to dictate terms ON THAT BIT OF CODE.
> 
> So how does this apply to the static/dynamic distinction? Go back to our hypothetical situation. Andrew must be able to fix the Harmonia bug in his IDE without being dependent on you. For a dynamic library, that's easy. Build a new dll/.so, drop it in, job done. For a static library, though, he has to build a new .lib and then relink the whole IDE app. To do that, you'd have to have distributed the object files - object, not source - which make up that app.
> 
> And this is exactly what the LGPL requires. If you static-link to an LGPLed lib, you have to distribute linkable object code for the rest of your app. If you dynamic-link, you don't. Same goal, just a different mechanism.
> 
> cheers
> Mike
> 
> 

In article <1115771536.2831.25.camel@localhost.localdomain>, John Demme says...
>
>That clears it up a lot.  I realize that this was the intent, but how hairy is the wording (I've never spent a ton of time combing through the legalese)?  Hairy enough that one should be cautious using LGPL and static libs?

Well, that rather depends on your tolerance for hairiness. Read http://www.fsf.org/licensing/licenses/lgpl.html (particularly clause 6) and judge for yourself.

I don't think this aspect of the LGPL is controversial or ambiguous, so I don't think you need be "cautious" in this regard. There are ambiguous bits, but they're more in the area of runtime dynamic linking (and web services, and so on). It's just that the verbiage puts people off. And I think many people don't understand the GPL/LGPL distinction and believe (wrongly) that both licenses are equally "viral", which may put them off.

I suspect most people linking LGPL libs do so dynamically, just because it's less hassle that way. Distributing object code would be a pain.

cheers
Mike

Thanks a lot Mike for good and detail explanation.

At least I think I know pros and cons now.

Andrew.