Slashdot Mirror

I'm so sick of hearing this tired misunderstanding of the FOSS movement. I beginning to think that no one really knows what the FOSS movement is about.

PLEASE go read the ACTUAL position of the FSF on selling software: Selling Free Software. Come back when you have something insightful to say.

3) You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above

We should all use free (though poorly functional) things, rather than things that work.

Were you implying that free software is poorly functional? Geez, every day I use free software that feel is very functional, don't you think?

I'm also a bit confused as how 'free software' = 'freedom'. So... you lose your individual freedom if you buy software?

Free Software means that the users are free to share, study, and improve the software with very little restrictions. You might want to read this; it's best to get it straight from the horse's mouth.

And, people buy Free Software all the time. Why is Red Hat still in business? Free Software has nothing to do with costs; if it costs just as much as proprietary software, I'd still buy the Free Software package if it were superior.

We should all use free (though poorly functional) things, rather than things that work.

Were you implying that free software is poorly functional? Geez, every day I use free software that feel is very functional, don't you think?

I'm also a bit confused as how 'free software' = 'freedom'. So... you lose your individual freedom if you buy software?

Free Software means that the users are free to share, study, and improve the software with very little restrictions. You might want to read this; it's best to get it straight from the horse's mouth.

And, people buy Free Software all the time. Why is Red Hat still in business? Free Software has nothing to do with costs; if it costs just as much as proprietary software, I'd still buy the Free Software package if it were superior.

Linus Torvalds could say, tomorrow, that he revokes everyone's right to use the parts of the Linux kernel he wrote. That's his right as copyright holder.

No, he can't.

From the FAQ

Linus can redistribute code he has written under another license, but he cannot revoke the rights he has already provided. He can also make it so future releases are under a more restrictive license, but someone would just end up forking the last GPLed version.

A good example of this is XFree86. Version 4.4 was released under a more restrictive license that the community did not like. Next thing you know, the last 4.4 prerelease under the old license was forked as X.org.

That is _not_ what RMS advocates. Please read his philosophy straight from his very own website: gnu.org.

In short, there's no idealogical problem with selling free software.

RMS uses the phrase himself. Possibly he introduced it. But after reading his Free Software Definition again, it contradicts the phrase. It sounds more like the definition of Free = Free Speech = Free Beer.

Why? Because how can you offer your software's source code to the public (free as in speech) without essentially making it free (no cost/free as in beer) especially when other people are free to duplicate and distribute it. The value of software is primarily the IP not the distribution or packaging. Sure you can charge for those and other auxilary things but that still means (re-using the analogy) the beer is free -- just not the cup (packaging) it comes with or the bartender fees (service) you pay... The fact remains if you offer source code your software itself becomes free, as in speech and beer.

So that phrase is misleading at best...

Well, if you're going to disagree with someone you should probably understand their position first -- which is in TFA. RMS hasn't nothing against making money on software. See here.

"Free as in beer" -> as if somebody gave you a beer without charging you a price. As in, "the beer was free". Relates to money.

"Free as in speech" -> as if you have a right to speak out, without being censored. As in, "he spoke freely". Relates to rights.

GNU Link

First open source (GNU) has no authority.

Software can be distributed w/o charge but does not have to be 100% free. Why he insists that this is the case is only understandable by him and people that are just as warped as he can be.

Somebody here fails to understand items such as the Java trap then... and why there's such a furore about the new version of OpenOffice.org having such a dependence upon non-free Java...

From http://www.gnu.org/gnu/linux-and-gnu.html:

"Linux is the kernel..."

The more I hear FROM Stallman the more scared I am...Hacker Song

Though hackers may be good with code,
they can't sing, hackers they can't sing!!!
Some sounds can make a person's head explode
Oh the pain, hackers, oh the pain.

Just a joke, RMS, no need to go GNU/Postal on me. :)

Then go here and you will love him!

Is the code open so I can update the GNU utilities? (Despite Apple's "commitment" to Open Source, I highly doubt it. But maybe they'll surprise me.)

As part of Darwin 8.0, I would expect the code for cp and mv to be licenced under the APSL, which, dispite being Free, is incompatable with the GPL. So, the code is available, but it can't be added to GNU tools, due to restrictions in the GPL.

