FreeBSD 10 To Use Clang Compiler, Deprecate GCC

[pingufunkybeat]

That is what I meant.

Corrected example: You include few lines of some GPL code into your program. If you want to distribute it you have to relicence whole YOUR code to GPL, even if you had only slightly modified GPL before.

You don't have to. You can

1) get the GPL code author's permission to use their code under a different licence (LGPL or BSD or whatever), by offering a reasonable share of the profits from the combined work,
2) rewrite the few lines yourself
3) distribute your software on its own and let the user assemble it -- this is what nvidia does with their drivers, or
4) stop distributing the software to other people.

What you can't do is relicence somebody else's code. If your secrecy is so important to you, and the GPL part is only a small fraction of the value, then write those "few lines of code" yourself instead of freeloading.

But this "virus automatic relicencing of all your code GPL" FUD is just FUD.

[jrch2k8]

Not at all ... not to mention in OSX and IOS.

Os X and Ios are not freebsd, they are based on the previous jobs company Next BSD code and Mach. they improved some parts of the bsd code with parts of freebsd though but is not freebsd per se.

in the embedded world freebsd is a small share of what linux is, after all embedded is one of the uber strong linux markets

[Chad Page]

I feel that long-term, FreeBSD going to Clang is a Very Good Thing, even setting aside the license.

There are many technically interesting applications for LLVM that gcc is not in a similar position to pursue, and having all of FreeBSD built under Clang will improve it's maturity (and optimizations )

[LightBit]

You don't have to. You can

1) get the GPL code author's permission to use their code under a different licence (LGPL or BSD or whatever), by offering a reasonable share of the profits from the combined work,
2) rewrite the few lines yourself
3) distribute your software on its own and let the user assemble it -- this is what nvidia does with their drivers, or
4) stop distributing the software to other people.

What you can't do is relicence somebody else's code. If your secrecy is so important to you, and the GPL part is only a small fraction of the value, then write those "few lines of code" yourself instead of freeloading.

But this "virus automatic relicencing of all your code GPL" FUD is just FUD.

1) Why would somebody give me permission to use his code under BSD license, if he released it under GPL, because he is afraid some corporation will "steal" his code?
2) That's what I do. Few lines was an extreme example, it could also be more.
3) Not practical.
4) Isn't Stalman talking about sharing all the time? Truth is his license might fully prevent it.

No, it is manual.

[kraftman]

I never said otherwise. True, BSDs are less competitive in features.
You must be selfish, if you want to be competitive.

That's true, but sometimes you're not so selfish, because other GPL projects can take your code.

[XorEaxEax]

You should never trust corporations.
Corporations give back to BSD, because it's cheaper for them. They get free developers. So both have benefit.

Yes, certainly FreeBSD (in particular) of the BSD's gets code contributions from corporations using it, but nowhere near the level of corporate contributions which Linux enjoys. And given that there is no 'share-alike' licence binding cooperative development together on BSD it's very unlikely that a company will release any enhancement back to FreeBSD which they think could aid a competitor. Linux, due to it's licence is in itself a no-competition zone, all participants pool their resources into making Linux as good as possible and then use Linux as the same base when they compete in other areas (support, enterprise solutions, distros, etc).

GPL is not so free. Copyleft per file would be better.

LGPL is available to those who would want copyleft per file, however it is up to the code authors to decide if they want to licence it as such, or GPL, or BSD/MIT or CDDL etc etc, and it's up to you to decide if you find the conditions acceptable and use it.

But GPL does that. For example: You include few lines of some GPL code into your program. You are foreced to relicence whole YOUR code to GPL, even if you had only slightly modified GPL before.

Actually including only a 'few lines of code' would not constitute a derivative work unless your program was of the 'hello world' category. Also you do not have to 'relicence' YOUR code, you will have to make it available ALONG with the GPL licenced code you are using in your distributed binary but YOUR code can stay licenced as it was as long as it is GPL compatible (which BSD, MIT and the like are). So if you write code and licence it under BSD/MIT and then release a program with it which also contains GPL code then YES, you must release the source code to that WHOLE program, but you (and others) can still use YOUR part of the code in proprietary projects.

