Slashdot Mirror

Things to keep in mind:

• Debian measures the "freeness" of software by the Debian Free Software Guideline(DFSG)
• Non-free software as measured by DFSG may be free from a different metric
• Debian != FSF

Have a read of this page if you will be voting. :)

Is the GPL APL-compatible?

The GPL is a well-established license, this new Apache license is not. Consider this: I start a new company, and tell everybody I'm developing a CPU for personal computers. People ask "Is it x86-compatible?", and I respond in a snide tone "is x86 compatible with my chip?

Is the GPL compatible with /any/ other license? No.

You clearly know nothing about the GPL. It is compatible with a lot of licenses.

However, the FSF makes a big deal whenever they think that an open source license isn't GPL-compatible.

That's because there is a lot of GPL-licensed software out there, and it would be useful to combine it with other projects, but a small oversight by somebody drawing up a new license might prevent that.

But that's not what this instance is about. The Apache project were aiming for GPL compatibility, and the FSF merely pointed out a problem in the license that prevented that from happening. They even hinted that they would change the GPL.

If you have an axe to grind with the GPL, fair enough, but please stick to the facts.

The GPL is considered a virus, because it is free as in BEER but not as in FREEDOM. It hooks you in with the "FREE BEER" aspect of the software, but you cannot do anything with that software except look at it, or use it. Don't you dare try to use your creativity to change it, because the greedy authors of the original art think your changes is their art. Its a typical trap license, and for people to bitch about another license being incompatible with a virus just sounds silly. The reality is the Apache License has more liberty packed in a few sentances than the GPL will ever have in its' pages upon pages leagal rehtoric.

The sad thing is all this hinges on giving the authors of software fair credit, which the Apache license belives is fair. Where the GPL belives that mentioning contrinutors, you know that people who add contributiosn to the gpl virus-ware, should get due credit, instead of being put under an umbrella of nameless, forgoten contributors who the author forgets to mention, and thus steals their contributions. This is typical GPL fair. The original author offten steals the contributions and never mentions the source of all the little patches, and alterations they force others to give back to them under the terms of the GPL, because the GPL license says listing authors is an incompatiblity.

You don't belive me? Well read for yourself at the GPL website: http://www.gnu.org/philosophy/bsd.html. They spell it out very clearly that listing authors gets in the way of their eventual theft.

``You can probably build a non https:// Apache without a few other modules that is GPLable but everyone I've dealt with seems quite happy with the state of apache and the license it uses right now.''

Or even one that does https using GNU TLS.

Personally, I read the ASL2.0 to be GPL-incompatible, due to extra requirements for distribution. I don't care much, though. If you want to link stuff with Apach, it's Apache-specific anyway, so giving it an Apache-specific license wouldn't hurt too much.

I counter with this atrocious web design.

I can't seem to find the page that explains what they mean about 'parallel'. There was a lot more explanation on these items on their website a couple years ago when I last engaged in lengthy discussions on these issues. But, as I remember, they explained that 'parallel' ment that you could release it as two different licenses (thus dual-licensing) IF you setup both licenses in parallel -- but you could not first make it GPL then later also license it as BSD, for example. It had to be done at the same time, and even that they discouraged. Perhaps those rules have changed, I don't know -- their lengthy explanations have all been shrunken down to one or two sentences.

I think part of the problem is that I seem to remember the GPL/FSF taking over the copyright. Perhaps it was a common mistake, some bit that changed over time, or perhaps it was specific to some FSF/Apache project I was working on. I don't honestly remember. But I can not seem to find any reference to such a condition at this point.

The difference with the GPL and LGPL is how it is used by other software. For example, if I were to write some application using the Apache license, I *could* link to a LGPL library, but NOT to a GPL library.

It does appear that Cygwin has changed their licensing information. The last time I had checked, it had said that you had to either be GPL or Proprietary. Now, instead of GPL-specifically, it is linking to OSI. However, the issue still remains that LGPL will allow a proprietary program (or ANY non-GPL compatible license) to link to it, whereas the GPL'd cygwin does not.

You mentioned a few companies that allow the use of GPL. Some of the companies that have told me not to were Apache (when working on Ant), Intel, jBASE, Temporal Wave, etc. Interestingly enough, I do not think Sun does allow it, as per the JCP.

