Hi,

I am no expert in all the different licenses available, but would like to understand them better. I understand the difference between GPL and LGPL, but at first glance the LGPL and the BSD licenses seem to do the same. The end-user may change the code and use it in free or commercial apps.

What is the major differences between the BSD and LGPL?

Regards,
Graeme.

Graeme Geldenhuys wrote

What is the major differences between the BSD and LGPL?

The main difference is that if you ship an application linked with an LGPL'd library,

a) you must provide the sources of this library if the end user asks for them
b) the end user must be able to relink with other version of the library (as far as API compatibility allows, of course, you're not required to keep your program compatible with all versions of that library out there now and in the future). This means that you have to either provide the source of your program, link dynamically to the library (most common case), or in case of static linking make all compiled object files of your application available.

Jonas

Op Fri, 4 Aug 2006, schreef Graeme Geldenhuys:

With LGPL, the LGPL part of the software remains free software, i.e. its source code needs to be distributed or made available on request. Of course, with BSD the source code usually remains available on the net as well.

The most practical difference is when you have modified the code, with LGPL this means the source code on the net is no longer the source code of the program you distribute, so if somebody requests the code you will have to make your changes public.

With BSD, no requirements exist, so you can keep your changes private.

Daniël

Graeme Geldenhuys wrote

What is the major differences between the BSD and LGPL?

I forgot to mention the BSD license: the BSD license basically doesn't require anything but giving credit to authors of the code you use (which the LGPL also requires).

Jonas

Thanks to everybody for the quick replies.

The point below relates to a library created in each license.

So to recap LGPL:
* The LGPL allows you to create a library, which you can use in a commercial app or a free app.
* If you statically link to that library (compile in into your executable), the whole application source must be available on request, even commercial apps. (this will be a major issue for me!)
* Any changes made to the library must be available on request.

To recap BSD:
* You can use the library in commercial and free apps.
* You can link statically or dynamically to the library without releasing your commercial code.
* You do not need to release any code changes made to the library.

Regarding the credits to authors. Wasn't there a change in the BSD license (revision 2 or something) where giving credit is not required anymore. Example you can create a commercial app (Mac OS 10 comes to mind) and don't need to mention any credits in you app.

Regards,
Graeme.

The shared<->static linking is still an unclear point of the LGPL, i.e. if there is really a difference. This is why FPC and Lazarus explicitly state that static linking of the unmodified rtl/fcl/lcl is allowed.

No, it does not have to be available. As I said:

> This means that you have to > either provide the source of your program, link dynamically to the > library (most common case), or in case of static linking make all > compiled object files of your application available.

Note the "either". Only the full source of the library must be made available on request.

* Any changes made to the library must be available on request.

This is implicit because of the fact that the source of the library must be available on request. Note that you are only obliged to provide these library sources to people who have legitimate access to the application in question, i.e. those who bought it or otherwise obtained a valid license from you to use the application (although you are free to make them publicly available to everyone, of course).

Correct.

Regarding the credits to authors. Wasn't there a change in the BSD license (revision 2 or something) where giving credit is not required anymore. Example you can create a commercial app (Mac OS 10 comes to mind) and don't need to mention any credits in you app.

There is a document /Library/Documentation/Acknowledgements.rtf which credits every single bit of open source code used in Mac OS X.

The Modified BSD license can be found at (see in particular point 2). http://www.opensource.org/licenses/bsd-license.php

What was left out was the "advertising clause", which said:

" * 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by the University of
* California, Berkeley and its contributors."

You still have to credit people whose source you use in your source code and documentation.

Jonas

Jonas Maebe wrote

There is a document /Library/Documentation/Acknowledgements.rtf which credits every single bit of open source code used in Mac OS X.

In fact, they go beyond what is required, since they even credit authors of public domain code. E.g.:

Doug Lea ( dlmalloc )
This is a version (aka dlmalloc) of malloc/free/realloc written by Doug Lea and released to the public domain. Use, modify, and redistribute this code without permission or acknowledgement in any way you wish. Send questions, comments, complaints, performance data, etc to

Jonas

Ok I see... So in terms of working with the FPC, does "object files" refer to ALL the *.ppu and *.o files relating to a commercial apps linked statically to the library? The library I am creating is meant to be compiled into your single executable application file, not as a separate .so or .dll file.

The Modified BSD license can be found at (see in particular point 2). http://www.opensource.org/licenses/bsd-license.php What was left out was the "advertising clause", which said:

That is what it was, the "advertising clause"! I have no problem mentioning credits in the source or a file shipped with the application.

Regards,
- Graeme -

No, it would only be the .o files (the linker doesn't need .ppu files). But keep in mind that both the FPC RTL and the LCL come with a modified LGPL license, which says that this is not necessary. The modification means that you only have to make available the modifications you did to the RTL/LCL source, and not make available all object files of your application for relinking.

Of course, if you also statically link against another LGPL'd library, this exception is moot.

The library I am creating is meant to be compiled into your single executable application file, not as a separate .so or .dll file.

I'm not sure I understand this. Technically, both are possible in principle.

Jonas

The BSD license is starting to sound like a much easier license than the LGPL, as long as you are not interested in changes made to the library by others.

I guess it is fair if you think of it as follows. If a company invests a $1mil per year to improve a library for commercial use (think along the lines of Qt here), if it was LGPL'ed, they had to give all that work away which doesn't make financial sense. But if it was BSD based, they could decide what they wanted to release back to the community in good faith (think Mac OS X here).

I'm not sure I understand this. Technically, both are possible in principle.

I know both are possible, I just prefer to use it as part of the executable and not a separate shared library. Makes for easier deployment and guarantees the application will run (no matter if I changed the API for a new version). Personal preference I guess, but this is why I wanted to know about the static linking with the different licenses.

Regards,
- Graeme -

Op Fri, 4 Aug 2006, schreef Graeme Geldenhuys:

QT is GPL. If want to develop non-GPL software with it, you need to pay a lot of money.

But if it was BSD based, they could decide what they wanted to release back to the community in good faith (think Mac OS X here).

Yes, but if a company that invests 1 mil EUR in software, uses FPC, and needs to improve something in the RTL, the LGPL guarantees those changes will be contibuted back.

This happens in practise as well, the Wine project switched from BSD to GPL, after which the amount of contributed code greatly increased.

It is unlikely someone would invest 1 mil in the RTL, even if it were BSD.

Daniël

Graeme Geldenhuys wrote

The BSD license is starting to sound like a much easier license than the LGPL, as long as you are not interested in changes made to the library by others.

That's correct.

I guess it is fair if you think of it as follows. If a company invests a $1mil per year to improve a library for commercial use (think along the lines of Qt here), if it was LGPL'ed, they had to give all that work away which doesn't make financial sense.

It depends. It's quite possible that by releasing your code, other people will in turn improve on that and cut your future development costs a lot. That's why companies like IBM, Intel and Apple all work more and more on gcc nowadays. Apple already gave up it's own compiler (MrC) and I know that at least IBM has transferred engineers from its own xlc to gcc.

From an economic point of view, open sourcing your stuff makes most sense for infrastructure frameworks and tools. After all, you can't really differentiate yourself with those things (or not enough at least), while it nevertheless costs a lot of money to get it all right. In those cases, that $1mil per year is basically wasted money which could have been spent on more useful and differentiating stuff, rather than some precious investment which you want to keep to yourself.

And once your competitors start cooperating on an open source infrastructure which replicates your functionality, you're actually at a competitive disadvantage if you keep trying to reinvent the wheel on your own. After all, you are competing against the combined resources of your competitors. You may have some efficiency advantages because you are in full control of everything, but there is a limit to that.

Also, things which differentiate today, may be a commodity tomorrow. So over time it may be that the optimal strategy changes.

But if it was BSD based, they could decide what they wanted to release back to the community in good faith (think Mac OS X here).

I think you are confused here. The BSD-licensed stuff in Mac OS X is mostly low-level stuff. Most of the proprietary stuff are high level applications (like the GUI/window manager and most end user apps), and several of them do link (dynamically) against LGPL libraries. You cannot call Mac OS X "BSD licensed", and the fact that it incorporates parts of the FreeBSD kernel and some libraries is not the reason that the upper layers can be closed.

Most of Apple's releases back to the community also make sense from a business point of view rather than merely "good faith". If their patches are incorporated upstream (i.e., in the open source project they use), then they don't have to maintain and merge those patches anymore when a new version comes out which they want to use. Additionally, all the open source stuff is tremendously helpful to developers, since if there is a bug it's much easier to figure out what's really going on.

Usually such libraries would be installed in the same folder as the application, and not installed system-wide to avoid conflicts. It sort of defeats the dynamic library advantage of saving on memory usage (different apps won't use the same library, so no memory saving), but it does enable modular upgrading/patching.

Deployment may indeed be somewhat more complex on most OS'es with a separate dynamic library though.

Jonas

If fpc/lazarus was under BSD license, I woudn't help developing it.

This difference is exactly what the gpl makes the gpl. If I have developed some code, and give it away for free and some company makes some improvements and start earning money with it. At the same time they could refuse to give me their improvements, so that I'm stuck. They didn't help me to improve my code.. but they can go with my work and make their profit...

That's the difference between BSD and the (L)GPL.

Joost

First, you have to separate libraries from the "end" binaries.

For the libraries, the situation is pretty much the same (modified LGPL and BSD don't differ THAT much in practice. Maybe some of the smaller passages in the LGPL, but that also makes the license 50 times as large as the BSD one. I also don't like that LGPL sounds like "GPL", creates lots of confusion. For that latter reason alone if I were to resetup a project like FPC, I'd choose MPL, and modified it to suit. Just for the name.

For the "end" binaries, you only highlight the worst case of BSD. Or better, you step over the bad part of GPLing the compiler too easily. E.g. only God knows how many chances we missed to get commercial help on products that link in the FPC compiler as backend. People that would have used the compiler as library, because the GPL would require them to open their entire application. When they see GPL they probably don't even bother to ask. (if I see something usable as library, part or whole and I see GPL I automatically dismiss it, and probably you too)

Something can be done about that, at least in theory, and then you have to go from FPC style GPL (nobody as full say about the whole source) to the GCC/GNU model. (every contributor has to sign away his rights to a foundation). The foundation can then enter into specific licenses with anybody.

The GNU model has the severe administrative overhead as disadvantage (want to submit patch? Wait for papers to come, sign, send back, wait for processing and confirmation as filed, a process that can take weeks-months), and the advantage (the foundation can sign any deal they want) is also a bump to take as an administrative burden, since a potential commercial user can't do anything on their own, they always have to go through this administrative-negotation process. Specially if the project is only in startup or has a very small scope in the beginning this is really inhibiting.

Not that I think it was that bad to do GPL in our case, but maybe, if we really had exploded, we would have deeply regretted it. Specially since our shared copyright system makes changing really hard.

Marco van de Voort wrote

For the libraries, the situation is pretty much the same (modified LGPL and BSD don't differ THAT much in practice.

Apart from the fact that improvements to LGPL libraries have to be distributed also in source form, while that's not the case for the BSD license. Or do you mean that in practice, most users of BSD libraries also publish the changes?

Jonas

Jonas Maebe wrote

BSD license. Or do you mean that in practice, most users of BSD libraries also publish the changes?

I think this happens most of the time... Companies don't feel pressured by the GPL or LGPL, but know they gained a lot from some BSD licensed project. They publish changes to also help their bug testing etc..

Regards,
Graeme.

I see your point. I think of it as how each camp can have leverage over the other.

GPL software needs some type of leverage over commercial software as they don't have the financial backing (or whatever else). They do this by forcing everybody else to publish there changes, which helps the project along.

Commercial companies feel they need some leverage over GPL software, as they invested a lot of money and man-power into some project to try and create a better product the end of the day. They want some return on investment. If they had to publish all change, nobody would bother buying their product, as they could just use the GPL (free) one.

I guess this is what makes the choice of a license so hard! :-)

Regards,
Graeme.

Commercial companies should find their leverage in those things the non- profitable section of the GPL-users can't do: Supply the support, documentation, guarantees that you'll provide help in case of a problem. And implement and sell things...

Or, in case of fpc - build those specific applications with it, which are not common enough for a community to write.

Joost

Well, that is a self chosen limitation, but it is the proper Slashdot party line on OSS, yes. I don't agree, though the exceptions are rarer.

And keep in mind that GNU foundation itself _ISN'T_ limited to this party line, THEY safely have copyrights signed away to the foundation, and they can strike any deal they want. They wouldn't require this signing away if they excluded commercial joint ventures so to say. I'm pretty sure RMS even hinted on this in some of his replies on remarks that "GPL and commercial intentions don't go together", since that is where I got the idea in the first place.

Or, in case of fpc - build those specific applications with it, which are not common enough for a community to write.

I prefer I could tell some vendor "implement this embedded architecture", and if you submit this back then I grant you a commercial license to integrate the compiler into your IDE, without open sourcing the IDE, and for that purpose alone. (more or less the GNU mechanism)

Of course this is not really "HOT" for FPC atm. But it could have been.

The more BSD stance can be described using fpdoc. There are zillions of such tools and liberating the license might cause some extra adoption, and e.g. (de-facto) standarisation of the fileformat.

I didn't say LGPL, I said modified LGPL, by which I meant ours. And that says

"If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so".

So with modified LGPL I can get out of source publishing too, at least that is how I intepret the license text.

Or do you mean that in practice, most users of BSD libraries also publish the changes?

I think, the ones that would with LGPL generally will anyway. I think some significant percentage of the others will also, or at least provide some form of feedback or something else that benefits the creators. Some will of course not do anything.

So the point is that under some, not so rare, circumstances usage, feedback and contributions can be higher under BSD yes (the ones that would under LGPL + a % of the others that wouldn't touch under LGPL). Which is logical, less inhibitions, more people using it, and for merging stuff back into main distribution, questions etc, you still need contact with the creators. You can simply refuse support to sb who clearly maintains his own trees.

You more or less said this yourself in the description of the OS X situation. It is easier to contribute back and use stock versions, than to maintain your own. Forking is very costly, and most OSS projects don't have it in them to be a long time moneymaker. They are more infrastructural.

And there is a certain chance that the people that don't contribute back now, will contribute back later when the "business case" is gone, and they want to merge with the main distro to keep maintenance down.

Note that I don't say we should do this, or anybody should do this. I just want to make _very_ clear that there are downsides to LGPL/GPL too. The case I picture above particularly applies when dealing with small companies. They are often very careful in the beginning, but when they work with you for a year, they often get more cooperative. The idea is that with BSD you get as many people on board, and later you harvest.

Op Fri, 4 Aug 2006, schreef Marco van de Voort:

You can do this. Of course, you need agreement within the FPC team, but there is no reason why we would need a GNU like copyright assignment procedure for that.

Daniël

Marco van de Voort wrote

inhibitions, more people using it, and for merging stuff back into main distribution, questions etc, you still need contact with the creators. You can simply refuse support to sb who clearly maintains his own trees.

So what happens if you find a discontinued LGPL project (dead for 4+ years) and you want to create a new product based on the original work. Trying to contact the original author was unsuccessfull. There are many of those on SourceForge.

Can you re-license your new project (which is based on the original one) with a different license, example BSD or MPL or something more restrictive or must the new project also be based on the LGPL?

Regards,
Graeme.

Then you are stuck with LGPL.

Can you re-license your new project (which is based on the original one) with a different license, example BSD or MPL or something more restrictive or must the new project also be based on the LGPL?

No.

We had this discussion before. I'll provide a summary for the rest:
- Since you don't have a systematic policy to point at, it is pretty hard to make a case that you (the ones that say YES) really are all principal contributors.
- Non-principal contributors are a problem. What is a contribution, what a trivial fix? And again, how is your registration of this?
- Now, if GNU foundation says yes, they can go ahead. I don't know the size of the GNU board, but the decision making process could only involve a few people. The compiler at least has 15-20 contributors, the RTL/FCL and probably vastly more.

They can only get out of source publishing (or dynamic linking, or publishing object files of the rest of your application) for their own application. Not for the RTL itself (while a BSD-licensed RTL would not require anyone to publish changes done to the RTL).

What you quote above merely means that if you change the library, you are allowed to up/downgrade (depending on your opinion) the license back to pure LGPL.

> Or do you mean that in practice, most users of BSD > libraries also publish the changes? I think, the ones that would with LGPL generally will anyway.

They are obliged to do so if the library is covered by the LGPL (as modified by us or not).

Jonas

On 4 aug 2006, at 14:41, Daniël Mantione wrote:

[change the license]

You can do this. Of course, you need agreement within the FPC team, but there is no reason why we would need a GNU like copyright assignment procedure for that.

No, you need approval of all copyright holders. Everyone who has submitted patches and did not explicitly assign the copyright to one of the FPC team members, retains the copyright on the code in that patch (to the extent that this code was copyrightable in the first place, i.e. it was not simply a typo-correction or so -- where exactly the boundary is can only be decided by a court on a case-by- case basis).

Jonas

Op Fri, 4 Aug 2006, schreef Jonas Maebe:

Exactly, if I make a suggestion to an author of a book to change something, I cannot claim copyright on it. Therefore the vast majority of patches are not protected by copyright.

Only if a patch adds enough code that it can be considered a "work" as specified in the copyright laws, the author of the patch gets rights on his work in the compiler.

Daniël

If the author of the book literally inserts your text (or bases his own text on yours) then you (co-)own the copyright on that part of the book.

Therefore the vast majority of patches are not protected by copyright.

Plenty of code has been integrated which is more than just a oneliner.

Only if a patch adds enough code that it can be considered a "work" as specified in the copyright laws,

A procedure is most certainly "a work". And significantly rewriting one would also be one.

Jonas

Or you can wait until 75 years (90 in the US) after the last author dies :) (or whatever copyright term extension Disney has managed to buy by then)

Jonas

If you have problems contacting them, getting exact deceased dates can be a problem too :)

I don't think that it's that hard assuming you want to release sources :)
- commercial libraries get a dual license: gpl and proprietary (you can develop non gpl software if you pay). This works, see e.g. Qt, MySQL etc.
- community projects are GPL or LGPL depending if they are libraries or programs
- code developed by public funds (academic etc.) gets BSD

Graeme Geldenhuys wrote: I don't think that it's that hard assuming you want to release sources :) - commercial libraries get a dual license: gpl and proprietary (you can develop non gpl software if you pay). This works, see e.g. Qt, MySQL etc.

IMHO it doesn't work. Both only succeeded because they had some buzz, not because of their licensing. It is more that they survived DESPITE their licensing. See e.g. we never seriously made a lot of work about adopting CLX.

- community projects are GPL or LGPL depending if they are libraries or programs - code developed by public funds (academic etc.) gets BSD

I think all code that is not really in danger of hostile takeover can better be BSD. The extra protection of (L)GPL is not going deliver anything, and maybe the looser licensing yield some extra contributors.

At the same time you'll loose some developers if you're using BSD.

If there's money involved, you can gain contributors with BSD, but if there's no money, you'll loose more of them. Most of the 'hobby' contributors don't like the BSD-license.

Joost

Is there any big pure community project being BSD (and friends) licensed?

Not that I know.

If there's money involved, you can gain contributors with BSD, but if there's no money, you'll loose more of them. Most of the 'hobby' contributors don't like the BSD-license.

Sounds like a Slashdot Reality Distortion field. I know no sane people that refuse to use BSD software and/or contribute to it.

Of course, you loose a few high profile cases like with embedded routers. But IMHO those are more noise and exception than every day performance.

See all the code that is open source without grassroots community. Nearly all fail (except some of the higher profile ones like Mozilla/Blender that are daily on Slashdot). The license doesn't make open source. The community behind it does.

BSD?

I know at least one. Quote Joost van der Sluis a couple of messages ago:

***
If fpc/lazarus was under BSD license, I woudn't help developing it.

This difference is exactly what the gpl makes the gpl. If I have developed some code, and give it away for free and some company makes some improvements and start earning money with it. At the same time they could refuse to give me their improvements, so that I'm stuck. They didn't help me to improve my code.. but they can go with my work and make their profit...
***

Jonas

Isn't the code base taken also from academic research projects?

Maybe he reads Slashdot? :-)

