|
|
Subscribe / Log in / New account

LLVM 2.7 released

From:  Chris Lattner <clattner-AT-apple.com>
To:  llvm-announce-AT-cs.uiuc.edu
Subject:  LLVM 2.7 Release!
Date:  Tue, 27 Apr 2010 00:56:35 -0700

Hi LLVM Friends, Fans, Followers and Fanatics,

LLVM 2.7 is live! You can download it here:
http://llvm.org/releases/   and read about it here:
http://llvm.org/releases/2.7/docs/ReleaseNotes.html

This release includes approximately 6 months of development that provide
major enhancements and new features over the LLVM 2.6 release.  This
includes significantly better generated code, improvements to debug
information generation and a broad number of new features in the
core infrastructure.  One exciting feature is that Clang is now able to
bootstrap itself, a major milestone in any compiler's development and
particularly notable considering the complexity of implementing C++!

The new features in LLVM 2.7 are broad and covered in the release notes
but here are some major additions to give a flavor for the improvements:
2.7 includes a new MicroBlaze target, a native code disassembler API
(with X86 supported so far), a much more memory efficient and flexible
representation of debug information, an extensible metadata system that
allows front ends to markup IR with information for language-specific
optimizations (e.g. devirtualization, type based alias analysis, etc)
and other down-stream consumers, direct IR support for taking the
address of a block and jumping to it (which speeds up some interpreters
loops by over 20%!), major progress on the MC project (a new LLVM
native code assembler), and major progress on C++ support in Clang.

Beyond the big features, there are dozens smaller features in LLVM 2.7,
such as support for non-temporal stores, 16-bit half-float support,
much improved X86 tail calls, better inliner heuristics, an improved
implementation of __builtin_object_size, many optimizer improvements,
much nicer comments produced in -fverbose-asm mode, debug info support
in the JIT, substantial footprint reductions for the LLVM compiler
itself (useful for clients of the JIT), full NEON support in the ARM
backend, support for building LLVM as a single big dynamic library,
and more.  Please see the release notes for more details.

Beyond improvements to the code, there are lots of other improvements
in the LLVM world.  We have a new logo: http://llvm.org/Logo.html
(rawr!), a new official LLVM blog: http://blog.llvm.org/ , a much
faster llvm.org server, and the LLVM repository passed 100,000
revisions in March.  Pace of development on LLVM itself and application
of LLVM to other projects continues to increase and expand.

This release would not be possible without our volunteer release team.
Thanks to Tanya Lattner, Pawel Worach, Nick Lewycky, Duncan Sands,
Anton Korobeynikov, and Edwin Torok for their work to qualify and
shepherd the release.  If you have questions or comments about this
release, please contact the LLVMdev mailing list!  Onward to 2.8,

-Chris

LLVM 2.6 Release Announcement:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2009-Oct...




to post comments

licence