However, rsync is GPLed (and they're shipping a modified rsync), so the code necessary to do what you want will be available under the GPL anyway. (In fact, it's been available in RsyncX for a while.)

I don't see why you would doubt Apple abiding by the licenses of the code they use. As far as I know, they've never been accused of not doing so.

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

We know that nobody wants Objective-C++.

You jump to argue that with nobody uses a Macintosh, but you can't understand why Objective-C++ users might not want to be dismissed as nobody. I'm not arguing that it's worth doing, just that all the people that were waiting on Objective C++ (all hundred or whatever), and were told that it would be in GCC 4.0 (http://gcc.gnu.org/wiki/What%20will%20be%20in%204 .0) at least deserve a statement that it won't be done.

I think there is always a misconception between what people think that i586 and i686 should mean and what GCC actually interprets it as being.
For GCC, i586 is just an alias for Pentium, e.g. Intel's original Pentium processor, and i686 is an alias for Pentiumpro, eg. Intel's original Pentium pro processors. For these options, GCC tries to create optimal code for the corresponding Intel processors, but nor necessarily for any more or less compatible processors from other manufacturers.
Maybe a lot of people don't know it, but GCC has actually a very rich set of processor selections and instead of just choosing between the old i386, i486, i586 and i686 settings, you can much more precisely specify what exact chaip you are using. For details see http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions

As for CMOV being the only useful addition since the i486, I have to disagree. For integer code this may be true, but for floating point code there is a very important addition with the FCOMI, FCOMIP, FUCOMI and FUCOMIP instructions. This instructions allows floating point comparisions which directly set the main processor flags and therefore can directly be fllowed by conditional branch instructions. The old FCOM family of instrustions only set the coprocessor flags and you need a time consuming sequence of instructions to transfer the coprocessor flags to the processor flags in order to be able to make conditional branches based on floating point comparisions.
Also, just like the CMOVcc instruction for interger registers, there are the equivalent FCOMVcc instructions for floating point registers.

Marcel

The Objective-C++ folks had to learn a couple hard lessons about contributing to open source projects, and GCC in particular. So it didn't make it into 4.0, but probably will for 4.n, where n is a very small integer.

In that respect, ObjC++ was no different from any of the zillion other "features" that get thrown at the GCC maintainers: it committed the heinous sin of not magically implementing itself. GCC tends to get this a lot from a user community (which might be large, or might only be a handful of people), and it almost always follows this general pattern:

User Community: Feature X would be cool, plz add it to GCC kthxbye.
GCC: No. We're busy. You can write it yourself, though; here's how and here's why.
UC: But it would be work!
GCC: That's why we're busy. We're either volunteers (so you can't force us to work on what you think would be cool), or we're paid by our employers to work on specific tasks.
[time passes]
UC: Okay, here's a patch.
GCC: Who are you?
UC: We're the people who want feature X. We went off and wrote it on our own, in isolation, because you wouldn't drop your own tasks to do it for us. Now here's the patch, kthxbye.
GCC: This patch is teh suck. People who aren't using feature X are being penalized with (slower compiler, slower generated code, false positive diagnostics, overly strict dependancies, genital warts, etc) to support your smaller user base. You need to work with the maintainers, not dump a patch in their laps out of the blue and expect to have it included.
UC: You're a bunch of fucktards for not accepting our crappy patches!
GCC: What, insulting us is going to make us change our minds?
UC: Fine, we'll fix up the patch so it won't suck.
GCC: Good. Here are some tips: [...] Now, the new version goes out next week, and after that we'll have more time to help.
UC: But this has to go out now!
GCC: It ain't done yet.
UC: But a lot of people want it!
GCC: So? It's not a popularity contest. It. Ain't. Done. Yet. If there are a lot of people who want it, as you claim, then you should have no trouble getting people to help you.
UC: But-
GCC: No. We're not shipping untested half-assed crap. Made that mistake before, we're not doing it again, you'll thank us later.
[time passes]
UC: Here's a patch.
GCC: We'll review it as soon as we can.
UC: Why not now?
GCC: There aren't enough of us. Sucks, doesn't it?
UC: Damn straight...
[time passes]
UC: Looked at the patch yet?
GCC: No. *looks at patch* Good. *commits patch* UC: *faints*

Being smart people, the Objective-C++ community didn't suffer from the immature stages featured in my one-act morality play above. But they got stuck for a while at the "we have a patch" / "that patch sucks" stage, and no progress was made for a long time. By the time the hard bits were worked out, it was too late for 4.0.

The Objective-C++ folks had to learn a couple hard lessons about contributing to open source projects, and GCC in particular. So it didn't make it into 4.0, but probably will for 4.n, where n is a very small integer.

In that respect, ObjC++ was no different from any of the zillion other "features" that get thrown at the GCC maintainers: it committed the heinous sin of not magically implementing itself. GCC tends to get this a lot from a user community (which might be large, or might only be a handful of people), and it almost always follows this general pattern:

User Community: Feature X would be cool, plz add it to GCC kthxbye.
GCC: No. We're busy. You can write it yourself, though; here's how and here's why.
UC: But it would be work!
GCC: That's why we're busy. We're either volunteers (so you can't force us to work on what you think would be cool), or we're paid by our employers to work on specific tasks.
[time passes]
UC: Okay, here's a patch.
GCC: Who are you?
UC: We're the people who want feature X. We went off and wrote it on our own, in isolation, because you wouldn't drop your own tasks to do it for us. Now here's the patch, kthxbye.
GCC: This patch is teh suck. People who aren't using feature X are being penalized with (slower compiler, slower generated code, false positive diagnostics, overly strict dependancies, genital warts, etc) to support your smaller user base. You need to work with the maintainers, not dump a patch in their laps out of the blue and expect to have it included.
UC: You're a bunch of fucktards for not accepting our crappy patches!
GCC: What, insulting us is going to make us change our minds?
UC: Fine, we'll fix up the patch so it won't suck.
GCC: Good. Here are some tips: [...] Now, the new version goes out next week, and after that we'll have more time to help.
UC: But this has to go out now!
GCC: It ain't done yet.
UC: But a lot of people want it!
GCC: So? It's not a popularity contest. It. Ain't. Done. Yet. If there are a lot of people who want it, as you claim, then you should have no trouble getting people to help you.
UC: But-
GCC: No. We're not shipping untested half-assed crap. Made that mistake before, we're not doing it again, you'll thank us later.
[time passes]
UC: Here's a patch.
GCC: We'll review it as soon as we can.
UC: Why not now?
GCC: There aren't enough of us. Sucks, doesn't it?
UC: Damn straight...
[time passes]
UC: Looked at the patch yet?
GCC: No. *looks at patch* Good. *commits patch* UC: *faints*

Being smart people, the Objective-C++ community didn't suffer from the immature stages featured in my one-act morality play above. But they got stuck for a while at the "we have a patch" / "that patch sucks" stage, and no progress was made for a long time. By the time the hard bits were worked out, it was too late for 4.0.

The Objective-C++ folks had to learn a couple hard lessons about contributing to open source projects, and GCC in particular. So it didn't make it into 4.0, but probably will for 4.n, where n is a very small integer.

In that respect, ObjC++ was no different from any of the zillion other "features" that get thrown at the GCC maintainers: it committed the heinous sin of not magically implementing itself. GCC tends to get this a lot from a user community (which might be large, or might only be a handful of people), and it almost always follows this general pattern:

User Community: Feature X would be cool, plz add it to GCC kthxbye.
GCC: No. We're busy. You can write it yourself, though; here's how and here's why.
UC: But it would be work!
GCC: That's why we're busy. We're either volunteers (so you can't force us to work on what you think would be cool), or we're paid by our employers to work on specific tasks.
[time passes]
UC: Okay, here's a patch.
GCC: Who are you?
UC: We're the people who want feature X. We went off and wrote it on our own, in isolation, because you wouldn't drop your own tasks to do it for us. Now here's the patch, kthxbye.
GCC: This patch is teh suck. People who aren't using feature X are being penalized with (slower compiler, slower generated code, false positive diagnostics, overly strict dependancies, genital warts, etc) to support your smaller user base. You need to work with the maintainers, not dump a patch in their laps out of the blue and expect to have it included.
UC: You're a bunch of fucktards for not accepting our crappy patches!
GCC: What, insulting us is going to make us change our minds?
UC: Fine, we'll fix up the patch so it won't suck.
GCC: Good. Here are some tips: [...] Now, the new version goes out next week, and after that we'll have more time to help.
UC: But this has to go out now!
GCC: It ain't done yet.
UC: But a lot of people want it!
GCC: So? It's not a popularity contest. It. Ain't. Done. Yet. If there are a lot of people who want it, as you claim, then you should have no trouble getting people to help you.
UC: But-
GCC: No. We're not shipping untested half-assed crap. Made that mistake before, we're not doing it again, you'll thank us later.
[time passes]
UC: Here's a patch.
GCC: We'll review it as soon as we can.
UC: Why not now?
GCC: There aren't enough of us. Sucks, doesn't it?
UC: Damn straight...
[time passes]
UC: Looked at the patch yet?
GCC: No. *looks at patch* Good. *commits patch* UC: *faints*

Being smart people, the Objective-C++ community didn't suffer from the immature stages featured in my one-act morality play above. But they got stuck for a while at the "we have a patch" / "that patch sucks" stage, and no progress was made for a long time. By the time the hard bits were worked out, it was too late for 4.0.

Without IP people would be free to use GPL code any way they want, without contributing back.

Without IP, nobody would be able to download the GPL code in the first place; they'd have to rely on tape drives or CD burners.

Or did you mean "copyright"? In that case, without copyright, people would be free to use executable computer programs any way they want, including contributing commented decompilations to the community.

The *BSD's do have there own compiler (at least, in license form) called none other than TenDRA. Just a shame the *BSD's don't all collaborate and get TenDRA in to a useable alterantive to GCC -- I've seen how much work it takes for the *BSD's to get GCC into a useable toolchain. hmmm.

The *BSD's do have there own compiler (at least, in license form) called none other than TenDRA. Just a shame the *BSD's don't all collaborate and get TenDRA in to a useable alterantive to GCC -- I've seen how much work it takes for the *BSD's to get GCC into a useable toolchain. hmmm.

If you want to achive optimal results, use the correct compiler options. There is not really an i686 processor, but as the expression i686 is so commonly used, GCC has it as an alias for Pentiumpro. Now the problem is that the Intel processors based on the Pentiumpro core (this includes the Pentium2 and Pentium3 processors) need a rather strict scheduling for optimal performance whereas the Athlon processors are more relaxed in their scheduling requirements. This means that the i386 option may produce tighter code that while slower on a Pentium Pro/2/3 may actually be faster on an Athlon.

If you really want to see how much the compiler can make of your processor, tell it what processor you are using and don't lie to the compiler. For instance if you take a look at the compiler options for the x86 target http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/i386-a nd-x86_002d64-Options.html#i386-and-x86_002d64-Opt ions you will see that GCC actually knows about the different type of AMD processors. So if you for instance have an AthlonXP and you want to try what the best code is that GCC can produce for your processor, try the option -march=athlon-xp

This is of course no guarantee that your program will run faster. I agree with your overall answer "it depends". Also, I must admit that the Athlon options for 32 bit code may not be so well tuned as the Intel options. This may partly be due to the fact that the Athlon processor is more "flexible" in their code execution and there are less occasions to improve performance by better scheduling.

In conclusion, I think people are too much fixed on the "mythical" i686 option whereas very few people still use processors for which the i686 is the best one. GCC knows a lot of processors and if you want to compile code just for your own machine, tell GCC what processor you *really* have. Also remember that there are 2 options to select the processor: the -mtune and the -march option. -march gives the minimum processor on which the code is to run and influences what kind of instructions can be used at all. -mtune specifies on which processor the code is to be run fastest and incluences instruction scheduling as well as selecting the best instruction in case there would be multiple prossibilities.

Marcel

I have not done any tests myself nor do I have any numbers to compare. However my guess is that for GCC 4.0, vectorization will still be quite behind the Intel compiler. You should see vectorization support in GCC 4.0 as the first skelleton, but a lot of the vectorization stuff didn't make it for GCC 4.0 and is now scheduled for GCC 4.1. For more details see the following web page: http://gcc.gnu.org/wiki/GCC%204.1%20Projects