[ Charset ISO-8859-1 unsupported, converting... ]

No. The core is the original AT&T source, though in term nearly everything was changed by UCSD. But that only meant that UCSD had the position of core, not that they programmed everything.

Same with the network stack. The original Darpa grant stack (which was BSD contributed) was pretty bad. IIRC the BSD projects themselves rewrote them into the NET/2 versions that formed the basis of most of the network stacks today because it was better and faster than the original DARPA one.

- commercial libraries get a dual license: gpl and proprietary (you can develop non gpl software if you pay). This works, see e.g. Qt, MySQL etc.

it kinda works and it does bring in money for development but it also means your project cannot absorb code from any other open source project without getting special permission from that projects developers and many people will feel very uneasy about contributing code due to the one sided terms of the license "we and only we can make money from its use in propietry apps". I belive in the case of QT the only reason its GPL at all is to get it into the distros.

QT's popularity is a result of free software developers missing the boat on getting a good universal widget set in order (they then iirc hurried to turn GTK into one), i'm not sure what brought mysql to prominance.

peter green wrote

I belive in the case of QT the only reason its GPL at all is to get it into the distros.

No, that´s wrong.

Qt is pure GPL only to force people that want to developed non-GPL software with Qt to pay for the licence.

Gtk+ is LGPL is more widely available then Qt.

That makes it a not pure "community" project to me :) Pure community projects are e.g. fpc or linux.

So they still didn't start from scratch, right :)?

Florian Klaempfl wrote

That makes it a not pure "community" project to me :) Pure community projects are e.g. fpc or linux.

In the sense that the hard initial work were done volounteers as a hobby.

Florian Klaempfl wrote

So they still didn't start from scratch, right :)?

I think this discussion is ripe for moving to fpc-other :)

Jonas

Marco van de Voort wrote

> Is there any big pure community project being BSD (and friends) licensed? BSD?

:-)

Graeme.

I think this discussion is ripe for moving to fpc-other :) Jonas

Yeah, my questions where answered, though the thread was still interesting reading. At least it didn't turn into some flame-war. :-)

G.

Yes, how about PostgreSQL, this is why I moved from MySQL to Postgres (aswell as it had better more features).

Rob van der Linde wrote

Yes, how about PostgreSQL, this is why I moved from MySQL to Postgres (aswell as it had better more features).

My personal choice is Firebird (it's a shame it doesn't get the attention as MySQL and Postgres - not sure why though). Been using it in a commercial environment for years, and it works beautifully! Rock solid. My 2c worth. :-)

Regards,
Graeme.