I am really glad you have given extensive thought to this conversation, instead of just flaming my original post as I expected would happen. I do have a license that I am currently writing all of my code against, and can provide you the URL via email (don't want it slashdotted) if you are interested in providing feedback regarding it.

You really ought to check out GNU Screen, which AFAIK comes with OS X by default. Screen allows you to run a number of shells or other interactive programs in a single terminal, sort of like having tabbed interface. However, Screen gives you all kinds of extra goodies with this--you can lock your session, detach it and reattach from anywhere, monitor "tabs" for silence or activity, split the terminal between one or more tabs, and so on. Better than "tabbed" terminals by far.

That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule.

• CMU CL: natively compiled
• SBCL: natively compiled
• MCL: natively compiled
• OpenMCL: natively compiled
• Xanalys LispWorks: natively compiled
• Allegro Common Lisp: natively compiled
• Corman Common Lisp: natively compiled
• Scieneer Common Lisp: natively compiled
• Embeddable Common Lisp: natively compiled, via GCC
• GNU Common Lisp: natively compiled, via GCC
• GNU CLISP: bytecode compiled
• Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor

If your statement is really true, isn't that quite a bit constraining to linux kernel development? This should not be a anti-BK-rant (I never used BK and can't say anything about it's qualities), but I think this would be a good argument against it. In the M$/SCO world, one expects such NDAs. But not in the Linux world.

This is exactly my concern. There is even this question: Do you anticipate implementing a source management system in the next: [Please select] on BitKeeper's download form, where providing your real name and email address is mandatory.

Let me quote Bitkeeper issue from Linux, GNU, and freedom by Richard M. Stallman:

[...]

Bitkeeper issue

The use of Bitkeeper for the Linux sources has a grave effect on the free software community, because anyone who wants to closely track patches to Linux can only do it by installing that non-free program. There must be dozens or even hundreds of kernel hackers who have done this. Most of them are gradually convincing themselves that it is ok to use non-free software, in order to avoid a sense of cognitive dissonance about the presence of Bitkeeper on their machines. What can be done about this?

One solution is to set up another repository for the Linux sources, using CVS or another free version control system, and arranging to load new versions into it automatically. This could use Bitkeeper to access the latest revisions, then install the new revisions into CVS. That update process could run automatically and frequently.

The FSF cannot do this, because we cannot install Bitkeeper on our machines. We have no non-free systems or applications on them now, and our principles say we must keep it that way. Operating this repository would have to be done by someone else who is willing to have Bitkeeper on his machine, unless someone can find or make a way to do it using free software.

The Linux sources themselves have an even more serious problem with non-free software: they actually contain some. Quite a few device drivers contain series of numbers that represent firmware programs to be installed in the device. These programs are not free software. A few numbers to be deposited into device registers are one thing; a substantial program in binary is another.

The presence of these binary-only programs in ``source'' files of Linux creates a secondary problem: it calls into question whether Linux binaries can legally be redistributed at all. The GPL requires ``complete corresponding source code,'' and a sequence of integers is not the source code. By the same token, adding such a binary to the Linux sources violates the GPL.

The Linux developers have a plan to move these firmware programs into separate files; it will take a few years to mature, but when completed it will solve the secondary problem; we could make a ``free Linux'' version that doesn't have the non-free firmware files. That by itself won't do much good if most people use the non-free ``official'' version of Linux. That may well occur, because on many platforms the free version won't run without the non-free firmware. The ``free Linux'' project will have to figure out what the firmware does and write source code for it, perhaps in assembler language for whatever embedded processor it runs on. It's a daunting job. It would be less daunting if we had done it little by little over the years, rather than letting it mount up. In recruiting people to do this job, we will have to overcome the idea, spread by some Linux developers, that the job is not necessary.

Linux, the kernel, is often thought of as the flagship of free software, yet its current version is partially non-free. How did this happen? This problem, like the decision to use Bitkeeper, re

It's not that you can "ONLY make GPL software" -- it's just that you have to allow a GPLed version (this is called being "GPL compatible"). The GPL never stops you from allowing others to do things with code you own the copyright to. So in our example, if you write a public domain library on top of object.java, you can let 3rd parties write proprietary apps with it; they just have to make sure that they have met the licensing requirements for any java stuff they use (perhaps by paying Sun a license fee, or using someone else's version of Java).

Accoding to this section of the FAQ, software written on top of GPL can only be GPL. It specifically says that, if the Object.java were released under GPL, then the code built on top of it can only be released as GPL (thus you could not write a public domain program on top of Object.java). Also, according to this section, it says you CAN NOT include GPL software in a proprietary system.

I think you have an oversimplified notion of benefit to the community. Community benefit is a complicated function of what code gets written, how much money developers are able to earn to support their coding, and how code is openly available to be improved or incorporated in new projects.

Honestly, I feel that your points are EXACTLY the reasons why GPL should NOT be chosen. First, the making money off the code. I showed in my previous comments (about the charity), GPL is not the best vehicle for that. Second, in regards to code being openly available to be improved or incorporated -- that is specifically the reason why most companies do NOT go with GPL -- it is NOT open to be improved or incorporated. That is the biggest problem with the GPL. The way it is designed, as shown before, GPL causes people to rewrite/reinvent it from scratch instead of improving or implementing it. That is the main contention I have with GPL. Not only has no company EVER been willing to let me use GPL code in ANY product they released (even the free as in money ones), I was not even allowed to pull up their webpages or source code to LEARN from it. Any license that discourages learning needs serious overhaul. If all current GPL code was in the Public Domain, for example, I, for one, would probably know how to implement a hell of a lot more algorithms that I currently do. And I am sure there are a lot of people out there who study GPL code anyways, but that goes against the GPL licensing.

Dual GPL/proprietary licensing (as used by, for example MySQL or QT) allows some developers to simultaneously earn revenue and produce free software. GPLed libraries encourage people who are tossing up between open or closed source development, to take the open route, because it's cheaper -- you can use more of the existing tools. If your management doesn't like the GPL, it shouldn't be too hard to get them to cough up the fee for the alternative license.

What you are talking about is dual licensing. This section explains that you can ONLY dual license if it is done at the beginning. You can not later choose to add another license to the already-GPL'd program. This is an issue I actually came up against in the workplace. We were looking at using cygwin to make some proprietary unix apps into windows apps. At the time, cygwin was offered under two licenses: GPL and $Money. We were hoping for LGPL, since we were linking against it, but not touching their code. Their webpage had a FAQ explaining that if you could not use the GPL version for whatever reason, you had to buy a license (which I think was per-install). Since the company was not willing to do that (prob. because of

It's not that you can "ONLY make GPL software" -- it's just that you have to allow a GPLed version (this is called being "GPL compatible"). The GPL never stops you from allowing others to do things with code you own the copyright to. So in our example, if you write a public domain library on top of object.java, you can let 3rd parties write proprietary apps with it; they just have to make sure that they have met the licensing requirements for any java stuff they use (perhaps by paying Sun a license fee, or using someone else's version of Java).

Accoding to this section of the FAQ, software written on top of GPL can only be GPL. It specifically says that, if the Object.java were released under GPL, then the code built on top of it can only be released as GPL (thus you could not write a public domain program on top of Object.java). Also, according to this section, it says you CAN NOT include GPL software in a proprietary system.

I think you have an oversimplified notion of benefit to the community. Community benefit is a complicated function of what code gets written, how much money developers are able to earn to support their coding, and how code is openly available to be improved or incorporated in new projects.

Honestly, I feel that your points are EXACTLY the reasons why GPL should NOT be chosen. First, the making money off the code. I showed in my previous comments (about the charity), GPL is not the best vehicle for that. Second, in regards to code being openly available to be improved or incorporated -- that is specifically the reason why most companies do NOT go with GPL -- it is NOT open to be improved or incorporated. That is the biggest problem with the GPL. The way it is designed, as shown before, GPL causes people to rewrite/reinvent it from scratch instead of improving or implementing it. That is the main contention I have with GPL. Not only has no company EVER been willing to let me use GPL code in ANY product they released (even the free as in money ones), I was not even allowed to pull up their webpages or source code to LEARN from it. Any license that discourages learning needs serious overhaul. If all current GPL code was in the Public Domain, for example, I, for one, would probably know how to implement a hell of a lot more algorithms that I currently do. And I am sure there are a lot of people out there who study GPL code anyways, but that goes against the GPL licensing.

Dual GPL/proprietary licensing (as used by, for example MySQL or QT) allows some developers to simultaneously earn revenue and produce free software. GPLed libraries encourage people who are tossing up between open or closed source development, to take the open route, because it's cheaper -- you can use more of the existing tools. If your management doesn't like the GPL, it shouldn't be too hard to get them to cough up the fee for the alternative license.

What you are talking about is dual licensing. This section explains that you can ONLY dual license if it is done at the beginning. You can not later choose to add another license to the already-GPL'd program. This is an issue I actually came up against in the workplace. We were looking at using cygwin to make some proprietary unix apps into windows apps. At the time, cygwin was offered under two licenses: GPL and $Money. We were hoping for LGPL, since we were linking against it, but not touching their code. Their webpage had a FAQ explaining that if you could not use the GPL version for whatever reason, you had to buy a license (which I think was per-install). Since the company was not willing to do that (prob. because of

It's not that you can "ONLY make GPL software" -- it's just that you have to allow a GPLed version (this is called being "GPL compatible"). The GPL never stops you from allowing others to do things with code you own the copyright to. So in our example, if you write a public domain library on top of object.java, you can let 3rd parties write proprietary apps with it; they just have to make sure that they have met the licensing requirements for any java stuff they use (perhaps by paying Sun a license fee, or using someone else's version of Java).

Accoding to this section of the FAQ, software written on top of GPL can only be GPL. It specifically says that, if the Object.java were released under GPL, then the code built on top of it can only be released as GPL (thus you could not write a public domain program on top of Object.java). Also, according to this section, it says you CAN NOT include GPL software in a proprietary system.

I think you have an oversimplified notion of benefit to the community. Community benefit is a complicated function of what code gets written, how much money developers are able to earn to support their coding, and how code is openly available to be improved or incorporated in new projects.

Honestly, I feel that your points are EXACTLY the reasons why GPL should NOT be chosen. First, the making money off the code. I showed in my previous comments (about the charity), GPL is not the best vehicle for that. Second, in regards to code being openly available to be improved or incorporated -- that is specifically the reason why most companies do NOT go with GPL -- it is NOT open to be improved or incorporated. That is the biggest problem with the GPL. The way it is designed, as shown before, GPL causes people to rewrite/reinvent it from scratch instead of improving or implementing it. That is the main contention I have with GPL. Not only has no company EVER been willing to let me use GPL code in ANY product they released (even the free as in money ones), I was not even allowed to pull up their webpages or source code to LEARN from it. Any license that discourages learning needs serious overhaul. If all current GPL code was in the Public Domain, for example, I, for one, would probably know how to implement a hell of a lot more algorithms that I currently do. And I am sure there are a lot of people out there who study GPL code anyways, but that goes against the GPL licensing.

Dual GPL/proprietary licensing (as used by, for example MySQL or QT) allows some developers to simultaneously earn revenue and produce free software. GPLed libraries encourage people who are tossing up between open or closed source development, to take the open route, because it's cheaper -- you can use more of the existing tools. If your management doesn't like the GPL, it shouldn't be too hard to get them to cough up the fee for the alternative license.

What you are talking about is dual licensing. This section explains that you can ONLY dual license if it is done at the beginning. You can not later choose to add another license to the already-GPL'd program. This is an issue I actually came up against in the workplace. We were looking at using cygwin to make some proprietary unix apps into windows apps. At the time, cygwin was offered under two licenses: GPL and $Money. We were hoping for LGPL, since we were linking against it, but not touching their code. Their webpage had a FAQ explaining that if you could not use the GPL version for whatever reason, you had to buy a license (which I think was per-install). Since the company was not willing to do that (prob. because of

Linus wants a distributed system, which Bitkeeper is.

Did Linus evaluate GNU Arch? If so, what did he find wrong with it? One of the goals of Arch is to replace Bitkeeper. Yes, there exists one known feature that Arch lacks compared to BK, namely copying files within a repository while forking its change history, but why did Linus find this a showstopper? Or has Arch progressed rapidly since the BK decision?

There is always GNU arch. It's got some nice features that subversion does not have to boot! Such as distributed repositories, advanced merging, and GPG signed patches.

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. I mean are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Don't you wish you could get one of these? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

Section1: But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Ok, so what is the problem here? That means that if Object.java were GPL, every single Object in the Java Programming Language would also have to be GPL, every program that uses Java, etc. Therefore, is Object.java were made GPL, you could ONLY make GPL software. Most companies are not willing to do that, because it imposes restrictions on how they use THEIR code. Many software developers (BSD, Apache, etc) are not willing to do that either, for the same reason. If I **ever** want to make my code Public Domain, say, it can NEVER be GPL first. Public Domain is the ONLY true Public license, with the various Open Source licenses being derivatives.

Section2:Because it imposes a specific requirement that is not in the GPL; namely, the requirement on advertisements of the program. The GPL states: You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This one seems like a good idea at first, but then you take a closer look. What this is really saying is that the GPL license prevents you from extending the license in any way. For example, let's say you wanted to write some application for a charity. Let's say you want to ensure that the charity gets money for said application. If the license is GPL, you can not. If it is something else, say an extension to the BSD license, you could add a clause saying that 1% of any proceeds received directly from the sale of this software must go to said charity. Ok, perhaps not a realistic situation, but the issue is there. The ability to extend a license to cover a specific need is the freedom the author has if he does NOT choose GPL.

Section3: You cannot incorporate GPL-covered software in a proprietary system....A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all....

This one is the WORST. Let's use an example. Let's say that I write some new 'find/grep'-like program that is ultra fast -- I mean, 10 times faster than ANYTHING in current use. What is the best possible scenario FOR THE COMMUNITY? The best scenario is if it is used EVERYWHERE. I mean, used as a replacement for *nix grep, used as a replacement for the Windows find (which, get real, needs improvements), perhaps even a replacement for some of Google's code. Why is this the best scenario? Easy, it makes everything faster for everyone. Everyone in the entire world can benefit from the program you wrote.

If, however, you release that little find utility as GPL, only Linux is likely to use it. Netware wouldn't. OS/2 wouldn't. Windows wouldn't. Google wouldn't. IE: only a few benefit from the speed-improvement. That really has not helped the community much at all.

And, let's take it a step further. Let's say **I** wrote it. And let's say I get hired on to write it for some BeOS version 8. Well, that's great! Except, I have to be careful NOT to use the code I already wrote, rewrite it from scratch and make sure it doesn't seem similar in code (SCO anyone?) -- ie: I have to reinvent the wheel AGAIN. And so does anyone else who wants to use that type of program and can't use GPL for one reason or another (perhaps because they work at almost any US business, since they rarely allow it). Using GPL reduces the chance of it gaining widespread usage and increases the chance of the wheel being reinvented again and again and again. It doesn't help the community, but instead harms it.

I for one would much rather see ALL source code Public Domain than GPL. At least then we are guaranteed to have something everyone can use.

Section1: But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Ok, so what is the problem here? That means that if Object.java were GPL, every single Object in the Java Programming Language would also have to be GPL, every program that uses Java, etc. Therefore, is Object.java were made GPL, you could ONLY make GPL software. Most companies are not willing to do that, because it imposes restrictions on how they use THEIR code. Many software developers (BSD, Apache, etc) are not willing to do that either, for the same reason. If I **ever** want to make my code Public Domain, say, it can NEVER be GPL first. Public Domain is the ONLY true Public license, with the various Open Source licenses being derivatives.

Section2:Because it imposes a specific requirement that is not in the GPL; namely, the requirement on advertisements of the program. The GPL states: You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This one seems like a good idea at first, but then you take a closer look. What this is really saying is that the GPL license prevents you from extending the license in any way. For example, let's say you wanted to write some application for a charity. Let's say you want to ensure that the charity gets money for said application. If the license is GPL, you can not. If it is something else, say an extension to the BSD license, you could add a clause saying that 1% of any proceeds received directly from the sale of this software must go to said charity. Ok, perhaps not a realistic situation, but the issue is there. The ability to extend a license to cover a specific need is the freedom the author has if he does NOT choose GPL.

Section3: You cannot incorporate GPL-covered software in a proprietary system....A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all....

This one is the WORST. Let's use an example. Let's say that I write some new 'find/grep'-like program that is ultra fast -- I mean, 10 times faster than ANYTHING in current use. What is the best possible scenario FOR THE COMMUNITY? The best scenario is if it is used EVERYWHERE. I mean, used as a replacement for *nix grep, used as a replacement for the Windows find (which, get real, needs improvements), perhaps even a replacement for some of Google's code. Why is this the best scenario? Easy, it makes everything faster for everyone. Everyone in the entire world can benefit from the program you wrote.

If, however, you release that little find utility as GPL, only Linux is likely to use it. Netware wouldn't. OS/2 wouldn't. Windows wouldn't. Google wouldn't. IE: only a few benefit from the speed-improvement. That really has not helped the community much at all.

And, let's take it a step further. Let's say **I** wrote it. And let's say I get hired on to write it for some BeOS version 8. Well, that's great! Except, I have to be careful NOT to use the code I already wrote, rewrite it from scratch and make sure it doesn't seem similar in code (SCO anyone?) -- ie: I have to reinvent the wheel AGAIN. And so does anyone else who wants to use that type of program and can't use GPL for one reason or another (perhaps because they work at almost any US business, since they rarely allow it). Using GPL reduces the chance of it gaining widespread usage and increases the chance of the wheel being reinvented again and again and again. It doesn't help the community, but instead harms it.

I for one would much rather see ALL source code Public Domain than GPL. At least then we are guaranteed to have something everyone can use.

Section1: But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

Ok, so what is the problem here? That means that if Object.java were GPL, every single Object in the Java Programming Language would also have to be GPL, every program that uses Java, etc. Therefore, is Object.java were made GPL, you could ONLY make GPL software. Most companies are not willing to do that, because it imposes restrictions on how they use THEIR code. Many software developers (BSD, Apache, etc) are not willing to do that either, for the same reason. If I **ever** want to make my code Public Domain, say, it can NEVER be GPL first. Public Domain is the ONLY true Public license, with the various Open Source licenses being derivatives.

Section2:Because it imposes a specific requirement that is not in the GPL; namely, the requirement on advertisements of the program. The GPL states: You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This one seems like a good idea at first, but then you take a closer look. What this is really saying is that the GPL license prevents you from extending the license in any way. For example, let's say you wanted to write some application for a charity. Let's say you want to ensure that the charity gets money for said application. If the license is GPL, you can not. If it is something else, say an extension to the BSD license, you could add a clause saying that 1% of any proceeds received directly from the sale of this software must go to said charity. Ok, perhaps not a realistic situation, but the issue is there. The ability to extend a license to cover a specific need is the freedom the author has if he does NOT choose GPL.

Section3: You cannot incorporate GPL-covered software in a proprietary system....A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all....

This one is the WORST. Let's use an example. Let's say that I write some new 'find/grep'-like program that is ultra fast -- I mean, 10 times faster than ANYTHING in current use. What is the best possible scenario FOR THE COMMUNITY? The best scenario is if it is used EVERYWHERE. I mean, used as a replacement for *nix grep, used as a replacement for the Windows find (which, get real, needs improvements), perhaps even a replacement for some of Google's code. Why is this the best scenario? Easy, it makes everything faster for everyone. Everyone in the entire world can benefit from the program you wrote.

If, however, you release that little find utility as GPL, only Linux is likely to use it. Netware wouldn't. OS/2 wouldn't. Windows wouldn't. Google wouldn't. IE: only a few benefit from the speed-improvement. That really has not helped the community much at all.

And, let's take it a step further. Let's say **I** wrote it. And let's say I get hired on to write it for some BeOS version 8. Well, that's great! Except, I have to be careful NOT to use the code I already wrote, rewrite it from scratch and make sure it doesn't seem similar in code (SCO anyone?) -- ie: I have to reinvent the wheel AGAIN. And so does anyone else who wants to use that type of program and can't use GPL for one reason or another (perhaps because they work at almost any US business, since they rarely allow it). Using GPL reduces the chance of it gaining widespread usage and increases the chance of the wheel being reinvented again and again and again. It doesn't help the community, but instead harms it.

I for one would much rather see ALL source code Public Domain than GPL. At least then we are guaranteed to have something everyone can use.

Perhaps there needs to be a cohesive international set of laws for such matters.

There is! Thats what these guys got us! (or rather got those who use intelectial property protection, which is among others, is us slashdot readers)

Just becouse big lobbying coorporations think "their" copyright laws are "broken in this post napster age", doesn`t mean copyright protection and other "intelectual property" laws are an unorganized/broken mess. If only human right laws where as well maintained and enforced internationally as "intelectual property" laws...

It would be interesting to watch two western cop`s, one going after a chines knockoff manufacturer and another after chinese refugee smuggeling organisation. I am not saying one will have succes and the other not. I am saying It will be intersting to watch by who either one is helped or obstructed.

Part of the material that will be made available at the conference is available already, if anyone wants to get a head start.

...and me with mod points.

i never thought i would quote linus torvalds, but in this case, you are a weasel.

you're right to say that the GPL does not have the word 'obfuscate' in it.

you're wrong in that code obfuscation is deliberately making something into an unpreferred form, namely, a form where it is not clear what the hell is going on, and hence effective/correct changes are difficult to make. how much more explcit do you want it to be?

as analogy (and normally i hate argument by analogy, it substitutes intuition for proof) no law (where i am, at least) explicitly forbids you from pointing a loaded firearm in my direction, either, but it's not something you're allowed to do (where i am, at least), and something that even morons can figure out you're not supposed to do, which is why they're not locked up.

damn ac's...such a necessary evil...

Is it any wonder people think Linux users are a bunch of flaming homosexuals when its fronted by obviously gay losers like these?! BSD has a mascot who leaves us in no doubt that this is the OS for real men! If Linux had more hot chicks and gorgeous babes then maybe it would be able to compete with BSD! Hell this girl should be a model!

Linux is a joke as long as it continues to lack sexy girls like her! I mean just look at this girl! Doesn't she excite you? I know this little hottie puts me in need of a cold shower! This guy looks like he is about to cream his pants standing next to such a fox. As you can see, no man can resist this sexy little minx. I mean are you telling me you wouldn't like to get your hands on this ass?! Wouldn't this just make your Christmas?! Yes doctor, this uber babe definitely gets my pulse racing! Oh how I envy the lucky girl in this shot! Linux has nothing that can possibly compete. Come on, you must admit she is better than an overweight penguin or a gay looking goat! Wouldn't this be more liklely to influence your choice of OS?

With sexy chicks like the lovely Ceren you could have people queuing up to buy open source products. Could you really refuse to buy a copy of BSD if she told you to? Don't you wish you could get one of these? Personally I know I would give my right arm to get this close to such a divine beauty!

Don't be a fag! Join the campaign for more cute open source babes today!

It's best told here

To earn some cash to fund development of the language, perhaps? The idea is something like: those who write proprietary apps contribute to the common good in cash; those who write free software contribute in kind.

If just the Object class was GPL'd, no one could write truly free open-source (say, BSD) java programs.

Why not? The modified BSD license is GPL compatible.

From the article:
"only four of 10 movies earn enough at the box office to recoup"(the money)"spent on producing and marketing a film"

Look, they're saying about box office. Now from the 60 minutes about internet movie "piracy":

"Fifty percent of the revenues for any movie come out of home video"

The quote from the first article gives the impression that most movies are not profitable.
Does anyone also think they were manipulating numbers there?

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goat.cx. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Look, it's all right there in the GNU Manifesto which is the basis for GNU software so prevalent in Open Source. Rather than going over it with you, I shall refer you to that excellent treatise on why software should be free.

FSF has said they will later publish some statistics from 'GPL compliance lab' like a number of GPL infringement cases they have so far settled out of courts. I guess there must be plenty of them already all over the world. For some unknown reason they have already given more GPL enforcement information in their _proprietary_ seminar tagged for hunders of bucks... free as in freedom, not as in...

Depends on Sun? You don't want JRE from Sun? Download it from IBM (http://alphaworks.ibm.com/java).

Still wrong? Try Blackdown (http://www.blackdown.org/.

Still not satisfied? You could try running it with GCJ (licensed GPL, http://gcc.gnu.org/java/, and probably succeed after some tweaking.

--Coder

Disallowing patented code I see as reasonable, since I see that as one of the biggest potential future challenges the GPL will face - What happens when something like the Unisys mess happens, with code that has used the GPL for 10 years? Substantially violating the spirit of the GPL, I do not see as acceptible. Something like restricting it to non-commercial or non-military use gets a bit more messy, but the way I see it, letting someone use the GPL as the core of their license at least allows a stable underlying framework, and reduces the potential for having a hellish tangle of conflicting licenses (ie, would you rather read 27 pages of "Fred's semi-open license V3.1", or "GPL, with the exception that you can't use it for blah"?).

And what exactly is stopping you from doind this today? HINT: Mail::Sender module's man page:

COPYRIGHT

Copyright (c) 1997-2002 Jan Krynicky . All rights reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.* There is only one aditional condition, [sic] you may NOT use this module for SPAMing! NEVER! (see http://spam.abuse.net/ for definition) [emphasis added].

*Perl itself may be copied only under the terms of either the Artistic License or the GNU General Public License, which means that the effective license of Mail::Sender is either the Artistic License with the added restriction or the GPL with said restriction. This is a restriction on use, mind you, which means that the Mail::Sender's license is an EULA, so it's even much more than what you are complaining about. Now, you might say that spamming is illegal anyway, or if you know Jenda that he himself doesn't give a flying fuck about spamming and this is why this very module was born in the first place, but still this is a clear example that what you imply is impossible, is in fact not only possible, but also being used for years.

Of course I might have failed to understand your real concerns, in which case please clarify what is your real problem with the GNU General Public License. (Of course I assume you have read it.)

Speaking about the advertising clause of original BSD-style licenses, I believe that changing the GPL to make them GPL-compatible would be unwise at least. That would cause the same problems as invariant sections in works covered by GNU FDL, while targetting a much less important issue. I highly urge you to consider this.

I'd like to see a clause in GPL3 that says something like "All patented contributions must be freely licensed for this work and automatically so for any legally derived works."

Congraulations. That clause is already in the GPL and always has been AFAIK. It is in the Preamble and in section 7 of the Terms and Conditions. To wit:

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

...

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

I've heard (though not tried) that Freenet can be compiled using GCJ, the GNU Compiler for Java, to native machine code. In other words, you lose the Java overhead.

Welcome to the new world of Open Source, courtesy of the GNU Manifesto.

Good God, I'm sorry about the formatting on that. LiveJournal rots the brain. Those auto-linebreaks are evil, and I should have previewed.

Sweet Jesus, have you ever read the GPL? More to the point, have you tried reading any document purporting to be a software use license? The GPL is a beacon of simplicity.

Yes, we do in fact need the very slight complexity introduced by documents like the GPL in order for the meaning to be clear. For example, where is "source code" defined in the first draft of your license? It could be successfully argued that a modified version of your program, compiled, then decompiled, then run through an obfuscator would constitute compliance with your license. The GPL includes a simple definition: Source code is "the preferred form of the work for making modifications to it". A second sentence in that paragraph clarifies that we're talking about the whole thing, not just diffs -- and it means Makefiles, too. (Would you like to try compiling the Linux kernel without Makefiles?) The third sentence in that paragraph clarifies that you don't need to provide something which you may not be able to provide -- source code for "anything that is normally distributed... with the major components... of the operating system on which the executable runs" (for example, Vim for MS Windows).

Going back to your license, it's not even clear to me that it's required to distribute source code to the program, not even for derived works.

Basically, the entire thirteen-clause document is like this. It states what is required, in a nutshell, and then clarifies what was said so that it is as precise as possible.

Think of legal matters the same as you think of programming. You can't just tell the computer, "Put a window on the screen." You have to tell it where, and what it's supposed to contain, and at lower levels (xlibs, MFC, or whatever) what a window is, how to draw it, and so on. The main problem is that language is horribly imprecise, especially for purposes like these. This is why licenses and contracts tend to start out with at least a paragraph or two defining what certain terms, as used in the document, will mean.

I'm not trying to be grouchy or come across as condescending, but legal matters do take a suprising amount of work to get right. Don't misunderstand me, though, IANAL or an apologist for one.

Sweet Jesus, have you ever read the GPL? More to the point, have you tried reading any document purporting to be a software use license? The GPL is a beacon of simplicity. Yes, we do in fact need the very slight complexity introduced by documents like the GPL in order for the meaning to be clear. For example, where is "source code" defined in the first draft of your license? It could be successfully argued that a modified version of your program, compiled, then decompiled, then run through an obfuscator would constitute compliance with your license. The GPL includes a simple definition: Source code is "the preferred form of the work for making modifications to it". A second sentence in that paragraph clarifies that we're talking about the whole thing, not just diffs -- and it means Makefiles, too. (Would you like to try compiling the Linux kernel without Makefiles?) The third sentence in that paragraph clarifies that you don't need to provide something which you may not be able to provide -- source code for "anything that is normally distributed... with the major components... of the operating system on which the executable runs" (for example, Vim for MS Windows). Going back to your license, it's not even clear to me that it's required to distribute source code to the program, not even for derived works. Basically, the entire thirteen-clause document is like this. It states what is required, in a nutshell, and then clarifies what was said so that it is as precise as possible. Think of legal matters the same as you think of programming. You can't just tell the computer, "Put a window on the screen." You have to tell it where, and what it's supposed to contain, and at lower levels (xlibs, MFC, or whatever) what a window is, how to draw it, and so on. The main problem is that language is horribly imprecise, especially for purposes like these. This is why licenses and contracts tend to start out with at least a paragraph or two defining what certain terms, as used in the document, will mean. I'm not trying to be grouchy or come across as condescending, but legal matters do take a suprising amount of work to get right. Don't misunderstand me, though, IANAL or an apologist for one.

He is firm on proprietary software; he won't use anything that doesn't given him the freedoms he considers important. But the GPL is designed not merely to provide those freedoms, but to aid in getting those freedoms to other works.

The original BSD license.
This is a simple, permissive non-copyleft free software license with a serious flaw: the ``obnoxious BSD advertising clause''. The flaw is not fatal; that is, it does not render the software non-free. But it does cause practical problems, including incompatibility with the GNU GPL.

We urge you not to use the original BSD license for software you write. If you want to use a simple, permissive non-copyleft free software license, it is much better to use the modified BSD license or the X11 license. However, there is no reason not to use programs that have been released under the original BSD license.

Is it that hard for GPL fanatics to understand that some people don't WANT protection against people using their code in proprierty projects?

The GPL does not stop you from using code in a proprietary project. It just states that if your are going to do so, you must make the GPL-derived portion of that project availible.

Is that so hard to understand?

BSD style license give freedom, but no security. GPL gives limited freedom, but great security. Wasn't it one of the founding fathers of the US who said "those who are willing to give up a liberty for security deserve neither"?

The GPL is about protecting freedom. It prevents companies like Microsoft from taking your code, making it incompatible, and cramming it back down your throat in closed-source form. (Read a little bit on the history of the web browser to see why this is a good idea.) The BSD liscense doesn't give a crap about "freedom" it says "here's this code, have fun".

Really, if you ask me, GPL is the problem here, since it wants all other licenses in the world to be GPL.

No, it doesn't which is why we have this story in the first place. There are plenty of other liscense out there that are "GPL compatible." The BSD license (modified version) would be an example of this. HERE is a list of them.

Exactly! Why all the hullabaloo all of a sudden? The Apache license and many others have long been incompatibile with the GPL, that does not make them any less free. I was under the impression that we "elected" the OSI to be the final arbiter of what is and is not an open source license.

BTW, surf over to gnu.org and take a look at the long list of GPL incompatible licenses. These include Apache, Mozilla, PHP, Zope, Apple, and more. Again I ask, why all the excitement?

Does this mean that the act of programmers working for free, giving away their hard work is slowly being realized as not a viable business model? Sure, we'd all love to live in a Richard Stallman world where we never had to work, where our robots did our menial tasks, and where we could simply dedicate our work for the benefit of society (no really, he said these things and it's the basis for GNU's existence)... but most of us are in the real world and giving away work doesn't make any economic sense when we have to deal with rising real estate costs, greater expenses for health care, purchasing things like food, supporting a family, etc.

2004 is the year where people realize that outsourcing of tech jobs to other countries like India, Russia, etc. doesn't just mean that the crappy work is being done by them, but that their jobs are being replaced. And 2004 will also be the year where people realize that writing open sourced projects, while a great exercise in coding skill, does absolutely nothing for them personally. The only people who benefit financially from open source are the companies who distribute those projects and who now have a team of workers essentially working at no cost. Why outsource to India when you can just browse SourceForge and find something that someone's working on for no pay at all?

The rhetoric of "selling licenses is so old sk00L... now we make our money from servicing those programs and coding customizations" has been proven false. Don't people realize that *those* tasks can easily be outsourced too? There's always some talented person in some corner of the world who's willing to work for a few dollars cheaper than you are. By giving up control over who gets to sell your product that you developed, you are essentially coding yourself into a wonderful unemployment situation.

Yes, 2004 will be a first for many things indeed.

As far as Stallman and his minions are concerned, Free means GPL.

That's complete rubbish. GNU even maintain a list of licenses that qualify as Free Software licenses but are GPL-incompatible.

That's the whole story. GPL or go to Hell. Nothing else.

Then how do you explain the fact that Stallman condones the use of the LGPL for glibc and a BSD-style license for Ogg Vorbis?

Sure, Sun's been a pretty good steward. But that's not the point: java could be doing so much better as free software. A free java would have at least two big advantages:

Sun has basically left some parts of the "standard java libraries" to rot. That applies to Swing in particular: no major changes here the last few years. One example: there is still no support for Cleartype or Xft, so fonts are looking pretty 1997-ish in Swing. And fonts are kind of a big deal in any gui-based app.

But more importantly: free software is more dependable. If Sun should fold, no one knows what would happen to java. If Sun gets into serious financial difficulties, it might stop making the JDK available as a free download. Etc.

That risk would disappear over night if java was free software.

At the very least, the libraries should be opened up. It is fairly easy to create an open source VM (comparatively): java's virtual machine is fairly well specified.

The libraries are much harder to implement: the fine folks at GNU Classpath are working hard to provide a free version of the library (which is used in gcj, kaffe, jikes rvm, etc.). But since large parts of the library are so poorly specified, they will always be lagging "official java" quite a bit.

Free java! Or at least the libraries.

'The question he should really be asking is why has no-one else offered to create an Open Source version of Java. Maybe because it's on the 'too hard' list. Sun would support an Open Source version of Java, but it need a lot of money and time to do so. You can't just flick a switch. Right now Sun has higher priorities in the form of Java 1.5,' he said.'

Obviously this Sun Evangelist is either totally clueless, or working for SCO. GCC already comes with a Java compiler called GCJ

I am afraid that your system would cease to function all together given as libc (as in /lib/libc.so.6), the core library that 90% of all applications link to is part of GNU. I am no nazi when it comes to insisting that you call the thing GNU/Linux but I can see how RMS can be seriously peeved when such critical elements that existed long before Linux proper (not to mention the C compiler the kernel is made with) are completely ignored and most people believe Linus wrote the whole thing. This is compounded by the fact that GNU people now have a semi-working kernel called Hurd and when plugged into the same libraries and tools that the Linux kernel is surrounded in it creates a functioning OS.

So for practical every-day use I tend to just say Linux but I also mention GNU/Linux at least once at the beginning of the conversation.

Initially the obnoxious BSD advertising clause was used only in the Berkeley Software Distribution. That did not cause any particular problem, because including one sentence in an ad is not a great practical difficulty.

If other developers who used BSD-like licenses had copied the BSD advertising clause verbatim--including the sentence that refers to the University of California--then they would not have made the problem any bigger.

But, as you might expect, other developers did not copy the clause verbatim. They changed it, replacing ``University of California'' with their own institution or their own names. The result is a plethora of licenses, requiring a plethora of different sentences.

When people put many such programs together in an operating system, the result is a serious problem. Imagine if a software system required 75 different sentences, each one naming a different author or group of authors. To advertise that, you would need a full-page ad.

This might seem like extrapolation ad absurdum, but it is actual fact. NetBSD comes with a long list of different sentences, required by the various licenses for parts of the system. In a 1997 version of NetBSD, I counted 75 of these sentences. I would not be surprised if the list has grown by now.

http://www.gnu.org/philosophy/bsd.html

The FSF is quite clear (see here and here) in that they do not consider licenses with the advertising clause to be compatible with the GPL.

I just don't get it... there are lots of GPL incompatible licenses and nobody says anything about it. In fact, most Linux distributions ship that software. It seems that the only problem is the GPL license... am I wrong?


GPL Incompatible Licenses:

The original BSD license, the OpenSSL license, the Apache License, the Mozilla Public License, the Netscape License, the PHP license, the Apple Public Source License, ...

GPL Incompatible Licenses

Red Hat distributes Apache, OpenSSL, xinetd, all with GPL-Incompatible, Free Software Licenses What is weird is Apache claims their license is compatible. What i'm really asking is why are all these projects able to get away with it?