[XorEaxEax]

Os X and Ios are not freebsd, they are based on the previous jobs company Next BSD code and Mach. they improved some parts of the bsd code with parts of freebsd though but is not freebsd per se.

No, certainly it's not anything close to vanilla FreeBSD but I doubt there's alot of old stuff from the NeXT days in there, iirc the Mach stuff isn't even micro-kernel based (Mach didn't become a full-fledged micro-kernel until late in the game, and shares little with the NeXT implementation) but again I may be remembering incorrectly.

in the embedded world freebsd is a small share of what linux is, after all embedded is one of the uber strong linux markets

Well I didn't say it's anywhere near Linux marketshare in embedded but it's not a 'hobby-os' outside of servers either. We have atleast Cisco and Juniper using FreeBSD as the base for their proprietary operating systems on which their embedded network devices (routers etc) runs on. Again the reason they choose FreeBSD instead of say Linux is because they are allowed to keep the enhancements they do to FreeBSD proprietary and thus use them as a competitive edge. This is great for Cisco,Juniper et al but it means less code makes it back to FreeBSD. Then again the FreeBSD developers ARE well aware of this and CHOOSE to allow this by their choice of licence so it's not as if anyone is being tricked.

There's obviously room for both BSD and Linux, as an end-user though I prefer the Linux model as I get to enjoy ALL the kernel enhancements made by corporations and not just those they think are of no competitive consequence.

[LightBit]

LGPL is available to those who would want copyleft per file, however it is up to the code authors to decide if they want to licence it as such, or GPL, or BSD/MIT or CDDL etc etc, and it's up to you to decide if you find the conditions acceptable and use it.

LGPL is not per file, because it doesn't allow static linking.

Actually including only a 'few lines of code' would not constitute a derivative work unless your program was of the 'hello world' category. Also you do not have to 'relicence' YOUR code, you will have to make it available ALONG with the GPL licenced code you are using in your distributed binary but YOUR code can stay licenced as it was as long as it is GPL compatible (which BSD, MIT and the like are). So if you write code and licence it under BSD/MIT and then release a program with it which also contains GPL code then YES, you must release the source code to that WHOLE program, but you (and others) can still use YOUR part of the code in proprietary projects.

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

My example has GPL incompatible license, because modified GPL is not compatible with GPL.

[XorEaxEax]

LGPL is not per file, because it doesn't allow static linking.

Well, that is an edge case as the point is to allow the end user to modify (generally as in update) the LGPL-based part of the application which isn't practical when the LGPL part has been statically linked into a binary. From what I gather it's allowed if you provide linkable object files for the proprietary part so that the end user can link it with a modified version of the LGPL code into a binary should he/she so wish. However it doesn't seem this is a practical problem in reality as it's easy to dynamically link as we can see by the wide use of projects like gtk2, gtk3, qt, sdl, webkit which are afaik all LGPL licenced.

My example has GPL incompatible license, because modified GPL is not compatible with GPL.

Ehh, if it's GPL incompatible then of course you can't use it together with GPL licenced code. What is your point?

[LightBit]

Well, that is an edge case as the point is to allow the end user to modify (generally as in update) the LGPL-based part of the application which isn't practical when the LGPL part has been statically linked into a binary. From what I gather it's allowed if you provide linkable object files for the proprietary part so that the end user can link it with a modified version of the LGPL code into a binary should he/she so wish. However it doesn't seem this is a practical problem in reality as it's easy to dynamically link as we can see by the wide use of projects like gtk2, gtk3, qt, sdl, webkit which are afaik all LGPL licenced.

Dynamic linking all small parts of other projects is also not practical, gtk2, gtk3, qt, sdl, webkit are diffrent story.

Ehh, if it's GPL incompatible then of course you can't use it together with GPL licenced code. What is your point?

My point is, GPL is very incompatible and that "forces" you to use GPL for your code.
As I said, I would prefer per file copyright license, like CDDL, but it is GPL incompatible.