Marcel

I'm surprised nobody considered GNU Arch http://www.gnu.org/software/gnu-arch/ to replace BitKeeper - it was probably started in direct response to the Linux Kernel using a non-free tool.

I must say I haven't used it, but from reviews and comparisons I've read, it seems to be a good tool.

Really? Let me see... Looks like I'm safe as all the software I use doesn't have the provisions. Even software that I refuse to use because of the license doesn't have such provisions. Where are you getting you software that you see lots of software with such a provision?

(here) which is probably quite useful if you already know what SSA is and how it applies to trees.

>I don't know where you got that from. It's not true.

From: http://gcc.gnu.org/wiki/What%20will%20be%20in%204. 0

In addition, the GCC Steering Committee has promised Apple (Zem Laski) that we will get Objective-C++ into GCC 4.0. Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. (Update) Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.

The version of GCC shipped by Apple typically includes a number of extensions not available in a standard GCC release. These extensions are generally for backwards compatibility and best avoided.

DIMENSION A(1000000), B(1000000), C(1000000)
READ*, X, Y
A = LOG(X); B = LOG(Y); C = A + B
PRINT*, C(500000)
END

Notice the lack of an array index. These are true vector operations to begin with, so it is already assumed that the array elements are independent, therefore the log and addition can be parallelized safely.

Actually someone is working on merging it. So you data is not update. See here.

One of the changes in 4.0.0 is autovectorization optimizing.
One _ancient_ compiler (10+ years) I have to use, already has this feature -- and on a large scale: it'll do it over several screensful of code. What took GCC so long?

Unfortunately, this compiler I mention also has a bug: once it's factored out 'i' in a piece of code like that below, it then complains that 'i' is an unused variable. So you have to do something with 'i' to suppress that warning, which kinda defeats the purpose of the autovectorization.

Sample code:

int a[256], b[256], c[256];
foo () {
int i;

for (i=0; i256; i++){
a[i] = b[i] + c[i];
}
}

RTFM. It says right in the changelog that more swing has been added.

"There have been many improvements to the class library. Here are some highlights:
Much more of AWT and Swing exist.
Many new packages and classes were added, including java.util.regex, java.net.URI, javax.crypto, javax.crypto.interfaces, javax.crypto.spec, javax.net, javax.net.ssl, javax.security.auth, javax.security.auth.callback, javax.security.auth.login, javax.security.auth.x500, javax.security.sasl, org.ietf.jgss, javax.imageio, javax.imageio.event, javax.imageio.spi, javax.print, javax.print.attribute, javax.print.attribute.standard, javax.print.event, and javax.xml
Updated SAX and DOM, and imported GNU JAXP"

http://gcc.gnu.org/gcc-4.0/changes.html

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

SCO is so not a threat they decided to delete the page. (404 Not Found)

oh, wait. here it is

They've been talking about having Objective-C++ in the GCC main branch for years now.

Yes.

There was even talk that 4.0 wouldn't ship without it.

I don't know where you got that from. It's not true.

Now it's shipped without it and it's still "coming Real Soon Now". Any word on if it's coming any time soon (really)?

No, it's not coming any time soon, because nobody's currently working on it. If you want to work on it, mail them. But don't expect things to happen by themselves. Nothing does.

Static Single Assignment, optimization techniques. Try here for more details.

git (GNU Interactive Tools) is a screen-based console "filer" with command line and extreme flexibility and key mapping, etc.

Freshmeat:http://freshmeat.net/projects/gnuinterac tivetools/
Homepage: http://www.hulubei.net/tudor/git/
GNU Page:http://www.gnu.org/software/git/

The underlying design of Subversion is centralized. It's probably easier to write something from scratch than to change core design elements of Subversion.

But, I wonder why he didn't just help improve (or fork) Arch so it would suit his needs better instead of starting from scratch. Arch is much closer to Bitkeeper in design and operation. It's decentralized, uses change sets, and it's GPLed.

The monotone hackers have the same design as this new git tool. They already adapted their visualisation tools to make pretty screenshots of the kernel patches development history: http://lists.gnu.org/archive/html/monotone-devel/2 005-04/msg00183.html

Let me tell the message in the myth of the starving genius. If somebody who's been working in isolation for years and starving and he has a brilliant new idea for how to do something or other. And so, now, he's starting a company and he is afraid some big companies like IBM will compete with him and so he gets a patent and this patent will "protect him". Well, of course, this is not the way of things work out in fields. People won't make this kind of progress in isolation is where you working with other people and talking with other people and developing software usually. And so the whole scenario doesn't make sense and besides, if there's such a good computer scientist there is no need for him to starve. He could have got a job at any time if he wanted.

But let's suppose this happened, and suppose he has this patent, and he says "IBM, you can't compete with me because I have got this patent ". But here is what IBM says: "well, gee, let's look at your product, hmm, I have this patent, this patent and this patent and this patent and this patent that your patent is violating. So how about a quick cross-licence?". And the starving genius says "hmm, I haven't had enough food in my belly to fight these things, so I better give in" and so they sign a cross-licence and now guess what .

IBM can compete with him - he wasn't protected at all. Now IBM can do this because they have a lot of patents. They have patents pointing here, here, here, everywhere. So that anybody from almost anywhere that attacks IBM is facing a stand-off. A small company can't do it but a big company can.

Hurd fanatics' usual argument against Linux.

Though Linus calls Linux modular, it isn't actually modular because at run time the kernel runs as one big program( it is called modular because of the modules aspect of Linux). The disadvantage of this being, as the kernel gets bigger it is going to be more difficult to maintain it. On the other hand, the microkernel as such is small. The modules are in user space, and are separate programs, which helps in maintaining them.

Look ahead 5 years and see how Linux kernel would be experiencing more bloat and Hurd getting better each time

• Dashboard
• Piper for a while was trying to implement an entire new Unix desktop based on GUI-based command-line scripting, but never quite got off the ground, and eventually abandoned the idea.
• Knoppix and other liveCDs are innovative -- an entire operating system on a CD-ROM! -- though you might quibble with "prior art" in the form of boot disks that you'd use to play your DOS games. They didn't have entire filesystems on them, though, so I'd maintain that this was innovation. A Windows liveCD exists in a primitive form somewhere, I think, but I don't know anything about it.
• gaim and other pluggable communication programs -- Firefox and xchat spring to mind -- are very useful, and you can probably find a plugin on one of those programs that does what you want. To my knowledge, the furthest the proprietary world got in this direction was skinning, but I could be wrong.
• Also in this vein is KDE, specifically the use of DCOP to help automate GUI tasks. DCOP isn't very well known and you have to discover it, but it can be very useful.
• GNU Screen, to my knowledge, is one-of-a-kind software, though you might cite inspiration in terms of VNC programs, which I don't know much about.
• I believe the concept of numerous virtual terminals on the same physical terminal (ie. Alt-F1, Alt-F2) is not only unique to OSS, but unique to Linux.
• 
  Ethan

> If you borrow a piece of GPL code, and CHANGE
> NOTHING in the GPL code, it just plugs directly
> into your product, you don't have to release your
> entire product as GPL.

Richard Stallman disagrees. I can also refer you to the FSF GPL FAQ and what it has to say on the subject. This very scenario was the reason to create the LGPL in the first place. If linking didn't infect, the GPL and the LGPL would be the same thing.

> I don't need or want your entire product, only
> the part that you've added TO MY CODE.

Then you should use the LGPL license, not the GPL.

> I haven't yet heard of a single case where an author of
> GPL code forced a company to release their entire product

Only because any company that tries to use GPL code is forced by a court to remove it instead. Releasing the entire product under the GPL is an option; it is just never taken. Mostly though, companies just don't touch any GPL code at all.

> So please, get off the "viral" rant, its getting old, and
> its just propagating more misinformation that simply isn't true.

If you read the LGPL and the reasons for creating it, you'd understand that the "viral rant" really is true. Your mistake is simply in not knowing the difference between GPL and LGPL. Look it up. What you think of as GPL really is the LGPL.

It seems the whole point to your posts above is that the GPL isn't viral because you don't have to GPL the code--you just have to hire a lawyer and go to court or just opt out entirely. I guess that's a compromise.