Posted Apr 27, 2010 15:16 UTC (Tue) by coriordan (guest, #7544) [Link] (72 responses)

It would be great if they changed to a copyleft licence.

Free software offers a short cut for development. Instead of writing a whole new compiler, the NextStep team got an Objective-C compiler quickly by extending GCC instead of starting from scratch. And due to the copyleft licence of GCC, we also got something: a free software Objective-C compiler.

If LLVM offers companies a short cut for developers, but doesn't require that the extensions get contributed back as free software, then I'm worried this will reduce the number of commercial contributors to free software compilers. They'll get a short cut, and we'll get nothing. I don't see why free software users would want this situation.

licence

Posted Apr 27, 2010 15:38 UTC (Tue) by bronson (subscriber, #4806) [Link] (7 responses)

LLVM has been doing awesome so far and has been the recipient of massive contributions from commercial companies. I suspect the LLVM authors knew what they were doing when they picked their license.

licence

Posted Apr 27, 2010 20:43 UTC (Tue) by coriordan (guest, #7544) [Link] (6 responses)

Of course they'll contribute at this stage. The current focus is on catch-up, and those companies have a self-serving interest in getting LLVM to a stage where they can do useful stuff while free-riding on it instead of having to build on GCC and give everything back.

licence

Posted Apr 27, 2010 21:32 UTC (Tue) by daglwn (guest, #65432) [Link] (5 responses)

This comment demonstrates a fundamental misunderstanding of the issue.

First, LLVM is not playing catch-up. It is already at least as good as gcc by several measures. There are companies that have contributed significant enhancements to LLVM, not just stuff that gcc already implements.

Often contributing code is not the problem. While sometimes companies want to hold onto IP for a little while, it is well-understood that contributing code back makes maintenance much easier. In the end, pushing things upstream is usually the best thing to do.

The bigger issue with the GPL is how it affects other components of a system, in this case the compiler. LLVM is a set of libraries. GPLing libraries means that one cannot link them to proprietary modules. A compiler is a very modular thing. If LLVM were GPL companies wouldn't be able to use it. Not because they don't want to contribute code to LLVM, but because they couldn't legally link to it.

A company that's heavily invested in other modules isn't going to throw those away and start from scratch. Instead the company will re-implement the missing piece and that means no code goes upstream into LLVM.

One could argue that LLVM should be LGPL. That's certainly a viable alternative and would get things closer to where I think you want them to go. It has its own issues but LGPL is really more appropriate than GPL for LLVM if you want a copyleft license.

licence

Posted Apr 28, 2010 0:28 UTC (Wed) by coriordan (guest, #7544) [Link] (4 responses)

Maybe you took "catch-up" as a put down for the project. That's not how I meant it. I meant it in terms of adoption, readiness for adoption as judged by third-parties. Whatever about LLVM comparing well or badly in various ways to GCC, the current situation is that virtually every project uses GCC, and almost none use LLVM. Before LLVM becomes the pace setter, it first has to get to a stage where projects and distributions migrate in large numbers from GCC to LLVM.

It's not there yet. A proprietary extension that squeezes out a 10% speed increase is currently not very valuable because the software isn't used. When the software is widely used, then a 2% speed increase will be noteworthy. A that point, the commercial developers will keep their special sauce secret and projects and distros will be asked to choose between shipping slower binaries, or shipping faster binaries that can't be modified/recompiled without losing the speed increase.

That's a problem that's coming.

licence

Posted Apr 28, 2010 3:41 UTC (Wed) by daglwn (guest, #65432) [Link] (3 responses)

How do you define "being used?" There are many companies using LLVM in products. It's not widely used by open source projects, perhaps, but your argument assumes that companies worry about their IP being used by open source projects. The worry, if there is one, is that competing companies will use the IP. Since multiple companies are already using LLVM, it seems this is not a big concern.

The primary issue is not contributing code. It's being able to link to other software.

licence

Posted Apr 28, 2010 20:41 UTC (Wed) by man_ls (guest, #15091) [Link] (2 responses)

Why is it that companies shouldn't be able to link a GPL compiler to other software, like proprietary modules? As long as it is only used in-house there is no problem at all, and I would guess that is the primary use case for 99% of users. Particularly for a compiler: you enhance it, you use it to compile your software, you distribute the result. (All libraries used by compiled code should be under a different license, of course, just like with GCC.)

Those that want to distribute or sell their proprietary modules along with the compiler cannot, and that is exactly Ciaran's point: a company cannot make a business of selling proprietary enhancements.

licence

Posted Apr 29, 2010 4:46 UTC (Thu) by Thalience (subscriber, #4217) [Link] (1 responses)

I think the point is that LLVM is not just a compiler. It is a toolkit. Producing a proprietary module to enhance the code generation (or whatever) is possible, sure. Although I think that trying to go head to head with Intel's ICC on the proprietary compiler front is a (badly) losing proposition. Anyone who wants a proprietary compiler already has one.

The real interesting cases where someone might want to link parts of LLVM to proprietary code are things like using the JIT compilation infrastructure as part of the AI for a commercial game. Or the MC toolkit for binary analysis of some kind. Where the end product is not really a compiler in any traditional sense of the word.

licence

Posted Apr 29, 2010 7:58 UTC (Thu) by nix (subscriber, #2304) [Link]

ClamAV 0.96 already does this, with a signed bytecoded language for writing downloadable detectors in, compiled to native code by LLVM, and compiled from a subset of C into the bytecode by LLVM as well.

licence

Posted Apr 27, 2010 15:39 UTC (Tue) by BrucePerens (guest, #2510) [Link] (7 responses)

Over the long term LLVM will be hurt just because of its license proliferation - lots of code, but lots of reasons not to use it. Surprisingly, some of its commercial contributors turn to GPL licenses just to impede the others from running away with their code.

Ciaran, it might help if there was a viable next-generation compiler project using GPL3 for people to jump upon. There isn't.

licence

Posted Apr 27, 2010 17:19 UTC (Tue) by b7j0c (guest, #27559) [Link] (5 responses)

the only "hurt" will be felt by projects who are unwilling or unable to incorporate bsd-style licensed code.

for everyone else, life will go on. i'm happily using clang on freebsd as well as dtrace and zfs.

licence

Posted Apr 27, 2010 17:33 UTC (Tue) by BrucePerens (guest, #2510) [Link] (4 responses)

That would be true if all of the code was BSD-licensed. That's only true for the LLVM core, not for the various additions like Adobe's, etc.

licence

Posted Apr 27, 2010 18:16 UTC (Tue) by elanthis (guest, #6227) [Link] (1 responses)

What is your point? We should use the GPL to stop companies from releasing modifications under the GPL? Actually, I'm quite certain that would work.

licence

Posted Apr 27, 2010 18:23 UTC (Tue) by BrucePerens (guest, #2510) [Link]

No. That producers of new code won't stop at the GPL, but will also use proprietary licenses.

licence

Posted Apr 27, 2010 20:41 UTC (Tue) by coriordan (guest, #7544) [Link] (1 responses)

Adobe is already making proprietary extensions?

This has become a problem sooner than I expected.

licence

Posted Apr 29, 2010 3:29 UTC (Thu) by darthscsi (guest, #8111) [Link]

"Adobe is already making proprietary extensions?"

http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler_Hi...

licence

Posted Apr 27, 2010 20:01 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

LLVM is almost 10 years old now (from the moment of conception). GCC is 25 year old. So LLVM's lifetime is comparable to the lifetime of GCC.

So far, no signs of license proliferation. Because it's easier to contribute private patches to the mainline then to maintain a fork.

My previous employer has a software product based on LLVM, and we've contributed quite a few patches (we had 'only mainline' policy for LLVM). And every time a new version of LLVM came out, we got a performance boost for our product absolutely for free.

licence

Posted Apr 27, 2010 15:40 UTC (Tue) by elanthis (guest, #6227) [Link] (3 responses)

-1

LLVM does not seem to be hurting in the least despite being liberally licensed, while GCC is wondering why the hell nobody wants to contribute.

licence

Posted Apr 27, 2010 17:03 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Everyone knows why LLVM is popular with developers. It's much more modern and less messy (and has a library interface and is hellishly extensible). GCC, despite many cleanups, remains a big hairball in some ways...

licence

Posted Apr 27, 2010 18:20 UTC (Tue) by patrick_g (subscriber, #44470) [Link] (1 responses)

>>> Everyone knows why LLVM is popular with developers. It's much more modern and less messy (and has a library interface and is hellishly extensible).

Since GCC version 4.5 it is possible to extend the compiler with plugins.
See http://gcc.gnu.org/wiki/plugins

licence

Posted Apr 27, 2010 19:20 UTC (Tue) by daglwn (guest, #65432) [Link]

That's not enough. LLVM's IR is simple and easy to understand. gcc's is complex and difficult to understand. That's really the biggest blocker for most people.

Starting over

Posted Apr 27, 2010 15:57 UTC (Tue) by tjc (guest, #137) [Link] (3 responses)

Instead of writing a whole new compiler, the NextStep team got an Objective-C compiler quickly by extending GCC instead of starting from scratch.
That's largely due to the fact that Objective-C is a superset of C, right down to the syntax of the language, where many language features are implemented as compiler directives. Anyone writing an Objective-C compiler based on a free C compiler would have the same advantage. And starting over from scratch was probably LLVM's biggest advantage. I expect there's very little cruft in LLVM.

Starting over

Posted Apr 27, 2010 16:16 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

One man's cruft is another one's maturity and features.

It's relatively easy to get clean code and make things nice and fast when the requirements, expectations, and features are low. By the time LLVM gets up to GCC's portability, performance, and covers all the similar corner cases it's going to be huge and ugly also.

Another thing to keep in mind is that so far LLVM performs best as a compiler when it's using GCC in the back-end.

As far as LLVM vs GCC we pretty much win either way the things end up going.

Starting over

Posted Apr 27, 2010 16:45 UTC (Tue) by nteon (subscriber, #53899) [Link] (1 responses)

Another thing to keep in mind is that so far LLVM performs best as a compiler when it's using GCC in the back-end.
Citation? There has been llvm-gcc, which uses the LLVM optimization passes & code-generation with the gcc front-end, and dragon egg which does the same using gcc 4.5's plug-in infrastructure. I haven't heard of a clang front-end stuck onto the gcc back-end stuff, but I haven't been following as closely over the past few months.

Starting over

Posted Apr 27, 2010 17:52 UTC (Tue) by drag (guest, #31333) [Link]

Oops. Ya, I had it backwards.

licence

Posted Apr 27, 2010 16:55 UTC (Tue) by cowsandmilk (guest, #55475) [Link] (3 responses)

Copyleft isn't the only thing that pushes companies to give code back. There's also the idea of free maintenance, improvements, and code review. It's well known how messy it is to try to maintain something outside the linux kernel, even if it is open. There is a major benefit of getting your code mainlined, whether it is in the kernel or in LLVM. Since the mainline contributions won't be under a copyleft license, Apple knows it can use those contributions in their proprietary products easily, just like others have permission to do so.

They know what they're doing.

licence

Posted Apr 27, 2010 18:02 UTC (Tue) by coriordan (guest, #7544) [Link] (2 responses)

> There's also the idea of free maintenance, improvements, and code review.

This tempts companies to contribute back the code that won't give the free software world any advantage.

If they can get the community to maintain the basic functionality and features that already exist in other free software projects, then of course they'll go for that.

But they'll keep the good stuff for themselves.

licence

Posted Apr 27, 2010 18:43 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

Is this actually the case with LLVM? Are there bits of it that are not "donated back"?

licence

Posted Apr 27, 2010 19:24 UTC (Tue) by daglwn (guest, #65432) [Link]

Maybe, maybe not. Our company has contributed some things back to LLVM and we'll be contributing a lot more as we go along. Pretty much the only stuff we've held back is stuff that depends on other pieces of our compiler. We can't contribute those back because they don't work without the proper infrastructure. It wouldn't be of any use to anyone. But we absolutely have contributed back the infrastructure to support those bits and it is entirely possible for someone to write the missing bits.

licence

Posted Apr 27, 2010 17:13 UTC (Tue) by b7j0c (guest, #27559) [Link] (3 responses)

no thank you

indeed i don't recommend using any of the fsf licenses to anyone anymore. they have become the legal morass they sought to negate. gpl2...gpl3...lgpl...agpl...this minefield has become far too complex. my guess is most people using an fsf license can't even explain its implications.

now read the three clause bsd license. within thirty seconds you understand what the license implies.

licence

Posted Apr 29, 2010 3:46 UTC (Thu) by k8to (guest, #15413) [Link] (2 responses)

Two clause?

licence

Posted Apr 29, 2010 18:09 UTC (Thu) by Trelane (subscriber, #56877) [Link] (1 responses)

I prefer public domain. *it* is true freedom.

licence

Posted May 2, 2010 17:46 UTC (Sun) by k8to (guest, #15413) [Link]

"Public domain" is strictly inferior to the BSD two-clause license. Public domain doesn't exist in much of this globe, but copyright is almost everywhere.

licence

Posted Apr 27, 2010 17:46 UTC (Tue) by trasz (guest, #45786) [Link] (14 responses)

The copyleft licenses cause more problems than they solve. Take a look at MySQL vs PostgreSQL - right now the fact that MySQL is GPL prevents the original authors (or anyone else, except for Oracle) from continuing their business. PostgreSQL, however, is doing just fine.

Also, take a look at license compatibility problems caused by GPL (actually, Stallman's interpretation of GPL). It's a strange kind of "freedom" when you cannot legally use GPL-ed library in Firefox, or cannot include ZFS in Linux.

Adding restrictions doesn't increase freedom. GPL means more restrictions.

licence

Posted Apr 27, 2010 17:59 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

The "business" of selling proprietary licenses? Right.

licence

Posted Apr 27, 2010 18:05 UTC (Tue) by drag (guest, #31333) [Link] (7 responses)

> The copyleft licenses cause more problems than they solve. Take a look at MySQL vs PostgreSQL - right now the fact that MySQL is GPL prevents the original authors (or anyone else, except for Oracle) from continuing their business. PostgreSQL, however, is doing just fine.

The problem has much more to do with the requirements of copyright assignments to MySQL.

And that still has not stopped anybody from any forks. It's just there is no point as long as Oracle keeps on making it open source and keep developing it... which they are.

> Also, take a look at license compatibility problems caused by GPL (actually, Stallman's interpretation of GPL). It's a strange kind of "freedom" when you cannot legally use GPL-ed library in Firefox, or cannot include ZFS in Linux.

ZFS and Firefox have their own restrictions that make them incompatible with the GPL.

Don't overlook that fact. Sure their restrictions are not a big deal when taken singularly, but when you start to mix and match all the different potential restrictions those licenses allow then you run into a huge legal mess very quickly.

In terms of Linux distributions the GPL provides a invaluable function as the 'lowest common denominator' in terms of 'lack of freedom'. It's the worst you can get.

When software licenses are attempting to layer more and more restrictions on end users is when you run into problems with GPL compatibility. When they are 'more free' then the GPL then there is no problem. So therefore the fact that the majority of the software in a typical Linux-based system is GPL means that it is keeping everybody honest.

Imagine you replace all the GPL/LGP'd software licensing with random selection of software licenses that the GPL has problems with... OpenSSL license, some Microsoft open source license, original mozilla license, motif licensing, etc etc. Now try to figure out how a Apache code is going to mix with OpenSSL code when writing a application that ties into a ZFS licensed library in a project that is principally licensed under the Apple Public Source code license and wants to create a GUI front end using the old QT proprietary license.

licence

Posted Apr 27, 2010 20:08 UTC (Tue) by b7j0c (guest, #27559) [Link] (4 responses)

the fsf is doing good enough job with its own alphabet soup of licenses, so i don't see how your comparison to the world of non-fsf licensing matters.

on the other hand, to turn your argument back on you, were one to replace the convoluted mess of fsf licenses with the three-clause bsd license, developers could actually read and understand the license they are using on their code.

even the "executive summaries" of just the gplv3 are nearly incomprehensible. the three-clause bsd license on the other hand doesn't even need a secondary explanation.

licence

Posted Apr 28, 2010 8:21 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (3 responses)

I don't find GPLv3 confusing.

"If you distribute binaries, you have to make the source you built them from available (best plan is to just chuck it on the CD/DVD). If you distribute the software as device firmware, you have to let the device operate with end-user-modified replacement firmware. If you have patents touched on by the software, and you distribute it, you have to licence them for free."

Have I missed anything?

licence

Posted Apr 28, 2010 8:31 UTC (Wed) by patrick_g (subscriber, #44470) [Link]

>>> Have I missed anything?

Excellent summary ! Thanks a lot.

licence

Posted Apr 28, 2010 10:34 UTC (Wed) by trasz (guest, #45786) [Link] (1 responses)

You missed the whole shared libraries problem, which may or may not exist, depending on who you ask, and problems with e.g. C++ templates.

licence

Posted Apr 28, 2010 14:30 UTC (Wed) by mpr22 (subscriber, #60784) [Link]

Thank you - I figured there had to be something, given that people seemed to be honestly claiming confusion. Clearly I shall have to have a look at these issues and refine my summary :)

licence

Posted Apr 27, 2010 21:58 UTC (Tue) by roc (subscriber, #30627) [Link]

> ZFS and Firefox have their own restrictions that make them incompatible
> with the GPL.

This is not true. Firefox can be redistributed under the GPL. I'm not sure what you or the original poster are referring to.

licence

Posted Apr 28, 2010 10:31 UTC (Wed) by trasz (guest, #45786) [Link]

In short - license incompatibility doesn't happen when you leave out GPL and old Qt license from the mix. There is no problem with mixing BSD, Apache, Mozilla, CDDL, Apple Public Source License or even that strange Microsoft thing.

Second thing is - it's not that licenses that are not compatible with GPL are more restrictive. Both CDDL and Mozilla are less restrictive than GPL, yet both are GPL-incompatible.

Catalogue of myths

Posted Apr 28, 2010 14:05 UTC (Wed) by pboddie (guest, #50784) [Link] (4 responses)

Take a look at MySQL vs PostgreSQL - right now the fact that MySQL is GPL prevents the original authors (or anyone else, except for Oracle) from continuing their business.

When the MySQL authors assigned their copyright to others - a universal problem - they handed over control over licensing to someone else. Had MySQL been permissively licensed, the last open source release of it could have been years ago by now, should Sun have wanted this to happen. PostgreSQL's ownership is more fragmented, meaning that one party cannot control everything, but they can (and do) maintain proprietary editions of the software.

It's a strange kind of "freedom" when you cannot legally use GPL-ed library in Firefox, or cannot include ZFS in Linux.

Firefox is surely tri-licensed under the Mozilla licensing policy, so this is you making stuff up again. Also, copyleft licences are all about end-user privileges/freedoms: that the end-user gets to see, change and pass on the code. Everyone who has considered this matter with any seriousness knows this to be the case.

It probably shouldn't come as a surprise that people would try and stick the intellectually feeble (but all too readily used) "troll" label on CiarĂ¡n O'Riordan while parroting the usual brand of ill-considered pontification on matters of "freedom". Some people would rather ridicule others than learn from them.

Catalogue of myths

Posted Apr 28, 2010 18:14 UTC (Wed) by trasz (guest, #45786) [Link] (3 responses)

If MySQL was permissively licensed, it would be independent from its "owners" despite any copyright assignments; if Sun wanted to close it, the community would just continue developing open version. It happens all the time, due to Fujitsu having its own closed-source fork of PostgreSQL, or Juniper having its own closed-source fork of FreeBSD - or even Panasonic having its own version of FreeBSD, which seems to have replaced Linux on new Viera TVs. It doesn't impact the original, open source, project, because there is no single "privileged party", like Oracle in case of MySQL.

Firefox is tri-licensed, and probably wants to stay that way. This means you cannot make it use GPL-ed library, since it would mean the resulted copy would be GPL-only.

As for your "everyone knows that adding licensing restrictions gives end users more freedom" claim - believe me, outside of GPL camp it's not an universal wisdom. ;->

Catalogue of myths

Posted Apr 28, 2010 22:30 UTC (Wed) by pboddie (guest, #50784) [Link] (2 responses)

If MySQL was permissively licensed, it would be independent from its "owners" despite any copyright assignments; if Sun wanted to close it, the community would just continue developing open version.

Well, MySQL is independent from its "owners" right now. The whining from its original "owners" has a lot to do with them not being able to go back to the business of selling a proprietary or restricted version.

It happens all the time, due to Fujitsu having its own closed-source fork of PostgreSQL, or Juniper having its own closed-source fork of FreeBSD - or even Panasonic having its own version of FreeBSD, which seems to have replaced Linux on new Viera TVs. It doesn't impact the original, open source, project, because there is no single "privileged party", like Oracle in case of MySQL.

Yes, I've seen this argument a lot. A bunch of people write code for a permissively licensed project, some corporation goes and enhances the code, ships it as a binary, but "it's OK because everyone still has the code they wrote". Compared to a project which has a copyleft licence, who loses? The end-users, of course.

Firefox is tri-licensed, and probably wants to stay that way. This means you cannot make it use GPL-ed library, since it would mean the resulted copy would be GPL-only.

If I take Firefox, make it work with a GPL-licensed library and distribute my modified version under the GPL, whose licence am I violating? Mozilla have permitted me to license the software under the GPL. Your use of the word "cannot" implies that it's not legally possible, but in fact it's just your usual complaining about a copyleft licence being put on some code.

As for your "everyone knows that adding licensing restrictions gives end users more freedom" claim - believe me, outside of GPL camp it's not an universal wisdom. ;->

Evidently not. But review what I've written above about corporations using permissively licensed code, then get back to us when you've caught up.

Catalogue of myths

Posted Apr 29, 2010 14:57 UTC (Thu) by trasz (guest, #45786) [Link] (1 responses)

"Well, MySQL is independent from its "owners" right now. The whining from its original "owners" has a lot to do with them not being able to go back to the business of selling a proprietary or restricted version."

Not being able to go back to the business of selling enhanced version, you mean. Or selling any version at all, unless by selling you mean "asking money while at the same thing giving the same thing for free".

As I said, that's one of the problems created by copyleft licensing, which would never occur with permissive license.

"Yes, I've seen this argument a lot. A bunch of people write code for a permissively licensed project, some corporation goes and enhances the code, ships it as a binary, but "it's OK because everyone still has the code they wrote". Compared to a project which has a copyleft licence, who loses? The end-users, of course."

Nobody loses. End users are happy, because they can buy better product, that wouldn't exist with copyleft license, because noone would invest serious money into development of something they have to give away for free. Other end users are happy, because they can still use open version for free. Developers are happy, because the corporation pays them money for working on a derivative of their Open Source project. Corporation is happy, because it sells the product.

"If I take Firefox, make it work with a GPL-licensed library and distribute my modified version under the GPL, whose licence am I violating? Mozilla have permitted me to license the software under the GPL. Your use of the word "cannot" implies that it's not legally possible [..]"

Yeah, you're right here. However, it's not possible to incorporate it back into the original project (in this case Mozilla), for reasons described above. Still, it's yet another problem caused by the copyleft license.

Catalogue of myths

Posted Apr 29, 2010 15:56 UTC (Thu) by pboddie (guest, #50784) [Link]

Not being able to go back to the business of selling enhanced version, you mean. Or selling any version at all, unless by selling you mean "asking money while at the same thing giving the same thing for free".

They can sell what they like as long as they adhere to the licensing: Red Hat seems to manage quite well doing just that. You'd think that being able to say "I am Monty!" and insisting that enough extra value is generated would be enough to differentiate Monty's outfit from other forks of MySQL, and Monty can still sell the software under the GPL. If his customers value that special edge that only Monty can provide, and if they're doing everything over the Web anyway, as long as they get the source code, no-one is violating the licence. And even if they ship actual software, if end-users are as apathetic as you make them out to be, they won't bother uploading the sources to the Internet, will they?

As I said, that's one of the problems created by copyleft licensing, which would never occur with permissive license.

You'll have to do better than that: if PostgreSQL was all owned by a single company - let's say it was Oracle - would the "open source" version still be under a permissive licence? I doubt it.

Nobody loses. End users are happy, because they can buy better product, that wouldn't exist with copyleft license, because noone would invest serious money into development of something they have to give away for free.

Yeah, that Linux thing: no-one's invested anything in it. Even now, people and organisations are investing time in the open source variants of MySQL, although I myself wonder why they bother, but that has nothing to do with the licence. To make such claims is just plain disingenuousness at its most blatant, especially given which site you're writing this on.

End-users do get the benefit of an improved product, potentially, disregarding the dog's breakfast that a lot of consumer electronics vendors seem to make when their code is exposed to public scrutiny, but end-users don't get the benefits around the code. This may seem unimportant to you, but claiming that it's absolutely unimportant is practically the same as the Bill Gates' jibe about "no-one wants the source code of their office suite": demonstrably untrue for, to take but one example, people whose native language is not in the list of wealthy, easily-milked markets supported by Mr Gates' proprietary software.

Yeah, you're right here. However, it's not possible to incorporate it back into the original project (in this case Mozilla), for reasons described above. Still, it's yet another problem caused by the copyleft license.

Yes, I am right and you know it, although that didn't stop you from making stuff up anyway. And it's only a "problem" for people who want to consume permissively licensed software. A "problem" which amounts to the whining often seen when people whose permissively licensed work suddenly ends up in a copyleft-licensed project: whining which is more or less equivalent to "I wrote one thing but I meant another". That these people then accuse copyleft licence users of "not respecting other people's wishes" just demonstrates the levels of hypocrisy involved.

licence

Posted Apr 28, 2010 1:50 UTC (Wed) by rsidd (subscriber, #2582) [Link] (23 responses)

Ciaran O'Riordan: you are not a free software advocate. You are a GNU troll.

In addition to what others have said above, the GNU licences in no way guarantee that modifications will be usable. Look at the khtml/webkit story (LGPL). Look at the ongoing Android/Linux story (GPL). (In fact what bit khtml was essentially what also bit FreeBSD: Apple did make all changes available, in their own tree with no effort to integrate upstream. It had nothing to do with the licence. Apple could well have gone with a Linux-based kernel, instead of the BSD/Mach one that they used, and a proprietary GUI. The result would have been the same.)

Whether corporate contributions make it upstream has to do with how the project is managed, not how it is licensed. As others have said, LLVM is doing fine. Meanwhile, your comments look like FUD -- your fear being that LLVM may overtake GCC as the C compiler of choice.

licence

Posted Apr 28, 2010 3:46 UTC (Wed) by daglwn (guest, #65432) [Link]

This is spot on. LLVM is a very well-managed project. Upstream contributions go through a rigorous review process that ensures they integrate well. While that means more effort upfront to make patches available, it also means a much higher quality of contributions.

licence

Posted Apr 28, 2010 5:18 UTC (Wed) by ncm (guest, #165) [Link] (2 responses)

Lying about Ciaran undermines your own credibility. I will remember this.

licence

Posted Apr 28, 2010 6:09 UTC (Wed) by rsidd (subscriber, #2582) [Link] (1 responses)

What lie? My claim that he is not a free software advocate? If he is, his advocacy is highly selective: he never has a good word for a non-GNU-licensed project. Or my claim that he is a GNU troll? His repeated "why-not-copyleft" comments on stories about BSD-licensed software (especially successful software) speak for themselves. You're welcome to remember this.

GNU troll?

Posted Apr 28, 2010 21:17 UTC (Wed) by man_ls (guest, #15091) [Link]

Repeatedly making well-reasoned and polite requests based on one's beliefs does not make anyone a troll. Ciaran is not begging for attention but making a valid point, with which you may happen to disagree; and he has proved time and time again that he is ready to work to make things happen.

You are insulting a valuable member of the community just to make a point, which is disgusting.

licence

Posted Apr 28, 2010 5:24 UTC (Wed) by rqosa (subscriber, #24136) [Link] (18 responses)

> Look at the khtml/webkit story (LGPL).

WebKit isn't a good example here, because it now has plenty of non-Apple developers and has been ported to non-Apple systems; for example, the Qt port of it has been integrated into Qt upstream. If KHTML had been BSD-licensed instead of LGPL-licensed, Apple might have made WebKit proprietary, and none of that would have happened.

It's true that WebKit hasn't been merged back into the original upstream (KHTML). However, there is now kwebkitpart, a KPart-wrapper around Qt WebKit which can be used in Konqueror as an alternative to KHTML.

licence

Posted Apr 28, 2010 6:02 UTC (Wed) by rsidd (subscriber, #2582) [Link] (17 responses)

Yes, webkit developed a community because webkit happened to be useful (and was also a significant improvement on khtml). Apple released Darwin too, though the licence did not require them to; but it was not useful (people already had linux and the BSDs) and it withered. I suspect if gecko hadn't been such a mess, webkit wouldn't have caught on either (indeed, Apple would probably have gone for gecko directly).

In two high-profile cases now (OS X and Safari), Apple has chosen as its base a significantly less popular open-source project (Mach/BSD instead of Linux; khtml instead of gecko) on the grounds that its codebase was cleaner and more maintainable; and the decision has paid off significantly for them, and in the case of khtml/webkit, for the community. Now it looks very much like Apple would like to move to LLVM and eventually dump GCC.

What will they do with LLVM? They can maintain their own tree and dump the upstream, as with webkit, or work with upstream; but in this case, given that LLVM is already a strong project, I suspect they will (continue to) work closely with upstream: their own fork is unlikely to offer compelling value, and diverging from upstream will only make life difficult for themselves. But their choice has nothing to do with the licence. The GPL forces you to release your changes but doesn't force you to play well with others: only your own self-interest can do that.

licence

Posted Apr 28, 2010 8:30 UTC (Wed) by patrick_g (subscriber, #44470) [Link] (7 responses)

>>> Apple has chosen as its base a significantly less popular open-source project (Mach/BSD instead of Linux; khtml instead of gecko) on the grounds that its codebase was cleaner and more maintainable

Mach/BSD cleaner and more maintainable than Linux ? Really ?

licence

Posted Apr 28, 2010 9:07 UTC (Wed) by rsidd (subscriber, #2582) [Link] (6 responses)

>Mach/BSD cleaner and more maintainable than Linux ? Really ?

Remember we're talking about the late 1990s here, when Linux was, frankly, pretty flaky while FreeBSD powered some of the biggest internet servers. But many would say it's still true today. Don't write off the BSDs yet. They continue to get new developer talent partly because the codebase is easier to deal with and the community is friendlier than LKML.

Apple wasn't ignorant of linux: for a while they supported a port of linux to mach/ppc, MkLinux. They just decided it wasn't optimal for them.

licence

Posted Apr 28, 2010 10:07 UTC (Wed) by samb (guest, #32949) [Link] (5 responses)

People like repeating 15-year-old memes.

As late as the late 90s some people were also convinced that FreeBSD would beat out Linux wrt commercial use and contributions due to the 'more business friendly' license.

licence

Posted Apr 28, 2010 10:36 UTC (Wed) by trasz (guest, #45786) [Link]

As of 2010's, some people are convinced that Linux will beat out Windows wrt desktop use. ;->

licence

Posted Apr 28, 2010 10:41 UTC (Wed) by rsidd (subscriber, #2582) [Link] (3 responses)

>people were also convinced that FreeBSD would beat out Linux wrt commercial use

It did, if you count its descendants. Mac OS X installations far outnumber linux by any measure. Are you saying Apple made the wrong decision? Or are you saying that we should be unhappy because it's a proprietary system? Personally I'm happy at the success of OS X because it (a) made Unix more widespread, (b) made web developers realise that there's life beyond Win/IE, (c) gave the Linux desktop something to aim at.

Note, again, that Apple did contribute back their changes and continue to do so (latest release here). The majority of projects there are either Apple's own (APSL) or under the BSD or MIT licenses: in other words, Apple isn't being forced to do this. And if they had chosen to go with linux or another GPL'd system, it would have made no difference: they could have continued to do exactly what they're doing now.

licence

Posted Apr 28, 2010 13:28 UTC (Wed) by pboddie (guest, #50784) [Link]

It did, if you count its descendants. Mac OS X installations far outnumber linux by any measure.

Citation needed! And you presumably really mean desktop/notebook installations (with the iPhone included with a bit of creative interpretation), especially after having read LWN coverage of the embedded scene and how Linux seems to be rather ubiquitous, even amongst the products of large corporations.

licence

Posted Apr 28, 2010 14:03 UTC (Wed) by nye (subscriber, #51576) [Link] (1 responses)

>Mac OS X installations far outnumber linux by any measure

Huh? Have I fallen into bizzarro world? Linux is nearly completely ubiquitous. Almost anyone with an ADSL modem or home router uses it every day. Anyone using a DVR, or a load of other kinds of set-top boxes. Lots of TVs now run Linux, maybe DVD players too. I've seen printers running Linux; hell it even runs on *fridges*. Fridges!

It has a substantial share of the phone market - maybe not as large as the iPhone but not far enough behind to be completely blown away. In fact, if you pick an embedded device at random, there's a better than average chance it'll be running Linux.

In contrast, I would estimate that I've seen less than a dozen machines in the flesh running OS X, *ever*, including phones but excluding iPod shuffles and early generations. If indeed they use OS X, then you can multiply that by a very small integer.

In fact, I can't name any manufacturers making devices based on FreeBSD other than Apple (I'm sure there must be a fair few, especially things like firewalls and NAS devices, but I don't actually know of any). I don't think it can be seriously argued any more that the GPL is an impediment to commercial use of Linux, versus the commercially-friendly BSD licence.

licence

Posted Apr 28, 2010 14:42 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Right. And there are relatively few tosters running NetBSD. Even though this was an explicit target market since 2000 or so.

licence

Posted Apr 28, 2010 13:36 UTC (Wed) by pboddie (guest, #50784) [Link] (2 responses)

Yes, webkit developed a community because webkit happened to be useful (and was also a significant improvement on khtml).

I so like the way Apple advocates like to beautify the achievements of Apple while downplaying the hard work of others. KHTML was a significant piece of work in itself - a competitive browser engine at the time - and perhaps the only reason why there is a (non-Apple) community around WebKit is because the KDE developers chose to license KHTML under the LGPL in the first place. Recalling that there was friction between the KHTML developers and the in-house Apple WebKit developers about collaboration, I imagine that had a permissive licence been chosen, WebKit would have been a purely proprietary affair.

licence

Posted Apr 29, 2010 8:24 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

>I imagine that had a permissive licence been chosen, WebKit would have been a purely proprietary affair.

You mean, like all the other proprietary projects listed here? Apple picked up BSD long before picking up khtml. In both cases, it released sources back (and continues to do so) but did not play nice with upstream. The only difference is, webkit picked up substantial third-party interest while Darwin did not. I argue it is because webkit was in fact a big improvement on khtml. This is not to say khtml was bad (obviously it wasn't, since Apple chose it). And it would have been preferable for Apple to work on improving khtml, but that's not what happened.

licence

Posted Apr 29, 2010 11:38 UTC (Thu) by pboddie (guest, #50784) [Link]

You mean, like all the other proprietary projects listed here? [page showing list of source packages]

Do you expect us to go through those projects removing the ones that are not copyleft-licensed and then bask in the generosity of Apple? Well, looking at the list and choosing a few projects at random, it quickly becomes an issue of assessing (for us and for Apple) whether it's worth the bother of maintaining a proprietary fork.

Take something like python-dateutil, of which I have recent experience: sure, if Apple's employees/lawyers thought it worthwhile to maintain a proprietary version, they'd probably do so, but such work would be fairly unappealing and would not provide any economic or strategic advantage. Why not let the maintainer(s) do the time-consuming and thankless task of making sure such a piece of infrastructure just works? Throw a few patches over the wall every now and again, just to keep the local maintenance burden at a minimum (and to avoid having to patch numerous Python-based packages which depend on it).

In contrast, when you're in desperate need of a Web browser that you can control - noting that Safari is yet another vehicle for standards front-running - there is a real incentive to maintain a proprietary fork if you can. And when you can put many more developers on the fork than there are behind the original project, the incentive to work with that project diminishes.

Finally, given that Apple are quite content to use patents as a form of anticompetitive instrument, is it really so hard to believe that had WebKit been permissively licensed, Apple would not have taken the opportunity to freeze out competitors like Nokia by taking their derived version private? It would surely be cheaper than a bunch of patent lawyers.

licence

Posted Apr 28, 2010 22:29 UTC (Wed) by wmf (guest, #33791) [Link] (2 responses)

Apple is the upstream for LLVM.

licence

Posted Apr 29, 2010 8:19 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

I'm not sure what you mean by that. Apple employs a handful of developers. The project is hosted at UIUC and has developers from all over.

licence

Posted Apr 29, 2010 15:32 UTC (Thu) by daglwn (guest, #65432) [Link]

To be fair, the LLVM leadership is most definitely concentrated at Apple. This causes some amount of friction from time to time.

licence

Posted Apr 29, 2010 5:12 UTC (Thu) by rqosa (subscriber, #24136) [Link] (2 responses)

> Apple has chosen as its base a significantly less popular open-source project (Mach/BSD instead of Linux; khtml instead of gecko) on the grounds that its codebase was cleaner and more maintainable

I don't think that "cleaner and more maintainable" was Apple's reason for choosing Mach/BSD. NeXTSTEP was first released in October 1988, almost three years before Linux 0.01. Then it was rebranded "OPENSTEP for Mach", then "Rhapsody", then "Mac OS X Server 1.0", then "Mac OS X 10.0", etc.

licence

Posted Apr 29, 2010 8:31 UTC (Thu) by rsidd (subscriber, #2582) [Link] (1 responses)

The link is the OpenStep API, which is cross-platform -- not tied to Mach/BSD. Perhaps the NeXT historical connection is why Apple went for a Mach/BSD kernel -- but they did experiment with Mach/Linux too (MkLinux) and in principle could have layered Openstep on top of any OS.

licence

Posted Apr 29, 2010 9:43 UTC (Thu) by paulj (subscriber, #341) [Link]

Avi Tevanian did a lot of the work on Mach at CMU, became a senior technologist at NeXT and then at Appel. He was a primary architect of NexTSTEP and of OS-X.

http://en.wikipedia.org/wiki/Avadis_Tevanian

licence

Posted Apr 28, 2010 19:01 UTC (Wed) by tdz (subscriber, #58733) [Link]

> It would be great if they changed to a copyleft licence.

I'd love to join in in this everlasting classic of flame wars, but I'll rather make some other point: if the LLVM developers would change to GPL, they'd likely scare away a lot of BSD people that support LLVM because it is non-GPL. So they would lose one of their main selling points and compete directly against GCC.

GPL dislikers

Posted Apr 27, 2010 20:06 UTC (Tue) by boog (subscriber, #30882) [Link] (16 responses)

That's quite a number of GPL "dislikers" amongst the comments... on LWN! If the GPL turns out to be unnecessary in the future and open source has already won, then fine. However, the GPL was surely essential in getting us to where we are now, and I for one shall be very glad of the security provided by the continuation of solidly-GPLed projects at the FSF and elsewhere. Just look at the speed with which corporate takeovers can change a project's future.

Those that don't know their history are doomed to repeat its mistakes.:-)

GPL dislikers

Posted Apr 27, 2010 21:01 UTC (Tue) by lmb (subscriber, #39048) [Link] (4 responses)

The GPL family protects freedom; it is an extremely strong license, because you can't ever take something away from its pool, you can only add to it. If you drink from it, you become a water brother. It reminds me of Team America's soundtrack: Freedom is the only choice now.

The BSD license is, in a sense, more free, since it doesn't bother to protect and guarantee any of its freedoms downstream; they aren't passed on.

In the hand of responsible people, both are equivalent for "Open" development. Both allow viable environments and dynamics. But one can be corrupted and abused, and the other one can't.

Of course people prefer the one that they can, theoretically, abuse. It's a question of balance. Personally, I believe the GPL family is stronger: it spreads and assimilates.

GPL dislikers

Posted Apr 27, 2010 22:08 UTC (Tue) by foom (subscriber, #14868) [Link] (3 responses)

With the recent proliferation of GPL licenses, there's now a major problem: lots and lots of code *is* being removed from "the" GPL pool. Because instead of one pool, it's now two partially overlapping pools.

If you're in the GPLv2 pool, you can't reuse code from any project which has transitioned from GPLv2+ to GPLv3+. If you're in the GPLv3 pool, you can't reuse code from any GPLv2 project.

This is not just a theoretical problem...see e.g. libreadline. Now under GPLv3+, so GPLv2-only code can no longer use it....speaking of which...<checks debian..>

Hm, here's a long list of packages that depended on "libreadline5-dev" and were requested to be transitioned...and the notice included no comment on the license change:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=readline6;...

It's extremely likely some of them are GPLv2 only, and therefore, Debian is probably now violating the GPL. Ugh....

And that's not even everything, because some packages have depended only on "libreadline-dev" from the get-go and so may silently migrate to readline6. Bigger Ugh....

GPL dislikers

Posted Apr 27, 2010 22:22 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

If you're in the GPLv3 pool, you can't reuse code from any GPLv2 project.

I think you may be wrong here. Given you've called out GPLv2only separately, you must with GPLv2 mean "GPLv2 or any later version", and GPLv3 is perfectly compatible with any such code, by dint of the upgrade path, obviously.

GPL dislikers

Posted Apr 27, 2010 22:52 UTC (Tue) by foom (subscriber, #14868) [Link] (1 responses)

...sigh. No, I did not mean GPLv2+ when I said GPLv2 there. As you so astutely note, if I had meant GPLv2+ there, then I would have been obviously wrong. So how about instead we assume that I meant "GPLv2" when I wrote "GPLv2", and thus wrote something that is *NOT* obviously wrong.

GPL dislikers

Posted May 2, 2010 22:24 UTC (Sun) by paulj (subscriber, #341) [Link]

Ok sorry about not figuring out that you mean "GPLv2" to be the same as your "GPLv2only" term. However the default for GPLv2 projects (i.e. using the recommended boilerplate) is to be upwardly compatible with GPLv3, and on that basis most GPLv2 code is perfectly compatible with GPLv3.

GPL dislikers

Posted Apr 27, 2010 21:47 UTC (Tue) by cmccabe (guest, #60281) [Link] (8 responses)

Any time you create a software license, you are playing a game of give and take. You give some things up, in hope of getting something back.

Linux kernel hackers license their code under the GPLv2. In return they get a rich ecosystem of servers, devices, and companies using Linux to build products, run servers, and create the Linux desktop environment itself that most of us use daily.

Part of the reason Linux was successful with the GPLv2 is that Linus *specifically* made it clear that:
1) The license would never change, because of the lack of copyright assignment.
2) Userspace programs could be closed source, or any other license.

The licensing regime that the FSF is trying to create with GPLv3, AGPL, and similar projects is too one-sided. Here are just a few of the problems:
1) At any time, upstream could switch to a more restrictive licensing scheme.
2) Tivo-ization, something that's essential to the business plan of many comapnies, is forbidden.

These are just a few of the problems.
Linus and the kernel hackers produced a position statement on the GPLv3 that explains the problems with GPLv3 in detail:
http://thread.gmane.org/gmane.linux.kernel/448894/focus=4...

Faced with such an obviously one-sided deal, most corporations just chose to walk away from the table. They put their resources into projects with less restrictive license regimes.

This is not an academic problem. The company I work at right now will not even consider using GPLv3 software in production. It doesn't matter what I think as a developer-- the legal team has preemptively vetoed it because there are just too many potential liabilities.

Open source software has economics on its side. Companies want to leverage the work of others to get a head start on their own. Once they understand that working well with upstream is the best way to do that, that is what will happen. But in situations where the economic logic is not there, no license in the world will convince them to switch.

The problem with the FSF is that they view licenses as a vehicle for political change. Rather than trying to educate people about the problems with the current patent system, or the political implications of locked-down devices, they are trying to strong-arm companies into compliance with restrictive licensing. But it's just not going to work. This is 2010. We live in a world where for any application you care to name, there are half a dozen competitors with various different licenses.

GPL dislikers

Posted Apr 28, 2010 7:46 UTC (Wed) by nix (subscriber, #2304) [Link] (7 responses)

the legal team has preemptively vetoed it because there are just too many potential liabilities
Of course legal teams did just that with GPLv2 for a long time, until it became clear that using it did not cause the world to end. Legal teams are paranoid by nature: it's their job. It doesn't mean you must assume their paranoia to be justified.

GPL dislikers

Posted Apr 28, 2010 8:14 UTC (Wed) by cmccabe (guest, #60281) [Link] (4 responses)

Just take one specific issue: the patent licensing clauses. This alone is enough to permanently kill any hope that the lawyers would ever accept GPLv3.

(offtopic: Personally, I hope that the Supremes eliminate software patents.)

Some people in this thread seem to be claiming that you shouldn't expect to be able to work on open source projects at your job. In that case, you can pick whatever crazy license you want. I've seen projects that come with the "send me a beer if you use this" license, or similar.

To me, that seems unduly pessimistic. If there is something you really want to do, and it's useful to society, you can probably find a way to do it, at least part time. It might mean taking a lower salary than you could have had elsewhere, but it shouldn't mean working a "McJob" that you hate.

GPL dislikers

Posted Apr 28, 2010 9:13 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

The patent licensing clauses are already there in GPLv2, so if the lawyers reject v3 forever for that reason, they would have rejected v2 as well.

GPL dislikers

Posted Apr 29, 2010 14:42 UTC (Thu) by Trelane (subscriber, #56877) [Link] (2 responses)

It wasn't explicit, though (iirc, this was one motivation for gplv3).

So the lawyers are perhaps not so good at finding implicit requirements?

GPL dislikers

Posted Apr 30, 2010 0:11 UTC (Fri) by cmccabe (guest, #60281) [Link] (1 responses)

Wow, you're right. I didn't realize that the GPLv2 granted an "implicit" patent license until I checked it out today. It's especially surprising to me because software patents didn't start becomnig a big problem in the United States until the State Street Bank decision in 1998, almost a decade after the GPLv2 was published.

I tried to figure out how an "implicit" license differed from an "explicit" one, but I gave up after about half a dozen pages of mind-numbing legalese. Anyway, I think that the Patent Commons Project and the Open Invention Project are much better ways to defend open source against patents than EULA-like licenses.

I also think it's funny that the GPLv3 contains the text "States should not allow patents to restrict development and use of software on general-purpose computers..." It's really rare to find a legal document that tries to tell the State what it should and shouldn't do. I don't know whether to applaud or laugh.

GPL dislikers

Posted Apr 30, 2010 2:48 UTC (Fri) by Trelane (subscriber, #56877) [Link]

"I think that the Patent Commons Project and the Open Invention Project are much better ways to defend open source against patents than EULA-like licenses."

Pardon my ignorance, but how is the GPLv3 (that is explicitly not an end-user license) like an End-User License Agreement?

Perhaps you mean complex? IMHO, it's not nearly as complex nor draconian as most EULAs (yes, I read them). Sure, it's complicated compared to BSD, but its aim is to ensure end-users' freedom as opposed to intermediates' freedom.

I also disagree that holding a patent-busting effort and patent portfolios is the same as ensuring that Free software remains Free. The two aims are complementary. The GPLv3 aims solely to preserve end-user freedoms for software that agrees to use it. The patent-busting and patent portfolio efforts are for those that threaten Free and Open Source Software, which (almost) implies not agreeing to distribute under the GPL or similar end-user protections.

"It's really rare to find a legal document that tries to tell the State what it should and shouldn't do."

That's the Preamble. It lays out the motivation and purpose of the actual license, which follows it. Most licenses don't have such a preamble.

"I don't know whether to applaud or laugh."

I'd go with "applaud" myself. Your aims WRT patents seem to align with the GPL.

GPL dislikers

Posted Apr 28, 2010 10:44 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

+1 on this.

It's very easy for legal counsel to cover its arse and be extremely pessimistic about risks, to the point their advice is unbalanced.

GPL dislikers

Posted Apr 28, 2010 13:41 UTC (Wed) by efexis (guest, #26355) [Link]

"...to the point their advice is unbalanced"

But effective nontheless.

GPL dislikers

Posted Apr 28, 2010 5:56 UTC (Wed) by russell (guest, #10458) [Link] (1 responses)

I wonder what to dislike about getting paid? I either get paid in cash ( non gpl code ) or get paid in code ( gpl code ). Seems crazy to me to like BSD over GPL.

As for those that argue GPL is a difficult license for business. It's suppose to be, it's not a gift.

GPL dislikers

Posted Apr 28, 2010 19:26 UTC (Wed) by daglwn (guest, #65432) [Link]

There are different licenses for different purposes. Assuming a from-scratch project not already bound to a license, a for-profit entity should probably release its code under GPL or LGPL so that anyone else who profits from it must release changes. The same entity would probably prefer to incorporate BSD-style licensed code into its products.

This of course implies that profit is the only motive, which is not always the case.

LLVM 2.7 released

Posted Apr 28, 2010 7:25 UTC (Wed) by adesharatushar@gmail.com (guest, #49449) [Link] (17 responses)

Please remember that GPL is about freedom and freedom not to companies or organizations or distributors but to end users. In theory, GPL allows its end user to make all the changes he wants to the product without anyone's permission or legal issue. And in most cases, reusing as much code from existing product as possible.

Now for this specific case, it is always possible to ask for source code of GCC distributed by any company (even when it is fork) and look at improvements, experiment with it and copy it to main code base. This all can happen with as much reuse of code as possible.

Now compare this with LLVM when some company makes improvement and distributes a fork without source code. First, it prevents end users from making changes (which may be some bug fix important for user but not important for company distributing it). Second, the competitor may require to offer the same improvement, which can result in same code being redeveloped (If the first company didn't make it to mainline, why its competitor should?). And there will be demand from all users to include that to mainline, which can result in one further redevelopment.

Personally as developer and end user, I prefer and trust GPL more then any other license.

LLVM 2.7 released

Posted Apr 28, 2010 18:28 UTC (Wed) by trasz (guest, #45786) [Link] (16 responses)

Now compare it with the situation when a company decides not to invest money into improvements, because the GPL license would force them to immediately give them away to the competition, which would then sell it to customers - and sell it with a lower price, since somebody else paid for developing it.
This is one of the fundamental problems with GPL - it encourages selling stuff written by other people and not giving anything back. With GPL, when you invest into writing code, it's your competition who will get profits, not you. With BSD, when you invest into writing code, it's up to you if you give it away, when, and how much of it.

GPL playing ground

Posted Apr 28, 2010 21:24 UTC (Wed) by man_ls (guest, #15091) [Link] (3 responses)

Right, the GPL makes for a more level playing ground -- even for developers, who do not have an advantage over other users. If developers want to have any leverage they have to earn it. That is why we like it.

GPL playing ground

Posted Apr 29, 2010 18:24 UTC (Thu) by bronson (subscriber, #4806) [Link] (2 responses)

> Right, the GPL makes for a more level playing ground

Let's say you invest a year of your time writing a piece of software and release it under the GPL. Now you and I and everybody else can compete on selling it. Except that you have a one year investment to pay down and I don't. I wouldn't consider that a more level playing field!

So many replies

Posted Apr 29, 2010 20:18 UTC (Thu) by man_ls (guest, #15091) [Link] (1 responses)

Right. Instead, say you release it under a BSD license. Now you and I and everybody else can compete on selling it, and I can make proprietary extensions which I can sell but you (after your one year investment) can't. What's fairer now?

So many replies

Posted Apr 29, 2010 23:51 UTC (Thu) by bronson (subscriber, #4806) [Link]

Neither one is fair. I'm not sure it makes sense to ask which one is more fair -- it depends on your situation.

I'll say this: I'm really glad we have a choice!

LLVM 2.7 released

Posted Apr 28, 2010 21:57 UTC (Wed) by nix (subscriber, #2304) [Link]

It's your competition *and* you who'll get profits. i.e., it's an enforced coalition. Corporations do quite like cooperating in coalitions and combines and cooperatives and so on, even very large corporations. Your belief that this is never true is as tiresome as your following up to every single thread on LWN that ever mentions the GPL with plaints about how the BSD license is better, it is, it is!

LLVM 2.7 released

Posted Apr 29, 2010 0:13 UTC (Thu) by Trelane (subscriber, #56877) [Link]

"With BSD, when you invest into writing code, it's up to you if you give it away, when, and how much of it."

But the end users get no choice with BSD. That's the whole point of GPL: enhance and protect the freedom of the end-user at the expense of the intermediaries' freedom, namely the ability to restrict the end-users. The BSD license gives the intermediate users maximum freedom at the expense of the end users' freedom.

LLVM 2.7 released

Posted Apr 29, 2010 7:41 UTC (Thu) by adesharatushar@gmail.com (guest, #49449) [Link] (9 responses)

"Now compare it with the situation when a company decides not to invest money into improvements, because the GPL license would force them to immediately give them away to the competition, which would then sell it to customers - and sell it with a lower price, since somebody else paid for developing it."

Hmm, so what is the advantage to end users or original developers (who released it under BSD license) even if some company invests the money or not? Because, the source is not going to be released and access to binary will be restricted to certain users only. On the other hand, if company invests money and release it under BSD, its even worst for company, because their competitor can build on it and not release it.

"This is one of the fundamental problems with GPL - it encourages selling stuff written by other people and not giving anything back."

Giving back to whom? To all original developer of (BSD) code which makes up 80-90% of product code base? To all early users who volunteered to be guinea pig and tested the product?

In fact, statement applies to BSD better then GPL. With BSD you profit from selling code written by others and give back nothing (to community). With GPL, you have to at least give back the code (if not part of your profit in form of royalty or license fee).

BSD is not a bad license, its just not as good when it comes to protecting and giving back to community.

And about making profit, today serious buyers won't pay because some one got a product and source code but because they trust that the seller is capable of providing solution to their problems (and at competitive price). Don't agree? Look at companies providing paid support for open source projects.

LLVM 2.7 released

Posted Apr 29, 2010 14:50 UTC (Thu) by trasz (guest, #45786) [Link] (8 responses)

When you base your product on BSD-licensed code, it's your decision if and when you want to give it away. It's an advantage for you - the author of software derived from BSD-licensed code.

"Giving back to whom? To all original developer of (BSD) code which makes up 80-90% of product code base? To all early users who volunteered to be guinea pig and tested the product?"

"Back" means "to the original project", but, since this is Open Source, this means both original developers and end-users.

"With GPL, you have to at least give back the code (if not part of your profit in form of royalty or license fee)."

If you only use the code with as little modifications as possible, you don't have anything to give back. Passing the copy of the unmodified source code is worthless.

As for what buyers pay for - there are markets for both innovative products and for boring proucts with expensive support. GPL is no problem for the latter, that's true. It's a big problem for the former. Take a look at companies like Apple, Juniper, Isilon or NetApp. They live from selling things that you can't get for free; their selling point is the product, not support for the product. If they were forced to give away their code, they would just stop putting serious money into R&D, just like commercial Linux vendors do. That's why they use BSD, not Linux - to not be forced into giving away their code.

LLVM 2.7 released

Posted Apr 29, 2010 16:02 UTC (Thu) by cry_regarder (subscriber, #50545) [Link] (5 responses)

Summary of argument:

Trasz:

"I want to make your code part of my proprietary product. Hence, I need to convince you to release your work under the BSD license."

Process of rhetoric ensues and then:

Convert says to self:

"Hmmm. I have this great piece of code I developed that would make a great library. I really want Microsoft and Oracle and Apple to make lots of money off of it so I'll happily release it under the BSD license. Win Win! I'm sure Microsoft will buy me out!"

Trasz:

Smiles happily and rubs hands together.

Did I understand your point?

Cry

LLVM 2.7 released

Posted Jul 14, 2010 17:05 UTC (Wed) by trasz (guest, #45786) [Link] (4 responses)

No, I'm afraid you don't. BSD version of the story:

- So, there is this nice piece of code I've written; I'm not sure how to make money on it right now, so here it is, under BSD license; do what you want.

- Hey, it would be really useful in this appliance we're working on right now. Btw, we're hiring, and since we want to use the code you've written, so maybe...?

- Sure.

GPL version of the story:

- So, there is this piece of code I've written; I'm not sure how to make money on it right now, so here it is, under GPL license; do what you want.

- Hey, it would be really useful in this appliance we're working on right now - except that the GPL would require us to give away the code we've written to our competitors. Maybe you could relicense it?

- Sorry, I accepted some patches from other people, thus I can't.

- kthxbye, we'll use something else.

LLVM 2.7 released

Posted Jul 14, 2010 23:37 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

the problem with the BSD version is that once you are employed by the company, future updates tend not to go to the BSD licensed version, but instead to the version your company creates under a proprietary license.

Also, the other people who sent you patches, but did NOT get hired may get upset with you and stop sending you patches.

the end result is that the BSD version may start off strong and may become a cornerstone for some proprietary product and the free version languishes and eventually replaced by another project,while the GPL version keeps growing until the company says "we're using this a lot and want to have in-house expertise, we'll hire one of the (many) developers to work for us so that we can get their attention"

How many BSD kernel developers are being paid to work on BSD code vs how many Linux developers are being paid to work on GPL code?

LLVM 2.7 released

Posted Jul 15, 2010 14:32 UTC (Thu) by trasz (guest, #45786) [Link] (2 responses)

If the company doesn't want to release the code under BSD, they probably wouldn't release updates under GPL either - they just wouldn't use that code.

As for your "languishing" scenario - nice theory, but experience shows it just doesn't happen; the BSD projects keep going, from FreeBSD (countless commercial derivatives, from Juniper to these weird Silicon Graphics boxes serving storage to the Linux clusters), to PostgreSQL, to Xorg (MIT is pretty much 2-clause BSD).

As for the numbers - how many MySQL developers are being paid to work on GPL code vs how many PostgreSQL developers are being paid to work on BSD code? Comparing Linux and FreeBSD is not really representative, because Linux is way more popular - it's almost like comparing <insert some GPL windowing system> and Xorg.

LLVM 2.7 released

Posted Jul 16, 2010 5:55 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

if the *BSD projects didn't languash in favor of the proprietary forks Linux probably would not exist today as one of the BSDs would be in it's place.

I think the situation of them vs Linux is a _perfect_ example.

LLVM 2.7 released

Posted Jul 16, 2010 10:52 UTC (Fri) by trasz (guest, #45786) [Link]

So you're claiming that JunOS forced FreeBSD out of core routers, NetApp forced FreeBSD out of high-end NAS, and Apple forced FreeBSD out of desktops and mobile phones. You are aware that this doesn't really match reality, aren't you? ;->

Actually, proprietary forks of FreeBSD didn't replace the vanilla version anywhere. Thus, it's not a good example, just like GPL windowing systems vs BSD windowing systems wouldn't be.

LLVM 2.7 released

Posted Apr 30, 2010 10:27 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (1 responses)

"If you only use the code with as little modifications as possible" then your added value (i.e. the thing that makes your product worth buying) is in hardware, services, or additional non-derivative software.

LLVM 2.7 released

Posted Jul 14, 2010 16:57 UTC (Wed) by trasz (guest, #45786) [Link]

Mostly in as-cheap-as-it's-physically-possible hardware and marketing.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds