It is illegal to remove the BSD license since the BSD license specifically states that the BSD license terms must be retained with the software. This applies even if a derived work is made or if a work is made that doesn't qualify as derived under copyright laws.
Here are the BSD terms that state this: * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution.
That's pretty clear.
As for "evil", well that depends upon how you define evil doesn't it. Let's use a general purpose definition: yes it's evil or rather "unethical" since it's clearly a violation of copyright law.
That's why you are wrong on both points and why Theo is correct on both points.
Certainly the spirit of sharing is violated by attempting to state that it's only GPL'd in the case of a dual license. It's also crucial that the patch in question isn't a new derivative work and thus doesn't qualify as a copyrightable work by the new authors. This means that the changes must be distributed under the original license or licenses since they remain in effect even upon minor changes authored by authors other than the original authors. If in fact the driver was dual licensed then the changes must be distributed under both licenses.
Hair splitting is often what lawyers do therefore the analysis I have performed is very relevant and very possibly will be tested in court in this case or others.
Remember the entirely of copyright law applies and is enhanced by the BSD license terms. Tread carefully least a big legal stick meet you in your journey with software.
How did you obtain that assessment? I never said that.
Let's think it through though now that you brought it up. Assuming the dual licenses are BSD and GPL it would seem that there is a conflict between the two licenses with the GPL saying that source must be shipped with any binary distributions while the BSD saying that binaries may be shipped with or without the source code at the developers choice. This is one of the quintessential gaps between these two licenses that is at the core of the philosophical battles raging in many places and projects.
Since the BSD explicitly permits the binary only distribution option developers may ship only the binary if they so choose as the license permits This is true if both licenses are alternatives since the developer can choose either license. All they need do is ship with the BSD license and indicate that that was their choice. This assumes that the work isn't a derived work under copyright law - as most changes, additions, updates, or modifications don't qualify as derived works under copyright law the new work isn't copyrightable.
Regardless derived works (as defined by copyright laws and court cases) must preserve the terms of the BSD license since that is explicitly stated in the license of original works licensed under BSD style licenses. This means that the BSD license can never be removed! This also means that the original code is forever under the BSD license even when embedded or fractured into a new derived work.
It should also be noted that the original authors retain all their rights to derived works! This has serious implications.
The GPL terms only come into play when the developer chooses to distribute their changes (assuming that they pass the test of being different enough and thus a derivative work under copyright laws and court cases) under the GPL terms. However, if the changes - when merged with the original work - don't qualify as a new copyrightable work the new authors have no say in the matter and the changes MUST BE DISTRIBUTED under BOTH licenses!!! This is a crucial point and one that will likely be tested in court, possibly as a result of this dispute or one like it.
Why must minor changes be distributed under both licenses at the discretion of the original works authors? Because they are the ones who control the original work and when the new author makes changes to the original work that don't qualify as derived works (as defined by copyright law and court cases) the new author has no control over their work once they merge it into the original work. Legal advice obtained a few days ago on this point suggest that the new authors consider their changes as a gift to the original authors to minimize the legal problems they could face. For proprietary software the original authors would likely seek an injunction to prevent the new changes. In open source the original authors usually welcome the "gift" of minor changes from new authors even if these changes are unsolicited. Often these changes are incorporated into the original work and redistributed. The key point to understand is that it's optional for the original authors to extend any copyright ownership in their original work to new authors minor changes - often they might do so out of courtesy and often they simply don't. It's up to them. With major changes though (see the definition of derivative works under copyright law) the work may qualify as a derivative work and the new authors may gain copyright status of their own. At that point the original work if merged with the new work gains a new co-author and the license must be updated to include all the authors of the new copyrightable work and the original work (unless a fork occurs in which case they are now two distinct works).
This has serious implications for forking and how much the original authors may control or impact forks of software systems.
How deep does this rabbit hole descend? I'm afraid we will find out and that the damage to open source and free source projects will be significant unless they cooperate with the spirit of sharing fairly and with integrity.
No, you can't relicense BSD software even if you create a valid derived work with it. Why not? Copyright laws and the BSD license terms. Read them again. Read copyright law again.
To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes.http://www.copyright.gov/circs/circ14.htm l#derivative/ [copyright.gov]
Since the original authors have not given up their rights to derived works they still have control over them allowed by copyright laws and court cases. The portions of the original work must still be made under the original license since the BSD license terms state that. That can't be changes without violating copyrights even if the original work is embedded within a derived work! You must give credit due to the BSD license terms! You must include the BSD license terms even in derived works or works that include even tiny portions of BSD code!
Since most changes to open source software are not derived works the original authors still have control over them. This seems to the be the case with the software driver patch in question.
Yes, you seem to have written that, however your conclusion doesn't apply since the GPL has many other significant and restrictive conditions that nullify the simplistic comparison that you put forward. You have to look beyond the surface comparison to the deeper interactions that the two licenses have upon works they impact. You must agree that in totality these are radically different approaches: GPL and BSD licenses. Since that is obvious then it's easy to see how a simplistic comparison fails.
Take one point in particular that devastates your assessment: the GPL virally requires new changes to be under the GPL license while the BSD license doesn't - however the original work MUST remain under the BSD license and that includes all the code expressed in it unless you take a tiny portion under fair use. How can this be? Since most changes, modifications, updates, or additions to most software projects that are open source or free source, and like the patch to the BSD based driver that is in question, are not significant enough or don't change the original work to be different enough they are not derivative works and thus not entitled to be copyrighted under copyright laws regarding derivative works.
The implication of copyright laws for BSD licensed original works is that minor changes, such as a patch for Linux, fail to achieve their own copyright status meaning that the BSD license is in full force. Good legal advice (and yes I did ask a software lawyer about this point since this story broke) has it that it's best to consider one's "contribution", such as the "patch" in question, as a gift to the original author(s) - a gift in the sense that it's a transfer of ownership from the minor change author to the original author(s) in a legal sense. Once the "patch" is merged with an original work it no longer is owned by the author of the patch in it's merged form (assuming it's not a derivative work under copyright law).
The implications of minor changes that don't qualify as derived works that are merged into original open source or free source software programs is that most of them are gifts and not copyrightable by the authors of the minor changes.
This is very serious indeed and requires careful analysis in this case with the "patch" to the BSD driver in question as well as in every contribution by anyone to any software project (open source, free source or proprietary in nature). This could shake the foundations of the whole basis of open source and free source software and require additional clauses in licenses to deal with this gray area. For there is no doubt that it's a gray area with the potential for many legal victories and defeats for our intrepid heroes involved.
It's a gray area since the question of what constituents a derivative work under copyright law and court decisions isn't black and white. It's clear that minor changes don't qualify as derivative works. The changes must be significant in size or cause the resulting work to be different enough from the original work for the new resulting work to be considered copyrightable on it's own. Naturally one can see that this also depends on many factors such as how large the original work is in comparison to the resulting work. For example, adding a few subroutines to Firefox or Apache wouldn't result in a new derived work due to the size differences. Furthermore, it would take quite a bit of work to significantly change Firefox or Apache to be "different" enough in it's fundamental operation to be considered a derivative work. Following this reasoning most changes to these projects are not derivative works and the merged code enters this gray area where the courts are likely to rule in favor of the original authors due to the language of copyright law in regards to derivative works.
So, yes, in this case it would seem that IF the author of the "patch" isn't the original author of the BSD driver AND IF the "patch" doesn't constitute a new derived work under copyright law (and applicable court cases) THEN the "patch" M
The "GPL" isn't about giving back to the community. It isn't giving if it's by force. Since the GPL mandates that the changes be distributed in source it's not giving back to the community. It's the community taking the changes by legal force.
Theo's issue goes beyond the license to common practices. Most BSD projects receive changes back from people simply because it's in everyone's benefit that those changes make it into the mainline distribution of said projects. Now people are free to distribute their changes as they see fit however they are still bound by copyright laws and the license.
The changes to the driver do not seem to be significant and don't make the driver different enough to warrant be classified as a derivative work; thus the new author - once his changes are merged - doesn't gain any copyright into the work (the driver in this case). His changes become part of a non-derived original work and he has no rights to it. In fact it's best to consider it a gift to the original authors under their license terms and ownership.
It's the merging of changes into another's work that is the issue. Do you changes constitute a derivative work or not? Usually they don't. Too bad. You've given your code to the original author and they can control what to do with it once it's been merged.
Of course you might have a copyright in your patch as a separate entity as long as it stays a separate entity only. That would make it useless since it's value is when it's merged into the original work.
...if someone makes the tiniest change to the code and only licenses their change under the GPLv2, then the entirety of the software can only be distributed under...
"If someone makes the tiniest change to the code" then their code when merged with the original work isn't a derived work and can't be copyrighted - the new changes become part of the original work. Copyright law requires a substantial change or a change that makes the new work different enough to be considered a derivate work and thus deserving of a copyright.
While your tiny changes by themselves might be copyright by you when you merge them into an original work written by one or more other people your work is essentially a gift to that project under their copyright and ownership. Unless, your changes are significant or different enough it's important to be aware of this.
I suspect that it is the case with most contributions to open source projects that have any size to the program(s) are actually gifts to the original authors work since most changes don't significantly modify or make the work different enough to deserve to be called a derivative. Given this reasoning the entire open source industry and communities must re-evaluate the basis of their contributions since most contributions when added to the work don't confer any rights to those giving the changes.
Ironically, as all of the conditionals imposed by the BSD license are also imposed by the GPL, this means there is no practical difference between distributing under the GPL and distributing under a "dual licensed" BSD and GPL.
Ah, no, your assessment is incorrect. While the GPL license may seem to the same conditionals the GPL imposes many many other conditionals upon developers that make it significantly different than the BSD license. In this regard they are totally different.
BSD enables many other choices that the GPL specifically prevents. This is why the GPL is known as "restrictive", "viral", and "communistic" in it's nature.
If the license is dual then both license terms must move forward with the new derived work - if indeed it's a new derived work which it most likely isn't by the definition of derivative works under copyright law. If it's not a new derived work then the changes made to it belong to the author of the original work per copyright law.
While the license gives you permission to modify the files that it covers it doesn't give you permission to modify the license.
Have you even read the BSD license? It's easy, it's only three (or four) paragraphs. Let's grab a copy from http://en.wikipedia.org/wiki/BSD_licenses and see what it has to say.
First off notice that it says copyright by someone.
Then it goes on about redistribution and use but with some conditions. What would they be? Oh, one of the conditions is that the license itself must be retained. How about that. The license must be retained. So you can't modify the license! It says so right there. Copyright law also has some input on that too, but enough said.
Now there is an exception of course, and that is if you are the original author or if all the original authors authorize the changes.
That's all folks. Nothing to see in this kafuffle except blatant attempted copyright theft and attempted absorbsion of BSD code into the maw of the GPL'd commune beast.
Move along and have some honesty with other peoples code please.
Cheers.
* Copyright (c) , * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are met: * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * Neither the name of the nor the * names of its contributors may be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
So someone categorized my earlier reply as off topic, sigh. Since the posting that I originally replied to included a signature footer including the statement "I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas" my comment was perfectly on topic. If anything his posting was off topic for including said signature. Commenting on signtures is perfectly valid.
103. Subject matter of copyright: Compilations and derivative works
(b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
To remove the copyright when you are not the copyright owner is a violation of copyright law. The original authors should be contacted and asked how they wish to proceed.
The original BSD code should at least be linked to or made available on the derivative site to clearly show the pedigree and respect the original authors rights.
When you use another's work and modify it you are creating a derivative work and possibly a compilation work. There are tests to be applied as to the extent of your changes. Changing a single word in a sentence of a comment or program line isn't enough to make a derivative work.
For example, lets say you take a BSD copyrighted program such as Apache, OpenBSD, FreeBSD, or any other large program and make some minor changes. If you modify a subroutine in a large program that's not a derivative work since that is a minor change and wouldn't qualify. In fact most contributions by folks to any large free or opensource projects don't qualify as new versions of the work and the copyright remains with the original authors.
Here is a summary from the US to back up the above assertion. http://www.copyright.gov/circs/circ14.html#derivat ive/ [copyright.gov] To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes.
Remember that while you can have all the open source or free software fantasies you wish the bottom line is that the copyright laws of your country and the country that the software originated from still apply and in many cases trump or nullify the license terms - sometimes in unexpected ways.
So in this case if the changes were minor the derivative works test fails, and the license MUST remain BSD as the subsequent work isn't a new copyrightable version!
Now the question is: how extensive where the changes? IF what was presented in this Slashdot thread is the entire source code AND it wasn't produced by the original author THEN one would easily see that it's not a new copyrightable work and the original authors copyright remains in full force with his BSD license terms.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Actually you are not merely a citizen of the state of texas, you are a Sentient Human Being which trumps all imaginary rules or categories such as "states", "texas", "taxpayer" or "consumer".
As a sentient human being you are a part of the universe that is alive and sentient. That is unique and special. It also infers powerful rights to you that the collective can't ever remove from you. Enjoy your power. Wisdom is advised however as others have the same immutable and powerful rights as you.
------- Chapter Two of Stephen Wolfram's A New Kind of Science is enough proof that God not only Doesn't exist but isn't needed except to placate the masses.
The fact that code released under the GPL can not be closed is a lack of freedom which BSD doesn't have. Not only is this a highly restrictive aspect of the GPL it's also the "totalitarian communistic" aspect of the GPL that attempts to enforce "social controls" on the software industry.
Before you get all McCarthy on me let me explain. Communistic in this case refers to the "community" and the high value that the GPL places upon keeping code available to the community as a whole - this is the principle of communism that I refer to: a higher value is placed on the rights of the community than the individual. GPL simply places higher values upon the rights of the community. BSD places high value on freedom to choose by the individual and the community.
The GPL's sad devotion to it's community (aka communistic) principle creates a lack of freedom and a number of serious adoption problems for many considering using, extending and modifying GPL'd software. The lack of choice is prevalent since the GPL requires one to share ones changes IF the resulting binaries are "distributed". Such arbitrary arrogance of control by the collective! When will it end, GPL v20.0 total social control? Yes you have freedom to choose to join the GPL collective, but after that your freedom is diminished significantly.
The BSD license enables full freedom. You are free to use, modify, edit, distribute (or not) the source or the binary. You are free to close the code! You are free to keep it open! That's total freedom and crucially important to innovation, the creative process and to the financial success for many of us. No adhering to totalitarian social control rules of the GPL restrictive license. Freedom to choose what you wish to do with the code when you wish to do it and how you wish to do it. Most importantly you can choose to change how you do it at anytime, unlike the GPL which requires you to adhere to the communistic party line at the moment you join and forever onwards.
Free software and open source software communistic free: BSD all the way!
As someone who has published software licensed the same software under the GPL and the BSD it's clear that BSD trumps GPL rules at anytime - allowing software published in this manner to override any GPL'd rule, phrase, sentence, paragraph or concept (and anything else I might have missed). Subsequent authors are of course free to do what they wish with it. Oh my god, they are even free to impose their draconian and totalitarian GPL license on their changes - IF AND ONLY IF their changes pass the derivative works test. HOWEVER, the original BSD license still applies to the original material - AND to minor changes that fail to pass the derivative works test! (See the second quoted text from the USA copyright office below for their derivative works test).
This is what the USA copyright act states:
103. Subject matter of copyright: Compilations and derivative works
(b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
To remove the copyright when you are not the copyright owner is a violation of copyright law. The original authors should be contacted and asked how they wish to proceed.
The original BSD code should at least be linked to or made available on the derivative site to clearly show the pedigree and respect the original authors rights.
When you use another's work and modify it you are creating a derivative work and possibly a compilation work. There are tests to be applied as to the extent of your changes. Changing a single word in a sentence of a comment or program line isn't enough to make a derivative work.
When I see a BSD user being so defensive in response to one of the World's oldest and most obvious trolls, I can only draw one conclusion - BSD must be dying.
And when I see comments such as yours it's obvious that you are the troll. However, even trolls need to be dealt with by a little thing known as a dose of reality.
The only way for *BSD to die is for all it's users to stop using it. That goes for Linux too, or Windows for that matter.
Death of software isn't the same as death of people since when a person dies it's game over for that person - eternal nothingness - non-existence brought to you.
When software dies that means that every copy has been destroyed or rendered unusable.
It's rare that a piece of software to actually die, especially one that is as widely distributed as *BSD. *BSD will live longer than you or your spawn (and their spawn) if you are lucky enough to have any.
All that's premature are your comments. Live long and prosper with whatever system(s) you are using. Oh, yeah, by limiting your system choices you are supporting a homogeneous mono culture and contributing to blandness which can only lead to Idiocracy. With your support we can make the Idiocracy happen much sooner.
Expand your view across the wider horizon that is out there for you to take advantage of: *BSD, Minix 3.x, EROS, MenuetOS, and of course there are these others listed here: http://en.wikipedia.org/wiki/List_of_operating_sys tems.
Then of course there is MacOSX which is a *BSD system with more users than all Linux installations combined; but then we wouldn't want facts to get in the way of your trolling now would we.
So using your logic, since MacOSX has more users than Linux, Linux must be dying. That's just flawed thinking buddy - get a brain and learn critical thinking skills.
The rumours of the death of *BSD systems are overblown and premature. The so called facts from the above "anonymous coward" are not facts at all but simply an opinion expressed by someone with an agenda.
If you don't use *BSD why would you care if it's living or dying? Why would you care if it's increasing in market share or declining?
The "anonymous cowards" opinions are irrelevant and likely incorrect anyhow. OpenBSD, NetBSD and FreeBSD are viable systems that have user communities that use them. It's not relevant how large those communities are.
In fact the so called Linux community isn't one community after all since there are reportedly over 300 distributions of systems that use the Linux kernel. So it's really *Linux and each of those distributions would break down to similar small groupings of users.
If your system works for you use it. If it doesn't, then adapt it or choose one that is better suited.
Today there was a very long outage of service from Comcast. I called and they didn't know there was an outage; it turned out that I was the first person to report it.
An hour later when it looked like it was working again I attempted to visit a web site and boom I was at their "download installation software" page for "new" or "existing" customers.
This of course prompted yet another call to Comcast since there is no way in hells acres that I'd ever install their software on my boxes just to connect to their service. After twenty minutes, they sheepishly explained this page as a "mis-provision" change to my account by the first Comcast operator who seems to have "messed" with my account configuration settings.
Things are working again fine after at least six hours of outage. No need to download any software once they fixed the provisioning of my account.
Comcast gets low marks: 3 out of 10 for quality of service calls. Customers who report problems should not be subjected to further problems just because they were the ones who reported it!
ps. A few months back I complained about twelve channels have static and lo and behold they turned off channels, and the others that were having static are still having static. I'd complain further but I'm moving out of this area in a week. Good riddance Comcast.
It seems that Apple is working with the LLVM group to replace the main parts of the GCC C, C++, Objective-C tool chain with a much more flexible system that supports static compilation as well as JIT and programs that can adjust their own code base at runtime. Objective-C is based on some notions of Smalltalk which has such a dynamic JIT environment. Apple seems to be moving towards a more runtime interactive tool chain with it's C language program base. One of the Apple people at the LLVM conference even mentioned some work with Smalltalk and LLVM. Objective-C as used in WebObjects has a much more dynamic feel to it.
It's interesting that the LLVM project's technological choices and their BSD-style license are both highly compatible with Apple's technological and business strategies.
As for CUPS it may make sense for Apple to keep it GPL'd for now. As others have undoubtedly noted it's now Apple's choice of whether or not to share their code changes with the community since they now own a large amount of the code base of CUPS. This approach to taking over GPL'd projects may well see a surge. This is a good opportunity for the primary developers of some GPL'd software projects if they desire to keep working on their projects full time.
The low adoption threshold of BSD enables choices that are prevented by the GPL. It is very interesting that Apple found a way to control a GPL'd project that seems important to them. Of course Apple may approach the CUPS and LLVM projects completely differently since they have different strategic and technological values. The LLVM project enables Apple to advance their C-base code library forward with linguistic enhancements that advanced languages like LISP, Smalltalk, Self, IO, and others have while keeping backwards compatibility and low-level static performance capabilities.
The fusion of dynamic and static languages continues with an interesting future at Apple.
If you go to Panera and order their "Pick Two" (of 1/2 sandwitch, soup or salad) plus a Washington Post paper (35 cents) you'll end up with a total of $6.66. Of course you must pay with six ones, six dimes and six pennies.
Yes, "I'll believe it when I see it" is a common expression that usually isn't meant to be taken literally. Often there is a fine line between "figures of speech" and "literal denotations". Since the prelevant social cult(ure) is based upon "belief" and "faith", rather than re-testable-knowledge, many of our figures of speech are actually belief reinforcers encouraging people to accept the whole concept of belief as a valid way of life. I'll therefore, choose to not-believe but seek knowledge instead, if and when it's possible to do so. This involves examining your own belief systems and learning self transformation technologies to alter ones beliefs so that they either don't exist or are more evidence based. Check out the neuro-linguistic works of Robert Dilts and Milton Erickson. While it may not be possbile to eliminate beleifs from one's life entirely it's desireable to reduce them to a dull roar rather than letting them drive your life. Be the belief reducing/illuminating/eliminating zone, by replacing belief with fact or knowledge when posisble.
In the case of Cold Fusion - an area of "science" that is chock full of beliefs and un-re-testable theories and claims - it's best to raise the standards of discussion to zero-belief tollerance even in "non-literal expressions".
Science isn't about belief, so why would you believe it? How about going beyond belief to actual knowledge? For this we'll just have to either build one ourselves or wait till one reaches the market, or seeing one demonstrated live might also work to begin to enter the domain of knowledge on this device.
Belief has it's place. A belief in the future, sure, but belief in some science experiment. Yikes, that sounds like religion. Ick, if it floats it must be a duck, sheesh.
Beliefs are suspect. Take knowledge when possible, and question that too.
Re:Declare your bias, why don't you?
on
OpenBSD 3.7 Reviewed
·
· Score: 3, Insightful
Are you talking about the so called "freedom" that code has under the GPL that "keeps" it open? That's not really freedom as it comes at a cost, a large cost, the authors "give up" their "rights" is the cost. Now they might want to do that and pay that price (which is perfectly fine if they choose to do so), but afterwards they are no longer free to do what they want with the code, and neither are users who might choose to use the code as the "many rules" of the GPL will keep you in line with the "commune of the GPL".
Freedom isn't the right word for the GPL'd code. It's too bad that Richard Stallman usurped that word. Yes, you get some freedom but it's more like a restricted freedom only if you obey the party line, and that's not true freedom at all since your freedom is restricted. Restricted-freedom-at-a-high-cost is more like it... or Freedom-with-legirons.
The BSD license with its minimal terms gives authors and users maximal choices including the freedom to modify the code and not release it and sell such modifications! That's true freedom of choice for authors and users! That's simply not an option if you want to stay within the terms of the agreement with the GPL! So the GPL isn't "free" in a way that the BSD is free.
Re:Declare your bias, why don't you?
on
OpenBSD 3.7 Reviewed
·
· Score: 3, Insightful
I'll bite. How isn't BSD "free enough"?
Are you talking about the so called "freedom" that code has under the GPL that "keeps" it open? That's not really freedom as it comes at a cost, a large cost, the authors "give up" their "rights" is the cost. Now they might want to do that and pay that price (which is perfectly fine if they choose to do so), but afterwards they are no longer free to do what they want with the code, and neither are users who might choose to use the code as the "many rules" of the GPL will keep you in line with the "commune of the GPL".
Freedom isn't the right word for the GPL'd code. It's too bad that Richard Stallman usurped that word. Yes, you get some freedom but it's more like a restricted freedom only if you obey the party line.
The BSD license with its minimal terms gives authors and users maximal choices including the freedom to modify the code and not release it and sell such modifications! That's simply not an option if you want to stay within the terms of the agreement with the GPL! So the GPL isn't "free" in a way that the BSD is free.
These two licences aim at different audiences and use different methods (minimal v.s. wordy) to achive their goals.
The BSD is about "freedom of choice" of BOTH authors and users.
The GPL doesn't care about users or authors. It simply cares about the code and will impose whatever restrictions by having users and authors surrender their natural and legal rights to the commune of the GPL.
Which do you want? The freedom of choice or the rules of the GPL commune you wish to live under! It's your own personal choice until you commit your code to one of them (or another licence scheme of your choice). Choose wisely and after consideration is my best advise. Be free, stay free.
It is not possible to be a scientist and believe in any gods. Why?
God beliefs are just that, beliefs or faith, and as a result unscientific.
While you might be scientific about a great many things in your life, you state that you follow your heart and believe in God. So you admit to being non-scientific in your belief, therefor you are not "being" a scientist with regard to your "belief" in God, therefor you "are" not a scientist.
Show me conclusive reproducable proof of God, of life after Death, of ESP, of psychic powers, of the super natural, of ____ and I won't need to believe in it, as it will have been proven, and can be proven over and over again; otherwise you're just spewing delusional mind poo.
Slashdot Mirror
You are incorrect on both counts.
It is illegal to remove the BSD license since the BSD license specifically states that the BSD license terms must be retained with the software. This applies even if a derived work is made or if a work is made that doesn't qualify as derived under copyright laws.
Here are the BSD terms that state this:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
That's pretty clear.
As for "evil", well that depends upon how you define evil doesn't it. Let's use a general purpose definition: yes it's evil or rather "unethical" since it's clearly a violation of copyright law.
That's why you are wrong on both points and why Theo is correct on both points.
Certainly the spirit of sharing is violated by attempting to state that it's only GPL'd in the case of a dual license. It's also crucial that the patch in question isn't a new derivative work and thus doesn't qualify as a copyrightable work by the new authors. This means that the changes must be distributed under the original license or licenses since they remain in effect even upon minor changes authored by authors other than the original authors. If in fact the driver was dual licensed then the changes must be distributed under both licenses.
Hair splitting is often what lawyers do therefore the analysis I have performed is very relevant and very possibly will be tested in court in this case or others.
Remember the entirely of copyright law applies and is enhanced by the BSD license terms. Tread carefully least a big legal stick meet you in your journey with software.
How did you obtain that assessment? I never said that.
Let's think it through though now that you brought it up. Assuming the dual licenses are BSD and GPL it would seem that there is a conflict between the two licenses with the GPL saying that source must be shipped with any binary distributions while the BSD saying that binaries may be shipped with or without the source code at the developers choice. This is one of the quintessential gaps between these two licenses that is at the core of the philosophical battles raging in many places and projects.
Since the BSD explicitly permits the binary only distribution option developers may ship only the binary if they so choose as the license permits This is true if both licenses are alternatives since the developer can choose either license. All they need do is ship with the BSD license and indicate that that was their choice. This assumes that the work isn't a derived work under copyright law - as most changes, additions, updates, or modifications don't qualify as derived works under copyright law the new work isn't copyrightable.
Regardless derived works (as defined by copyright laws and court cases) must preserve the terms of the BSD license since that is explicitly stated in the license of original works licensed under BSD style licenses. This means that the BSD license can never be removed! This also means that the original code is forever under the BSD license even when embedded or fractured into a new derived work.
It should also be noted that the original authors retain all their rights to derived works! This has serious implications.
The GPL terms only come into play when the developer chooses to distribute their changes (assuming that they pass the test of being different enough and thus a derivative work under copyright laws and court cases) under the GPL terms. However, if the changes - when merged with the original work - don't qualify as a new copyrightable work the new authors have no say in the matter and the changes MUST BE DISTRIBUTED under BOTH licenses!!! This is a crucial point and one that will likely be tested in court, possibly as a result of this dispute or one like it.
Why must minor changes be distributed under both licenses at the discretion of the original works authors? Because they are the ones who control the original work and when the new author makes changes to the original work that don't qualify as derived works (as defined by copyright law and court cases) the new author has no control over their work once they merge it into the original work. Legal advice obtained a few days ago on this point suggest that the new authors consider their changes as a gift to the original authors to minimize the legal problems they could face. For proprietary software the original authors would likely seek an injunction to prevent the new changes. In open source the original authors usually welcome the "gift" of minor changes from new authors even if these changes are unsolicited. Often these changes are incorporated into the original work and redistributed. The key point to understand is that it's optional for the original authors to extend any copyright ownership in their original work to new authors minor changes - often they might do so out of courtesy and often they simply don't. It's up to them. With major changes though (see the definition of derivative works under copyright law) the work may qualify as a derivative work and the new authors may gain copyright status of their own. At that point the original work if merged with the new work gains a new co-author and the license must be updated to include all the authors of the new copyrightable work and the original work (unless a fork occurs in which case they are now two distinct works).
This has serious implications for forking and how much the original authors may control or impact forks of software systems.
How deep does this rabbit hole descend? I'm afraid we will find out and that the damage to open source and free source projects will be significant unless they cooperate with the spirit of sharing fairly and with integrity.
See my earlier comment for a more indepth reply.
m l#derivative/ [copyright.gov]
No, you can't relicense BSD software even if you create a valid derived work with it. Why not? Copyright laws and the BSD license terms. Read them again. Read copyright law again.
To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes.http://www.copyright.gov/circs/circ14.ht
Since the original authors have not given up their rights to derived works they still have control over them allowed by copyright laws and court cases. The portions of the original work must still be made under the original license since the BSD license terms state that. That can't be changes without violating copyrights even if the original work is embedded within a derived work! You must give credit due to the BSD license terms! You must include the BSD license terms even in derived works or works that include even tiny portions of BSD code!
Since most changes to open source software are not derived works the original authors still have control over them. This seems to the be the case with the software driver patch in question.
Yes, you seem to have written that, however your conclusion doesn't apply since the GPL has many other significant and restrictive conditions that nullify the simplistic comparison that you put forward. You have to look beyond the surface comparison to the deeper interactions that the two licenses have upon works they impact. You must agree that in totality these are radically different approaches: GPL and BSD licenses. Since that is obvious then it's easy to see how a simplistic comparison fails.
Take one point in particular that devastates your assessment: the GPL virally requires new changes to be under the GPL license while the BSD license doesn't - however the original work MUST remain under the BSD license and that includes all the code expressed in it unless you take a tiny portion under fair use. How can this be? Since most changes, modifications, updates, or additions to most software projects that are open source or free source, and like the patch to the BSD based driver that is in question, are not significant enough or don't change the original work to be different enough they are not derivative works and thus not entitled to be copyrighted under copyright laws regarding derivative works.
The implication of copyright laws for BSD licensed original works is that minor changes, such as a patch for Linux, fail to achieve their own copyright status meaning that the BSD license is in full force. Good legal advice (and yes I did ask a software lawyer about this point since this story broke) has it that it's best to consider one's "contribution", such as the "patch" in question, as a gift to the original author(s) - a gift in the sense that it's a transfer of ownership from the minor change author to the original author(s) in a legal sense. Once the "patch" is merged with an original work it no longer is owned by the author of the patch in it's merged form (assuming it's not a derivative work under copyright law).
The implications of minor changes that don't qualify as derived works that are merged into original open source or free source software programs is that most of them are gifts and not copyrightable by the authors of the minor changes.
This is very serious indeed and requires careful analysis in this case with the "patch" to the BSD driver in question as well as in every contribution by anyone to any software project (open source, free source or proprietary in nature). This could shake the foundations of the whole basis of open source and free source software and require additional clauses in licenses to deal with this gray area. For there is no doubt that it's a gray area with the potential for many legal victories and defeats for our intrepid heroes involved.
It's a gray area since the question of what constituents a derivative work under copyright law and court decisions isn't black and white. It's clear that minor changes don't qualify as derivative works. The changes must be significant in size or cause the resulting work to be different enough from the original work for the new resulting work to be considered copyrightable on it's own. Naturally one can see that this also depends on many factors such as how large the original work is in comparison to the resulting work. For example, adding a few subroutines to Firefox or Apache wouldn't result in a new derived work due to the size differences. Furthermore, it would take quite a bit of work to significantly change Firefox or Apache to be "different" enough in it's fundamental operation to be considered a derivative work. Following this reasoning most changes to these projects are not derivative works and the merged code enters this gray area where the courts are likely to rule in favor of the original authors due to the language of copyright law in regards to derivative works.
So, yes, in this case it would seem that IF the author of the "patch" isn't the original author of the BSD driver AND IF the "patch" doesn't constitute a new derived work under copyright law (and applicable court cases) THEN the "patch" M
The "GPL" isn't about giving back to the community. It isn't giving if it's by force. Since the GPL mandates that the changes be distributed in source it's not giving back to the community. It's the community taking the changes by legal force.
c id=20399923
Theo's issue goes beyond the license to common practices. Most BSD projects receive changes back from people simply because it's in everyone's benefit that those changes make it into the mainline distribution of said projects. Now people are free to distribute their changes as they see fit however they are still bound by copyright laws and the license.
The changes to the driver do not seem to be significant and don't make the driver different enough to warrant be classified as a derivative work; thus the new author - once his changes are merged - doesn't gain any copyright into the work (the driver in this case). His changes become part of a non-derived original work and he has no rights to it. In fact it's best to consider it a gift to the original authors under their license terms and ownership.
It's the merging of changes into another's work that is the issue. Do you changes constitute a derivative work or not? Usually they don't. Too bad. You've given your code to the original author and they can control what to do with it once it's been merged.
Of course you might have a copyright in your patch as a separate entity as long as it stays a separate entity only. That would make it useless since it's value is when it's merged into the original work.
For reference: http://linux.slashdot.org/comments.pl?sid=282341&
...if someone makes the tiniest change to the code and only licenses their change under the GPLv2, then the entirety of the software can only be distributed under...
"If someone makes the tiniest change to the code" then their code when merged with the original work isn't a derived work and can't be copyrighted - the new changes become part of the original work. Copyright law requires a substantial change or a change that makes the new work different enough to be considered a derivate work and thus deserving of a copyright.
While your tiny changes by themselves might be copyright by you when you merge them into an original work written by one or more other people your work is essentially a gift to that project under their copyright and ownership. Unless, your changes are significant or different enough it's important to be aware of this.
I suspect that it is the case with most contributions to open source projects that have any size to the program(s) are actually gifts to the original authors work since most changes don't significantly modify or make the work different enough to deserve to be called a derivative. Given this reasoning the entire open source industry and communities must re-evaluate the basis of their contributions since most contributions when added to the work don't confer any rights to those giving the changes.
Ironically, as all of the conditionals imposed by the BSD license are also imposed by the GPL, this means there is no practical difference between distributing under the GPL and distributing under a "dual licensed" BSD and GPL.
Ah, no, your assessment is incorrect. While the GPL license may seem to the same conditionals the GPL imposes many many other conditionals upon developers that make it significantly different than the BSD license. In this regard they are totally different.
BSD enables many other choices that the GPL specifically prevents. This is why the GPL is known as "restrictive", "viral", and "communistic" in it's nature.
If the license is dual then both license terms must move forward with the new derived work - if indeed it's a new derived work which it most likely isn't by the definition of derivative works under copyright law. If it's not a new derived work then the changes made to it belong to the author of the original work per copyright law.
While the license gives you permission to modify the files that it covers it doesn't give you permission to modify the license.
Have you even read the BSD license? It's easy, it's only three (or four) paragraphs. Let's grab a copy from http://en.wikipedia.org/wiki/BSD_licenses and see what it has to say.
First off notice that it says copyright by someone.
Then it goes on about redistribution and use but with some conditions. What would they be? Oh, one of the conditions is that the license itself must be retained. How about that. The license must be retained. So you can't modify the license! It says so right there. Copyright law also has some input on that too, but enough said.
Now there is an exception of course, and that is if you are the original author or if all the original authors authorize the changes.
That's all folks. Nothing to see in this kafuffle except blatant attempted copyright theft and attempted absorbsion of BSD code into the maw of the GPL'd commune beast.
Move along and have some honesty with other peoples code please.
Cheers.
* Copyright (c) ,
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of the nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL BE LIABLE FOR ANY
* DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Hi,
So someone categorized my earlier reply as off topic, sigh. Since the posting that I originally replied to included a signature footer including the statement "I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas" my comment was perfectly on topic. If anything his posting was off topic for including said signature. Commenting on signtures is perfectly valid.
Thanks.
This is what the USA copyright act states:
t ive/ [copyright.gov]
103. Subject matter of copyright: Compilations and derivative works
(b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
To remove the copyright when you are not the copyright owner is a violation of copyright law. The original authors should be contacted and asked how they wish to proceed.
The original BSD code should at least be linked to or made available on the derivative site to clearly show the pedigree and respect the original authors rights.
When you use another's work and modify it you are creating a derivative work and possibly a compilation work. There are tests to be applied as to the extent of your changes. Changing a single word in a sentence of a comment or program line isn't enough to make a derivative work.
For example, lets say you take a BSD copyrighted program such as Apache, OpenBSD, FreeBSD, or any other large program and make some minor changes. If you modify a subroutine in a large program that's not a derivative work since that is a minor change and wouldn't qualify. In fact most contributions by folks to any large free or opensource projects don't qualify as new versions of the work and the copyright remains with the original authors.
Here is a summary from the US to back up the above assertion.
http://www.copyright.gov/circs/circ14.html#deriva
To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes.
Remember that while you can have all the open source or free software fantasies you wish the bottom line is that the copyright laws of your country and the country that the software originated from still apply and in many cases trump or nullify the license terms - sometimes in unexpected ways.
So in this case if the changes were minor the derivative works test fails, and the license MUST remain BSD as the subsequent work isn't a new copyrightable version!
Now the question is: how extensive where the changes? IF what was presented in this Slashdot thread is the entire source code AND it wasn't produced by the original author THEN one would easily see that it's not a new copyrightable work and the original authors copyright remains in full force with his BSD license terms.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Actually you are not merely a citizen of the state of texas, you are a Sentient Human Being which trumps all imaginary rules or categories such as "states", "texas", "taxpayer" or "consumer".
As a sentient human being you are a part of the universe that is alive and sentient. That is unique and special. It also infers powerful rights to you that the collective can't ever remove from you. Enjoy your power. Wisdom is advised however as others have the same immutable and powerful rights as you.
-------
Chapter Two of Stephen Wolfram's A New Kind of Science is enough proof that God not only Doesn't exist but isn't needed except to placate the masses.
The fact that code released under the GPL can not be closed is a lack of freedom which BSD doesn't have. Not only is this a highly restrictive aspect of the GPL it's also the "totalitarian communistic" aspect of the GPL that attempts to enforce "social controls" on the software industry.
Before you get all McCarthy on me let me explain. Communistic in this case refers to the "community" and the high value that the GPL places upon keeping code available to the community as a whole - this is the principle of communism that I refer to: a higher value is placed on the rights of the community than the individual. GPL simply places higher values upon the rights of the community. BSD places high value on freedom to choose by the individual and the community.
The GPL's sad devotion to it's community (aka communistic) principle creates a lack of freedom and a number of serious adoption problems for many considering using, extending and modifying GPL'd software. The lack of choice is prevalent since the GPL requires one to share ones changes IF the resulting binaries are "distributed". Such arbitrary arrogance of control by the collective! When will it end, GPL v20.0 total social control? Yes you have freedom to choose to join the GPL collective, but after that your freedom is diminished significantly.
The BSD license enables full freedom. You are free to use, modify, edit, distribute (or not) the source or the binary. You are free to close the code! You are free to keep it open! That's total freedom and crucially important to innovation, the creative process and to the financial success for many of us. No adhering to totalitarian social control rules of the GPL restrictive license. Freedom to choose what you wish to do with the code when you wish to do it and how you wish to do it. Most importantly you can choose to change how you do it at anytime, unlike the GPL which requires you to adhere to the communistic party line at the moment you join and forever onwards.
Free software and open source software communistic free: BSD all the way!
As someone who has published software licensed the same software under the GPL and the BSD it's clear that BSD trumps GPL rules at anytime - allowing software published in this manner to override any GPL'd rule, phrase, sentence, paragraph or concept (and anything else I might have missed). Subsequent authors are of course free to do what they wish with it. Oh my god, they are even free to impose their draconian and totalitarian GPL license on their changes - IF AND ONLY IF their changes pass the derivative works test. HOWEVER, the original BSD license still applies to the original material - AND to minor changes that fail to pass the derivative works test! (See the second quoted text from the USA copyright office below for their derivative works test).
This is what the USA copyright act states:
103. Subject matter of copyright: Compilations and derivative works
(b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material.
To remove the copyright when you are not the copyright owner is a violation of copyright law. The original authors should be contacted and asked how they wish to proceed.
The original BSD code should at least be linked to or made available on the derivative site to clearly show the pedigree and respect the original authors rights.
When you use another's work and modify it you are creating a derivative work and possibly a compilation work. There are tests to be applied as to the extent of your changes. Changing a single word in a sentence of a comment or program line isn't enough to make a derivative work.
For exampl
When I see a BSD user being so defensive in response to one of the World's oldest and most obvious trolls, I can only draw one conclusion - BSD must be dying.
s tems.
And when I see comments such as yours it's obvious that you are the troll. However, even trolls need to be dealt with by a little thing known as a dose of reality.
The only way for *BSD to die is for all it's users to stop using it. That goes for Linux too, or Windows for that matter.
Death of software isn't the same as death of people since when a person dies it's game over for that person - eternal nothingness - non-existence brought to you.
When software dies that means that every copy has been destroyed or rendered unusable.
It's rare that a piece of software to actually die, especially one that is as widely distributed as *BSD. *BSD will live longer than you or your spawn (and their spawn) if you are lucky enough to have any.
All that's premature are your comments. Live long and prosper with whatever system(s) you are using. Oh, yeah, by limiting your system choices you are supporting a homogeneous mono culture and contributing to blandness which can only lead to Idiocracy. With your support we can make the Idiocracy happen much sooner.
Expand your view across the wider horizon that is out there for you to take advantage of: *BSD, Minix 3.x, EROS, MenuetOS, and of course there are these others listed here: http://en.wikipedia.org/wiki/List_of_operating_sy
Then of course there is MacOSX which is a *BSD system with more users than all Linux installations combined; but then we wouldn't want facts to get in the way of your trolling now would we.
So using your logic, since MacOSX has more users than Linux, Linux must be dying. That's just flawed thinking buddy - get a brain and learn critical thinking skills.
Hi,
The rumours of the death of *BSD systems are overblown and premature. The so called facts from the above "anonymous coward" are not facts at all but simply an opinion expressed by someone with an agenda.
If you don't use *BSD why would you care if it's living or dying? Why would you care if it's increasing in market share or declining?
The "anonymous cowards" opinions are irrelevant and likely incorrect anyhow. OpenBSD, NetBSD and FreeBSD are viable systems that have user communities that use them. It's not relevant how large those communities are.
In fact the so called Linux community isn't one community after all since there are reportedly over 300 distributions of systems that use the Linux kernel. So it's really *Linux and each of those distributions would break down to similar small groupings of users.
If your system works for you use it. If it doesn't, then adapt it or choose one that is better suited.
UPDATE
Today there was a very long outage of service from Comcast. I called and they didn't know there was an outage; it turned out that I was the first person to report it.
An hour later when it looked like it was working again I attempted to visit a web site and boom I was at their "download installation software" page for "new" or "existing" customers.
This of course prompted yet another call to Comcast since there is no way in hells acres that I'd ever install their software on my boxes just to connect to their service. After twenty minutes, they sheepishly explained this page as a "mis-provision" change to my account by the first Comcast operator who seems to have "messed" with my account configuration settings.
Things are working again fine after at least six hours of outage. No need to download any software once they fixed the provisioning of my account.
Comcast gets low marks: 3 out of 10 for quality of service calls. Customers who report problems should not be subjected to further problems just because they were the ones who reported it!
ps. A few months back I complained about twelve channels have static and lo and behold they turned off channels, and the others that were having static are still having static. I'd complain further but I'm moving out of this area in a week. Good riddance Comcast.
Ah Dwater,
That was a joke, and the meaning was correct and clear. Language is flexible, get used to it.
Cheers,
Peter
I'm a Comcast customer and use firefox and safari on Mac OSX and Windows without any issues with Comcast whatsoever!
Are you saying that you hate their customers too? ;--)
It seems that Apple is working with the LLVM group to replace the main parts of the GCC C, C++, Objective-C tool chain with a much more flexible system that supports static compilation as well as JIT and programs that can adjust their own code base at runtime. Objective-C is based on some notions of Smalltalk which has such a dynamic JIT environment. Apple seems to be moving towards a more runtime interactive tool chain with it's C language program base. One of the Apple people at the LLVM conference even mentioned some work with Smalltalk and LLVM. Objective-C as used in WebObjects has a much more dynamic feel to it.
It's interesting that the LLVM project's technological choices and their BSD-style license are both highly compatible with Apple's technological and business strategies.
As for CUPS it may make sense for Apple to keep it GPL'd for now. As others have undoubtedly noted it's now Apple's choice of whether or not to share their code changes with the community since they now own a large amount of the code base of CUPS. This approach to taking over GPL'd projects may well see a surge. This is a good opportunity for the primary developers of some GPL'd software projects if they desire to keep working on their projects full time.
The low adoption threshold of BSD enables choices that are prevented by the GPL. It is very interesting that Apple found a way to control a GPL'd project that seems important to them. Of course Apple may approach the CUPS and LLVM projects completely differently since they have different strategic and technological values. The LLVM project enables Apple to advance their C-base code library forward with linguistic enhancements that advanced languages like LISP, Smalltalk, Self, IO, and others have while keeping backwards compatibility and low-level static performance capabilities.
The fusion of dynamic and static languages continues with an interesting future at Apple.
If you go to Panera and order their "Pick Two" (of 1/2 sandwitch, soup or salad) plus a Washington Post paper (35 cents) you'll end up with a total of $6.66. Of course you must pay with six ones, six dimes and six pennies.
Enjoy
Yes, "I'll believe it when I see it" is a common expression that usually isn't meant to be taken literally. Often there is a fine line between "figures of speech" and "literal denotations". Since the prelevant social cult(ure) is based upon "belief" and "faith", rather than re-testable-knowledge, many of our figures of speech are actually belief reinforcers encouraging people to accept the whole concept of belief as a valid way of life. I'll therefore, choose to not-believe but seek knowledge instead, if and when it's possible to do so. This involves examining your own belief systems and learning self transformation technologies to alter ones beliefs so that they either don't exist or are more evidence based. Check out the neuro-linguistic works of Robert Dilts and Milton Erickson. While it may not be possbile to eliminate beleifs from one's life entirely it's desireable to reduce them to a dull roar rather than letting them drive your life. Be the belief reducing/illuminating/eliminating zone, by replacing belief with fact or knowledge when posisble.
In the case of Cold Fusion - an area of "science" that is chock full of beliefs and un-re-testable theories and claims - it's best to raise the standards of discussion to zero-belief tollerance even in "non-literal expressions".
Science isn't about belief, so why would you believe it? How about going beyond belief to actual knowledge? For this we'll just have to either build one ourselves or wait till one reaches the market, or seeing one demonstrated live might also work to begin to enter the domain of knowledge on this device.
Belief has it's place. A belief in the future, sure, but belief in some science experiment. Yikes, that sounds like religion. Ick, if it floats it must be a duck, sheesh.
Beliefs are suspect. Take knowledge when possible, and question that too.
Are you talking about the so called "freedom" that code has under the GPL that "keeps" it open? That's not really freedom as it comes at a cost, a large cost, the authors "give up" their "rights" is the cost. Now they might want to do that and pay that price (which is perfectly fine if they choose to do so), but afterwards they are no longer free to do what they want with the code, and neither are users who might choose to use the code as the "many rules" of the GPL will keep you in line with the "commune of the GPL".
Freedom isn't the right word for the GPL'd code. It's too bad that Richard Stallman usurped that word. Yes, you get some freedom but it's more like a restricted freedom only if you obey the party line, and that's not true freedom at all since your freedom is restricted. Restricted-freedom-at-a-high-cost is more like it... or Freedom-with-legirons.
The BSD license with its minimal terms gives authors and users maximal choices including the freedom to modify the code and not release it and sell such modifications! That's true freedom of choice for authors and users! That's simply not an option if you want to stay within the terms of the agreement with the GPL! So the GPL isn't "free" in a way that the BSD is free.
I'll bite. How isn't BSD "free enough"?
Are you talking about the so called "freedom" that code has under the GPL that "keeps" it open? That's not really freedom as it comes at a cost, a large cost, the authors "give up" their "rights" is the cost. Now they might want to do that and pay that price (which is perfectly fine if they choose to do so), but afterwards they are no longer free to do what they want with the code, and neither are users who might choose to use the code as the "many rules" of the GPL will keep you in line with the "commune of the GPL".
Freedom isn't the right word for the GPL'd code. It's too bad that Richard Stallman usurped that word. Yes, you get some freedom but it's more like a restricted freedom only if you obey the party line.
The BSD license with its minimal terms gives authors and users maximal choices including the freedom to modify the code and not release it and sell such modifications! That's simply not an option if you want to stay within the terms of the agreement with the GPL! So the GPL isn't "free" in a way that the BSD is free.
These two licences aim at different audiences and use different methods (minimal v.s. wordy) to achive their goals.
The BSD is about "freedom of choice" of BOTH authors and users.
The GPL doesn't care about users or authors. It simply cares about the code and will impose whatever restrictions by having users and authors surrender their natural and legal rights to the commune of the GPL.
Which do you want? The freedom of choice or the rules of the GPL commune you wish to live under! It's your own personal choice until you commit your code to one of them (or another licence scheme of your choice). Choose wisely and after consideration is my best advise. Be free, stay free.
It is not possible to be a scientist and believe in any gods. Why?
God beliefs are just that, beliefs or faith, and as a result unscientific.
While you might be scientific about a great many things in your life, you state that you follow your heart and believe in God. So you admit to being non-scientific in your belief, therefor you are not "being" a scientist with regard to your "belief" in God, therefor you "are" not a scientist.
Show me conclusive reproducable proof of God, of life after Death, of ESP, of psychic powers, of the super natural, of ____ and I won't need to believe in it, as it will have been proven, and can be proven over and over again; otherwise you're just spewing delusional mind poo.