You are also arguing based on a slightly different definition of 'viral'. In most discussions, it is used in the context of making larger works based on source code, not simply installing binaries that link against LGPL shared libraries.

...the code you incorporated into your proprietary product.

If that company ever distributed their proprietary code, it would have to be GPL.

(without looking at the GPL code as a baseline, because that becomes a copyright infringement, as it isn't a cleanroom implementation)

How is this possible after determining the GPL code isn't workable?

If you borrow a socket interface from a GPL product and put it into your application, does your entire application become a derivitive work of that socket interface? Of course not!

If you re-implemented the interface, no. If you borrowed the GPL code that implemented the interface, the resulting program has to be GPL.

Also, GPL != LGPL. GNU specifically uses the GPL on shared libraries where they want to enforce linked programs be GPL.

It grants rights, it does not take them away.

Pedant: It takes away rights that would otherwise belong to the public domain.

Your link to the GPL FAQ does not support your arguments:

1
2
3
4
5
6
7

There's more but seven is enough. In short, any time they hint at not requiring re-licensing under the GPL, there is a catch. Either the author has to dual-license (one license being the GPL) or amend the GPL (no guaranteed propogation). Always, the GPL is in the equation.

Look, I am not anti-GPL (it _is_ a useful license), but I do understand the rationale behind the per-file licenses like the MPL (and its derivatives). If I write code today based on an existing code base, I really can't predict my future needs whether to redistribute it or not. If I go the GPL route, that changes the game plan. With the CDDL, the game plan is more controllable, if I organize my files properly and make a modular program.

It seems the whole point to your posts above is that the GPL isn't viral because you don't have to GPL the code--you just have to hire a lawyer and go to court or just opt out entirely. I guess that's a compromise.

You are also arguing based on a slightly different definition of 'viral'. In most discussions, it is used in the context of making larger works based on source code, not simply installing binaries that link against LGPL shared libraries.

...the code you incorporated into your proprietary product.

If that company ever distributed their proprietary code, it would have to be GPL.

(without looking at the GPL code as a baseline, because that becomes a copyright infringement, as it isn't a cleanroom implementation)

How is this possible after determining the GPL code isn't workable?

If you borrow a socket interface from a GPL product and put it into your application, does your entire application become a derivitive work of that socket interface? Of course not!

If you re-implemented the interface, no. If you borrowed the GPL code that implemented the interface, the resulting program has to be GPL.

Also, GPL != LGPL. GNU specifically uses the GPL on shared libraries where they want to enforce linked programs be GPL.

It grants rights, it does not take them away.

Pedant: It takes away rights that would otherwise belong to the public domain.

Your link to the GPL FAQ does not support your arguments:

1
2
3
4
5
6
7

There's more but seven is enough. In short, any time they hint at not requiring re-licensing under the GPL, there is a catch. Either the author has to dual-license (one license being the GPL) or amend the GPL (no guaranteed propogation). Always, the GPL is in the equation.

Look, I am not anti-GPL (it _is_ a useful license), but I do understand the rationale behind the per-file licenses like the MPL (and its derivatives). If I write code today based on an existing code base, I really can't predict my future needs whether to redistribute it or not. If I go the GPL route, that changes the game plan. With the CDDL, the game plan is more controllable, if I organize my files properly and make a modular program.

It seems the whole point to your posts above is that the GPL isn't viral because you don't have to GPL the code--you just have to hire a lawyer and go to court or just opt out entirely. I guess that's a compromise.

You are also arguing based on a slightly different definition of 'viral'. In most discussions, it is used in the context of making larger works based on source code, not simply installing binaries that link against LGPL shared libraries.

...the code you incorporated into your proprietary product.

If that company ever distributed their proprietary code, it would have to be GPL.

(without looking at the GPL code as a baseline, because that becomes a copyright infringement, as it isn't a cleanroom implementation)

How is this possible after determining the GPL code isn't workable?

If you borrow a socket interface from a GPL product and put it into your application, does your entire application become a derivitive work of that socket interface? Of course not!

If you re-implemented the interface, no. If you borrowed the GPL code that implemented the interface, the resulting program has to be GPL.

Also, GPL != LGPL. GNU specifically uses the GPL on shared libraries where they want to enforce linked programs be GPL.

It grants rights, it does not take them away.

Pedant: It takes away rights that would otherwise belong to the public domain.

Your link to the GPL FAQ does not support your arguments:

1
2
3
4
5
6
7

There's more but seven is enough. In short, any time they hint at not requiring re-licensing under the GPL, there is a catch. Either the author has to dual-license (one license being the GPL) or amend the GPL (no guaranteed propogation). Always, the GPL is in the equation.

Look, I am not anti-GPL (it _is_ a useful license), but I do understand the rationale behind the per-file licenses like the MPL (and its derivatives). If I write code today based on an existing code base, I really can't predict my future needs whether to redistribute it or not. If I go the GPL route, that changes the game plan. With the CDDL, the game plan is more controllable, if I organize my files properly and make a modular program.

It seems the whole point to your posts above is that the GPL isn't viral because you don't have to GPL the code--you just have to hire a lawyer and go to court or just opt out entirely. I guess that's a compromise.

You are also arguing based on a slightly different definition of 'viral'. In most discussions, it is used in the context of making larger works based on source code, not simply installing binaries that link against LGPL shared libraries.

...the code you incorporated into your proprietary product.

If that company ever distributed their proprietary code, it would have to be GPL.

(without looking at the GPL code as a baseline, because that becomes a copyright infringement, as it isn't a cleanroom implementation)

How is this possible after determining the GPL code isn't workable?

If you borrow a socket interface from a GPL product and put it into your application, does your entire application become a derivitive work of that socket interface? Of course not!

If you re-implemented the interface, no. If you borrowed the GPL code that implemented the interface, the resulting program has to be GPL.

Also, GPL != LGPL. GNU specifically uses the GPL on shared libraries where they want to enforce linked programs be GPL.

It grants rights, it does not take them away.

Pedant: It takes away rights that would otherwise belong to the public domain.

Your link to the GPL FAQ does not support your arguments:

1
2
3
4
5
6
7

There's more but seven is enough. In short, any time they hint at not requiring re-licensing under the GPL, there is a catch. Either the author has to dual-license (one license being the GPL) or amend the GPL (no guaranteed propogation). Always, the GPL is in the equation.

Look, I am not anti-GPL (it _is_ a useful license), but I do understand the rationale behind the per-file licenses like the MPL (and its derivatives). If I write code today based on an existing code base, I really can't predict my future needs whether to redistribute it or not. If I go the GPL route, that changes the game plan. With the CDDL, the game plan is more controllable, if I organize my files properly and make a modular program.

It seems the whole point to your posts above is that the GPL isn't viral because you don't have to GPL the code--you just have to hire a lawyer and go to court or just opt out entirely. I guess that's a compromise.

You are also arguing based on a slightly different definition of 'viral'. In most discussions, it is used in the context of making larger works based on source code, not simply installing binaries that link against LGPL shared libraries.

...the code you incorporated into your proprietary product.

If that company ever distributed their proprietary code, it would have to be GPL.

(without looking at the GPL code as a baseline, because that becomes a copyright infringement, as it isn't a cleanroom implementation)

How is this possible after determining the GPL code isn't workable?

If you borrow a socket interface from a GPL product and put it into your application, does your entire application become a derivitive work of that socket interface? Of course not!

If you re-implemented the interface, no. If you borrowed the GPL code that implemented the interface, the resulting program has to be GPL.

Also, GPL != LGPL. GNU specifically uses the GPL on shared libraries where they want to enforce linked programs be GPL.

It grants rights, it does not take them away.

Pedant: It takes away rights that would otherwise belong to the public domain.

Your link to the GPL FAQ does not support your arguments:

1
2
3
4
5
6
7

There's more but seven is enough. In short, any time they hint at not requiring re-licensing under the GPL, there is a catch. Either the author has to dual-license (one license being the GPL) or amend the GPL (no guaranteed propogation). Always, the GPL is in the equation.

Look, I am not anti-GPL (it _is_ a useful license), but I do understand the rationale behind the per-file licenses like the MPL (and its derivatives). If I write code today based on an existing code base, I really can't predict my future needs whether to redistribute it or not. If I go the GPL route, that changes the game plan. With the CDDL, the game plan is more controllable, if I organize my files properly and make a modular program.