I actually think that Tivo is a proxy for the FSF's concerns over untrustworthy computing. The big issues I have are 1) no software license which doesn't start blacklisting technologies or intentions to support technologies can address this. Imagine, for example, that we create a hardware/vm system where the OS is not trusted and certain areas of memory are encrypted to prevent OS access. Imagine further that the encryption is handled via a hardware/firmware solution and that Linux talks to that hardware through a very simple driver. Hence the keys for the encryption are not handled by the OS. We can now let a GPL v3 hypothetical Linux run without compromosing the DRM because the hardware and user-mode components don't have to trust the kernel. 2) there are sound economic reasons to suggest that Tivo's approach is short-minded and that untrustworthy computing will probably not become the technology that the media companies want it to be anyway. Why go looking for solutions in search of imaginary problems? However, I am willing to forgive this as an honest mistake made in concern for the freedoms that the FSF expounds even given areas I feel are less-than-idealistic (see below).
The bigger issue in my mind, however, was the question of compatibility with the Afferro Public License which contains explicit restrictions about how the code can be altered such that you must provide access tothe source of the application over whatever network sessions the user connects to it. I see this as 1) very EULA-like and 2) very onerous. The original approach, allowing the GPL v3 to adopt these provisions as optional clauses would have eventually sought to drag every networked application into this mess and would have seriously curtailed the ability to modify an application for one's own use (part of Freedom 1) and distribute such modifications (part of freedom 3).
While the heavy-handed approach in the earlier drafts did not make it into the final draft, the problem I have has to do with the rationale document, which gave only one reason for the change: that it added complexity. There was *no* discussion or acknowledgement in the FSF's official rationale for the change regarding the question of software freedom. I am therefore left to conclude that the question of whether this was a legitimate abridgement of freedom was *never* an issue for the FSF.
Early drafts of the GPL v3 were non-free based on other criteria already established by the FSF including the fact that it put limits on what could be charged (see their concerns of the Reciprocal Public License). In short, I think that early drafts of the GPL v3 were clearly not Free Software licenses under the standards set forth by the FSF and I do not think that meeting those standards was a high priority.
A linking exception as you suggested may help increase compatibility with other licenses, but by increasing compatibility with Free Software licenses it also increases compatibility with proprietary licenses. This may or may not be desired by the copyright holder, and its desirability is dependent on the nature of the program, which is why it isn't built into the GPL. Howso? How does allowing GPL code to *link* against old-style BSD licenses mean more compatibility with proprietary apps? If you are worried that someone could write an old-style BSD licensed bridge between proprietary code and GPL code, the same holds true already for LGPL and new-style BSD code. The *only* exception is the obnoxious advertising clause. How does that work exactly?
Of course, this problem would go away if everyone used the GPL (or a BSD-style license in appropriate cases); the problem only exists because multiple Free Software licenses do. Not that the GPL is perfect, but I don't believe any of its flaws are sufficient reason to use another license (excluding BSD-style licenses for cases where universal adoption is required) without good reason. Agreed regarding the GPL v2. However, I think that the GPL v3 is a step back from the practical extension of the 4 basic freedoms into a war-on-terror "sacrifice freedom for the greater good" mentality.
1) Write softare that uses OpenSSL in a way as to be a derivative work of that software despite the fact that OpenSSL is Free Software by the FSF's own definition (and they even classify the license as Free).
2) create software which is derivative of GPL v 2 (only) software and Apache License v2 software even though both are Free Software licenses by the FSF's terms.
3) Create software which is derivative both of GPL software (any version) and Mozilla Public License software even though both respect the 4 basic freedoms.
The GPL is the best tool we have to release software we want to do open source without having other companies proprietize it. But it does have other restrictions which go beyond the "you can't take other people's freedom."
I would like to see a list of linking exceptions built into the GPL. It would go a long way toward actually resticting the limitations to what you say.
1) in line with the OSI definition of open source. In fact the OSI seems to have bent over backwards to include Qmail in that they specifically allow the distribution of a base package plus patches.
2) Not represented as open source by its maintainer.
This is what I said and I will stand by it. You have not yet contradicted me:-)
Not necessarily. I am not entirely sure where the boundary between use and preparing derivative works may lie in regards to installing and configuring software, particularly if the config file is a script itself that is run. In essence as soon as you alter one line of PHP even if it is a config file, you may arguably be preparing a derivative work which may put you out of compliance.
Furthermore, not all jurisdictions internationally may see installation of software as necessarily fair use and hence the mere act of installing the software may or may not be permissible under the GPL depending on where you live (IANAL, but I believe that US law does treat installation of software and running of software as protected activities. Were they not, they would be covered under the GPL itself, and use is not defined in the GPL in such a way as would necessarily provide the right to install the software).
Finally, what is wrong with allowing people to choose licenses for other software that interoperates with your own software? Is the goal to coerve everyone to use GPL-compatible licenses? Or is it to build software which is truly Free? Are you *that* insecure about your position that you cannot tolerate other licenses? Why should the Afferro Public License get a linking exception but not the old-style BSD license?
Finally a note on the BSD license. The GPL and BSD licenses have different strengths and weaknesses. If you are launching a business product and do not want your competitors to take it and run, the GPL is a good license for that. My business uses it in the vast majority of our work. However, it is not the only way. PostgreSQL and Apache both have built very large and vibrant communities on the principle that people contribute back for various reasons and that such contributions should be freely given (and not coerced). Sure both projects have proprietary spinoffs, but in both cases, the core program undergoes such rapid development that no other company wants to get stuck with more maintenance work than necessary, so they contribute back everything they can (meaning everything that is not part of their differentiation strategy and that the community is interested in. An example of what is not contributed back to PostgreSQL is EnterpriseDB's Oracle Compat stuff that the PostgreSQL community rightly doesn't want anyway).
And releasing a reference implementation under the GPL would be silly and counterproductive (which both PostgreSQL and Apache started out as). The only issue with the BSD license is that software developers may be less inclined to share code in a community which has players which are likely to proprietize that code unless they can ensure very wide-spread distribution. Hence if I had a cool PostgreSQL add-in and the core team was not interested, I would have to think long and hard before giving EnterpriseDB and the like a competitive stick to beat me with (if it went core that would be another matter).
All software lives or dies on the basis of community. License choices are secondary to community management issues. And all software licenses suck:-)
In fact software wins or loses in the competitive marketplace on the basis of community. The choice of BSD vs GPL makes some difference for many projects but neither one necessarily precludes success over competitors. In fact the superior development pace of Linux over *bsd has more to do with community management issues than licensing choices.
BTW, for all the things I say against the GPL, it is because I work with the license a lot and will continue to work with at least version 2. There are licenses which I would not willingly work on, such as the Afferro Public Licnese, however.
There are a lot of people in the open source world who want work done for free. Myself included. It is, for better or worse, a part of the culture of open source.
However, there is always a tension between regulating the scarce resource that is developer time and doing things for money. This is an inherent tension.
Probably 95% or more of the code I do is released under the GPL because although it is imperfect, it is the best tool we have:-).
The major concerns I have involve: 1) An unwillingness of the FSF to approach license compatibility issues as anything other than political (look at the willingness to grant a linking exception wrt the Afferro Public License, but not the old-style BSD license, for example).
2) The unwillingness of the FSF to include an ability to have some system for jurisdiction control in the license, meaning that there is no way to pin down what, for example, constitutes derivation in any case.
3) The GPL v3 process left a bad taste in my mouth because the anti-Tivoization and APL-compatibility clauses were initially incompatible with 2 of the 4 basic freedoms so ideals were sacrificed for the sake of expediency. Although the worst of these clauses was removed (the optional terms for source distribution over any network section), these were *not* done for the right reasons (that they are fundamentally incompatible with the FSF's very definition of Free Software in that it restricts both use and modification of the software) but rather because of concerns over "complexity."
Yes, I use the GPL for most software I work with, but it would be *really* nice to see:
1) Linking exceptions to other standard open source licenses such as the old-style BSD license built into the license.
2) A clause that states that any dispute under the contract shall be judged in the juridiction of the person accused of infringing on copyrights or breaching the terms of the license. That way, you could actually ask a lawyer what the license means and get a reasonably trustworthy reply. Right now, to be safe, you have to interpret such terms as "derivative work" as broadly as possible. But you probably cannot enforce such a broad interpretation against those you accuse of violating the terms of the license.
3) A clear statement as to certain sorts of uses deemed to be non-derivative. For example, because libpq may or may not link to OpenSSL (old-style BSD license), it would be nice to state that optional dependencies do not constitute transitive derivation if they are not required by the other program (I am not sure that they ever constitute transitive derivation, but YMMV, and IANAL). Hence it would be nice to know (for the sake of educating Debian) that GPL apps may link to Libpq (new-style BSD) even though libpq may or may not link to libraries with other incompatible licenses.
In short my concerns over the GPL are: 1) In the GPL v3, political expediency took precedence over the very definition of Free Software. People wanted to sacrifice freedom in a way that would make the Bush Administration proud. (Note the optional restrictions which were dropped because "they made the license too complex" isntead of the fact that they seriously abridged freedoms 1 and 3 in the FSF's definition of Free Software.)
2) The GPL is restrictive but, perhapse deliberately, vauge about the exact nature of those restrictions.
3) THe GPL thus provides a huge "gray area" where no legal interpretation is possible.
At the same time, it is the best license we have for multi-vendor projects where there are concerns about BSD-type traps.
BSD-type licenses have their own problems though... For example, why would you contribute code to a BSD project if your competitors would make it their free lunch (unless it is a reference implementation and that is the whole point)? This does become an issue in cases like PostgreSQL where the BSD license may delay certain contributions from coming back to the community (i.e. if it is not accepted as part of the core distribution, then all you do is give it to your competitors-- it is harder decision to contribute).
> How many people know that if they buy a copy of some closed-source MySQL-based bulletin board software, > that they are required to then go purchase a license from MySQL AB in order to *use* the software? [emphasis added]
They don't need to buy a license to use it. The license you can buy only gives you a permission to use MySQL with non-free software. If you are going to use only free software, then you don't need to buy the license. To again GPL provides freedom. Don't mix GPL with the non-GPL license MySQL is selling for those who don't want freedom. Um... That is what I said, right? The point is that most people don't know that if you buy some closed-source PHP-based bulletin board software on MySQL, that you *also* have to buy a license from MySQL. They use the GPL to extort money for license fees instead of using the LGPL for client libraries.
Having worked at Microsoft PSS, I will tell you that if a customer got angry enough and threatened to sue, we sent them over to people who sent them lots of free stuff.
I am not aware of anyone even trying to sue Microsoft. Hmmm... sue and probably lose, or drop the suit and get free stuff?
Note that this applied to threats both over quality of software and quality of support.
First, "going after someone for shoddy software" doesn't necessarily mean "suing them." One case in point: LedgerSMB forked from a shoddy program. Our codebase is under total rewrite because the code is so bad as to be impossible to maintain, and the security in the original program was non-existant (using logins as session keys?!? Using timestamps for session validation-- validation meaning "this timestamp corresponds to a time in the last hour?????").
In this case "going after the author" meant "submitting lots of stuff to Bugtraq after fair warning was given" and using similar measures. These tactics proved somewhat effective. He actually began fixing "some" of the security issues (only those that didn't require a valid login to exploit, however-- he does not consider embezzlement to be a security problem according to his previous emails). One of our messages early on has been "unlike SQL-Ledger, we take security against embezzlement very seriously."
More stuff is going to Bugtraq after our next release too. He has had a few months to fix the problems and the only responses we get no are "go away."
Secondly, I would add that the question over whether the software is the real deal has to do with ownership of... trademarks. Yes, the project should control its trademarks, and not accept code contributions from everyone without review. However a commitment to the principles of freedom and inclusive community are what are required.
However, I would agree that first, second, or third parties can provide support and guarantees. This may be the copyright holder, the internal IT department, or a third-party vendor.
Actually, I see the GPL as potentially problematic, and inadequate in some areas, but it is the best license we have for certain kinds of projects. It is also the license I use the most because most of my projects are unlikely to be the sort of "reference implementations" that the BSD license is better suited for.
However, because I do most of my work with the GPL, I will have to say that it does have problems and I hope that over time those problems are corrected.
What can you not do under the GPL? 1) CHoosing your own license for your own code. 2) linking to OpenSSH or other old-style BSD-licensed projects, or works like PHP or SugarCRM which are licensed under other incompatible FOSS licenses.* 3) Gain greater legal clarity by adding a jursdiction clause.
* IANAL. Limitations according to the FSF. However, definitions such as "derivative work" and "work as a whole" may vary according to jurisdiction, but you may have no control over where a case is actually tried. Therefore I suspect that most lawyers will advise that one interpret these as broadly as possible when deciding what can be enforced against you but as narrowly as possible in determining what to enforce.
Don't get me wrong-- most of my contributions are under the GPL. THis is why I am aware of limitations and shortcomings of the license. It may be a decent license which meets most peoples needs relatively well, but there are a lot of restrictions that I consider to be somewhat burdensome (for example compatibility with other FOSS licenses). These restrictions are real and to pretend that they are not is just... silly.
The issue with the GPL is that people can get away with what look like violations to the rest of us because we all have to interpret the license as broadly as possible to avoid different jurisdictional issues, while someone could take a more narrow interpretation if they review appropriate jurisdictions carefully. Thus those of us who do larger-scale projects are held hostage to a higher standard than those who use our code.
Every license has traps. Despite the above points, most of my work is released under the GPL because, though it has many problems, it is still the best we have for many kinds of projects.
The Qmail license is more restrictive and fits the OSI definition of OSS (barely). It does *not* meet the definition of Free Software however, nor does DJB characterize Qmail as "open source." so this example is slightly debatable.
I consider the Afferro Public License to be more restrictive. Thank goodness adding those terms to the GPL v3 didn't happen:-)
THis being said, the GPL is still one of the most restrictive OS licenses. Whether or not those restrictions are right for your project depends on what you want to accomplish:-)
The scarce resource is developer and engineering manpower, not the software itself. License-models use the licenses as a way of distributing access to that scarcity. However it is not the only possibility.
One option (that I do) is to charge customers for access to the actual scarcity-- my time! Want x feature? Pay me $y.
The tragedy of commons does apply to free software however in a limited way. People like to make feature requests, and not everyone wants to pay to make those things happen. If we treat our time as a common resource, we never get paid. So paid features are implemented before those requests which are not associated with financial incentive.
This argument is silly. However, there is a valid point that the GP makes that is hidden in the rhetoric.
If I want to make a truly FOSS-based server product, I would either stick to open standards for access or I would release the client libraries under a suitably free license (LGPL or BSD). Some companies, such as MySQL AB, however, like to twist this around to sell *proprietary* software licenses to those who don't run 100% FOSS software. And MySQL AB at various times in the past has had odd ideas about what constitutes derivation (MySQL-only applications connecting via ODBC were considered to be derivative, but multi-RDBMS ones were not). Only when they got a *lot* of flack and PHP threatened to drop support for them did they add the linking exceptions.
How many people know that if they buy a copy of some closed-source MySQL-based bulletin board software, that they are required to then go purchase a license from MySQL AB in order to *use* the software?
Personally, I think that the GPL is a good choice for self-contained programs, and the LGPL should be the preferred option for libraries and connectors to other programs.
The GPL has a few other annoyances that I don't like:
1) No clear definition of areas which are clearly non-derivative. For example, if a Radius plugin links to FreeRadius and libpq, then is it a derivative work of OpenSSL (whose old-style BSD license is incompatible with the GPL) even though it is possible though unlikely that the individual has not built libpq without linking to that library? Is it illegal to install the radius plugin if you have this linking in place? The "let the court decide what is derivative" is a problem in the GPL in my view, but IANAL.
2) No possibility of a jurisdictional clause (I would like to see a clause that specifies the jurisdiction of the code author alleging infringement) meaning that nobody has any clear rules since these things vary from one jurisdiction to the next.
The GPL is both restrictive and overly vague. But it is the best tool for the job in many open source projects. Just because it is the best shouldn't mean that we should overlook its substantial shortcomings.
First, I think that all FOSS licenses will keep us free (GPL, BSD, MIT, Apache, etc). In fact, I have made contributions to BSD-licensed software and GPL-licensed software. It doesn't matter to me what license is used provided that it doesn't contain onerous restrictions (I have no plans to do anything under the Affero Public License, for example because it is too EULA-like and I am *very glad* that the FSF saw the light and only gave a linking exception to that license rather than allowing for the worst terms of the license to be included as optional terms for the GPL v3).
Secondly, many of us contribute to FOSS because it makes business sense to do so. Simply saying "we believe in it so we can keep it going agaisnt the world" in some ways devalues the real economic and business reasons and hence shortchanges the community on an opportunity for recruitment.
FOSS is good for business. Freedom is an economic good (and more freedom may or may not be better-- there are valid business reasons for choosing either the GPL or BSD license over the other depending on what you are trying to do). THe main reason for choosing the GPL is that you may not want your competitors to take your code and run with it. The main reason for choosing the BSD license is that you may want to help foster competition in an industry that is complimentary to your products or services.
First, I generally only buy Linux-friendly hardware because most of my stuff runs Linux. There are exceptions where required (the Symbol MC50 is really nice for taking inventory in a retail business but I *hate* Windows Mobile sucks, and that is being polite) but I figure I should point out that although TFA suggests that this is the socially responsible path, I do this just because it is easier.
I dont have time to reverse engineer hardware and write drivers. Bravo to those that do!
I don't have the expertise to reverse engineer hardware and write drivers. Bravo to those that do!
If someone wants to go out and buy non-Linux-friendly hardware for whatever reason, go for it. I won't hold it against anyone. However, if you seriously want to run Linux, you will find that this is usually a waste of time and money.
I can't recall if I've seen this around but: if nobody "owns" software, is it subject to tragedy of the commons?
Nobody owns the software as a whole. Lots of pieces are owned by lots of people with agreements between them. Think of owning a city lot where a portion of the lot is owned by you but is public right-of-way (i.e. the city is legally allowed to come and build a road or sidewalk on part of it if they want without further compensation to you).
There are probably arguments either way, but because software isn't a scarce commodity I don't know how that old idea applies.
No, but developer effort is a scarce commodity. Business models, whether open or closed source which develop software for the public use generally have to have a way to make back the costs of the use of that scarce commodity. Software license fees are one way. Charging customers for development they need is another.
Effective competition against software license models can only happen with the understanding of the real economic bottleneck-- software developers and engineers.
I would suspect that as long as there are enough people willing and able to create new software and / or modify what's out there the issues would be minimized. The big problem I see with no "owners" of software is that ensuring you had "the real deal" would be difficult, because there's nobody to go after for "shoddy" software. Essentially, without an owner there is no responsibility. This could be detrimental, because it would mean that every organization that wants to use software would then have to hire competent software folks to evaluate and analyze the software, or make it all proprietary in the first place.
Don't confuse code with trademark. Linus owns the Linux trademark. It is only Linux if Linus says so. He does not own all the code in the project, however.
PostgreSQL has taken a similar approach. As has LedgerSMB, but in both these cases, there is a core committee who retains ownership of the trademarks for QA purposes.
Sure the local crowd here on/. is capable of evaluating most small projects, but in an environment that really relies on software as a tool, you can't "guess" that it will do what you want, and having the luxury (yes it's a luxury) of a software "owner" on which to place responsibility is probably a good thing.
What exactly needs to be owned? The project as a whole needs to be managed by a small group of people at most. The trademark needs to be owned and managed. But this does *not* correspond with a need for ownership of the source code.
"The software" is a pretty vague term in the open source world. As is "ownership."
Having software so "open" that responsibility cannot be assigned is actually a bad thing.
Now, the balance between those two concepts - responsibility and freedom - is a tricky one to be sure. At the very least, I agree that software should be "open" in the sense that you should be able to change what you have locally to do whatever you want; responsibility only comes in when you distribute those changes to others (or the use of modified bits can affect others).
Not really. Most community-driven (rather than company-driven, such as MySQL) projects end up eventually with three levels of community:
1) Core team (sometimes called a Steering Committee or Project Management Team), most of which have commit rights, and all are involved in managing the project.
2) Committers who have earned the right to commit based on past performance. Their rights are granted and managed by the core team.
3) Other community members including both users and developers. Any contributions from them have to go through committers.
The key to making this work is the commitment to community and transparency of process. Sure, just anyone can't go commit to svn-- only those who have proven themselves.
Any reason why contact lenses can't block certain wavelengths of light?
Actually I can think of one in this specific case: mechanism.
To block the light, it would either need to reflect that frequency, absorbe it, or flouresce.
Not sure if reflection is an option.
Absorbtion would heat up the contact and possibly damage your eye.
Flourescence could be cool though depending on the wavelength, it could either interfere with your vision or damage your eye. OTOH, flourescence into the visual range would at least let you know someone was trying to blind you;-)
This doesn't meant that you couldn't block some wavelengths. It just means that you couldn't block them at this sort of power without causing problems as the energy has to go somewhere.
While I think that the GP engages in some stereotyping, I think there is a valid point hidden inside.
The basic question that I get from a *lot* of business types is:
"if this is so great, why do people give it away for free?" This is actually an easy question to answer, but you have to start with the economic model of many open source businesses and actually discuss why people contribute. In other words it isn't free love hippie communes, but rather a valid approach to doing business in a somewhat complex industry.
In short, these people think about business in terms of an ability to monetize assets and efforts. They see giving away the software as being contrary to that when in reality, it is actually a very rational business decision to make.
Economic model: Do you absorb the costs and hope to make them back later on license fees? Or do you start charging people *now* for the work you are doing? How do you deal with the economy of scale when facing the likes of Microsoft who can *always* undersell you while still making a profit?
Why people contribute:
1) Maybe they need the improvements themselves and don't want to be stuck with the maintenance work across versions. Note that the solid majority of software is written for in-house applications so this allows for a lot of code to be shared and ongoing labor costs to go down:-)
2) Maybe they want some practice working on concepts in a peer reviewed environment to build marketable job skills. How is this different from an internship?
3) Maybe they want their name out there. Working on resume pieces, etc. Standard loss leader stuff.
4) Maybe they are charging customers for work the customers need and don't want to be stuck with all mainetance work themselves. This is simply creating value for customers while being able to do some advertising with a negative net cost:-)
But it all boils down to: Maintenance costs go down-- marketing exposure and potential for revenue go up. Why wouldn't you want to contribute?
The point is-- there are solid reasons to choose open source in a business, but it involves getting beyond the stereotype that all open source essentially amounts to people doing work without getting paid.
I think that it is time that we really move away from the "Linux costs less" mantra. In reality, Linux costs whatever you want to pay (the base stack usually is free of charge, but there are a lot of services, etc. that go with it and you can pay as much as you want here).
My experience (oddly born out in the Microsoft Get the Facts papers) is that people who go with Linux usually end up paying more once you factor in these services. However, the real reason is not that they find that the absolutely must, but rather that they find that they get greater benefits out of strategically investing in their infrastructure. Hence they can afford to profitably take on projects that would have been prohibitive under WIndows.
Windows is really the cheap option in most senses of the word (both in thers of quality and longer-term price). Linux can range from a DIY stack which is very powerful but takes a lot of invested labor from the company to a high-end optimized business solution which required a lot of effort by consultants etc.
Great, you finally brought up the really grotesque and injust point and I'm glad we got around to it before this thread closes. Obviously it needs to be stated as plainly as possible because there is a curious mix here of people who have a thorough knowledge of accounting and those who keep their money in a piggy bank. Personally I probably fall somewhere in between. I wouldn't call my knowledge thorough but I do maintain accounting software and hence get to discuss things with a lot of CPA's. And I have had to teach myself quite a bit on my own.
The ugly part here is in the amortization in the accounting sense and the concept of depreciation. Obviously the previous post doesn't need a lecture on the basics, but most people obviously do from a quick look at the off-the-wall posts below. Sadly, I'm short of time so let's just make it a real quick summary.
What makes capital expense golden and labor costs shit is the concept of depreciation. You cannot depreciate labor costs, but you can depreciate capital expenditures. This is the fundamental basis of corporate welfare. The state subsidizes businesses through tax refunds on capital expenditures.
Get it?
Of course there are other nefarious factors as well that drive the process even more such as the fact that by raising capital costs you can create barriers to entry and thus form the basis for the plutocratic system we use in the States today where the meaning of competition has been twisted to mean at least two brands used in marketing for each product category. I actually disagree with your characteristic of depreciation. The basic idea has nothing to do with taxes but rather the idea that one needs to try to track costs of obtaining revenue with that revenue. This is a basic accounting principle on which both the financial and tax disciplines are built.
Basically, labor may or may not be subject to amortization/depreciation depending on whether this is a one-time expense (like a capital asset purchase) which affects a substantial time frame. In this case, I would argue that it is proper to amortize the labor over the time that it is in effect.
Note that this principle cuts both ways, however. Just as you have to account for costs which are paid once but affect a substantial time frame, you also have to account for revenue that is collected once but refers to obligations over a time period. For example if you purchase a one-year support contract from my company on October 1, at the end of the year (assuming a year-end of Dec. 31), I have to adjust that revenue down by 3/4 (and essentially move that on to the next year).
In this view, the only way to account for project labor (as opposed to ongoing administrative and labor costs) would be to amortize it over a period of time (from a financial accounting perspective-- tax laws may vary...). This is the only way to be able to get good financial information regarding the real cost of revenue over any time covered in the project.
My preferred stack is Linux/Apache/Perl/PostgreSQL (though you can substitute Python or even PHP for Perl). To tell you the truth, it is better documented than MS's stack. It comes with awesome documentation and community assistance as well. Although it is geared towards a more advanced user than the MySQL docuemntation, the PostgreSQL docs are *great.* Perl is well documentated, and so is Linux and Apache.
Apache probably doesn't have as much documentation as IIS though this is probably because Apache itself has fewer things that can break without warning (like the metabase;-) ).
Not sure I agree. Note that most of this money goes to *on-going administrative expenses* wrt the shipping company. Jet fuel, maintenance, labor, and the like which are used up in the process of actually shipping the package.
Furthermore, from the shipper's perspective, it doesn't make a bit of differences to their finances whether that shipping expense is going towars the purchase of a new jumbo-jet or not. THey don't get to amortize that expense on their books.
Here is a better example to mull over. Support I buy a few raw materials and hire someone to manually produce goods for sale out of them. Does the labor I pay him go into an expense account immediately? No. It goes into an asset account (inventory). In essence the *total* cost to acquire an item for sale goes into the inventory account and only moves to an expense account when the item is either sold or converted for internal use and if it is a capital good (say, a large storage container) that labor cost initially becomes part of the capital asset value and then would be subject to normal depreciation processes as an asset (i.e. be moved into an expense account over a period of time). I see no reason why there is concern over treating larger computer network projects the same way.
In fact, I would argue that this is the right way to track consulting labor in projects because it better allows you to match your expenses with your revenue (and if you are not interested in such a correlation, you should just stick with cash-based accounting;-) ).
However, IANACPA, and I know of no FASB/IASB rules on this. It is just my reasoning based on my understanding of GAAP.
Slashdot Mirror
I actually think that Tivo is a proxy for the FSF's concerns over untrustworthy computing. The big issues I have are 1) no software license which doesn't start blacklisting technologies or intentions to support technologies can address this. Imagine, for example, that we create a hardware/vm system where the OS is not trusted and certain areas of memory are encrypted to prevent OS access. Imagine further that the encryption is handled via a hardware/firmware solution and that Linux talks to that hardware through a very simple driver. Hence the keys for the encryption are not handled by the OS. We can now let a GPL v3 hypothetical Linux run without compromosing the DRM because the hardware and user-mode components don't have to trust the kernel. 2) there are sound economic reasons to suggest that Tivo's approach is short-minded and that untrustworthy computing will probably not become the technology that the media companies want it to be anyway. Why go looking for solutions in search of imaginary problems? However, I am willing to forgive this as an honest mistake made in concern for the freedoms that the FSF expounds even given areas I feel are less-than-idealistic (see below).
The bigger issue in my mind, however, was the question of compatibility with the Afferro Public License which contains explicit restrictions about how the code can be altered such that you must provide access tothe source of the application over whatever network sessions the user connects to it. I see this as 1) very EULA-like and 2) very onerous. The original approach, allowing the GPL v3 to adopt these provisions as optional clauses would have eventually sought to drag every networked application into this mess and would have seriously curtailed the ability to modify an application for one's own use (part of Freedom 1) and distribute such modifications (part of freedom 3).
While the heavy-handed approach in the earlier drafts did not make it into the final draft, the problem I have has to do with the rationale document, which gave only one reason for the change: that it added complexity. There was *no* discussion or acknowledgement in the FSF's official rationale for the change regarding the question of software freedom. I am therefore left to conclude that the question of whether this was a legitimate abridgement of freedom was *never* an issue for the FSF.
Early drafts of the GPL v3 were non-free based on other criteria already established by the FSF including the fact that it put limits on what could be charged (see their concerns of the Reciprocal Public License). In short, I think that early drafts of the GPL v3 were clearly not Free Software licenses under the standards set forth by the FSF and I do not think that meeting those standards was a high priority.
With the GPL you cannot:
1) Write softare that uses OpenSSL in a way as to be a derivative work of that software despite the fact that OpenSSL is Free Software by the FSF's own definition (and they even classify the license as Free).
2) create software which is derivative of GPL v 2 (only) software and Apache License v2 software even though both are Free Software licenses by the FSF's terms.
3) Create software which is derivative both of GPL software (any version) and Mozilla Public License software even though both respect the 4 basic freedoms.
The GPL is the best tool we have to release software we want to do open source without having other companies proprietize it. But it does have other restrictions which go beyond the "you can't take other people's freedom."
I would like to see a list of linking exceptions built into the GPL. It would go a long way toward actually resticting the limitations to what you say.
Qmail is:
:-)
1) in line with the OSI definition of open source. In fact the OSI seems to have bent over backwards to include Qmail in that they specifically allow the distribution of a base package plus patches.
2) Not represented as open source by its maintainer.
This is what I said and I will stand by it. You have not yet contradicted me
Not necessarily. I am not entirely sure where the boundary between use and preparing derivative works may lie in regards to installing and configuring software, particularly if the config file is a script itself that is run. In essence as soon as you alter one line of PHP even if it is a config file, you may arguably be preparing a derivative work which may put you out of compliance.
:-)
Furthermore, not all jurisdictions internationally may see installation of software as necessarily fair use and hence the mere act of installing the software may or may not be permissible under the GPL depending on where you live (IANAL, but I believe that US law does treat installation of software and running of software as protected activities. Were they not, they would be covered under the GPL itself, and use is not defined in the GPL in such a way as would necessarily provide the right to install the software).
Finally, what is wrong with allowing people to choose licenses for other software that interoperates with your own software? Is the goal to coerve everyone to use GPL-compatible licenses? Or is it to build software which is truly Free? Are you *that* insecure about your position that you cannot tolerate other licenses? Why should the Afferro Public License get a linking exception but not the old-style BSD license?
Finally a note on the BSD license. The GPL and BSD licenses have different strengths and weaknesses. If you are launching a business product and do not want your competitors to take it and run, the GPL is a good license for that. My business uses it in the vast majority of our work. However, it is not the only way. PostgreSQL and Apache both have built very large and vibrant communities on the principle that people contribute back for various reasons and that such contributions should be freely given (and not coerced). Sure both projects have proprietary spinoffs, but in both cases, the core program undergoes such rapid development that no other company wants to get stuck with more maintenance work than necessary, so they contribute back everything they can (meaning everything that is not part of their differentiation strategy and that the community is interested in. An example of what is not contributed back to PostgreSQL is EnterpriseDB's Oracle Compat stuff that the PostgreSQL community rightly doesn't want anyway).
And releasing a reference implementation under the GPL would be silly and counterproductive (which both PostgreSQL and Apache started out as). The only issue with the BSD license is that software developers may be less inclined to share code in a community which has players which are likely to proprietize that code unless they can ensure very wide-spread distribution. Hence if I had a cool PostgreSQL add-in and the core team was not interested, I would have to think long and hard before giving EnterpriseDB and the like a competitive stick to beat me with (if it went core that would be another matter).
All software lives or dies on the basis of community. License choices are secondary to community management issues. And all software licenses suck
In fact software wins or loses in the competitive marketplace on the basis of community. The choice of BSD vs GPL makes some difference for many projects but neither one necessarily precludes success over competitors. In fact the superior development pace of Linux over *bsd has more to do with community management issues than licensing choices.
BTW, for all the things I say against the GPL, it is because I work with the license a lot and will continue to work with at least version 2. There are licenses which I would not willingly work on, such as the Afferro Public Licnese, however.
YMMV as all the jobs have since been moved to India ;-)
Sorry, I should have been clearer.
There are a lot of people in the open source world who want work done for free. Myself included. It is, for better or worse, a part of the culture of open source.
However, there is always a tension between regulating the scarce resource that is developer time and doing things for money. This is an inherent tension.
Probably 95% or more of the code I do is released under the GPL because although it is imperfect, it is the best tool we have :-).
The major concerns I have involve:
1) An unwillingness of the FSF to approach license compatibility issues as anything other than political (look at the willingness to grant a linking exception wrt the Afferro Public License, but not the old-style BSD license, for example).
2) The unwillingness of the FSF to include an ability to have some system for jurisdiction control in the license, meaning that there is no way to pin down what, for example, constitutes derivation in any case.
3) The GPL v3 process left a bad taste in my mouth because the anti-Tivoization and APL-compatibility clauses were initially incompatible with 2 of the 4 basic freedoms so ideals were sacrificed for the sake of expediency. Although the worst of these clauses was removed (the optional terms for source distribution over any network section), these were *not* done for the right reasons (that they are fundamentally incompatible with the FSF's very definition of Free Software in that it restricts both use and modification of the software) but rather because of concerns over "complexity."
Yes, I use the GPL for most software I work with, but it would be *really* nice to see:
1) Linking exceptions to other standard open source licenses such as the old-style BSD license built into the license.
2) A clause that states that any dispute under the contract shall be judged in the juridiction of the person accused of infringing on copyrights or breaching the terms of the license. That way, you could actually ask a lawyer what the license means and get a reasonably trustworthy reply. Right now, to be safe, you have to interpret such terms as "derivative work" as broadly as possible. But you probably cannot enforce such a broad interpretation against those you accuse of violating the terms of the license.
3) A clear statement as to certain sorts of uses deemed to be non-derivative. For example, because libpq may or may not link to OpenSSL (old-style BSD license), it would be nice to state that optional dependencies do not constitute transitive derivation if they are not required by the other program (I am not sure that they ever constitute transitive derivation, but YMMV, and IANAL). Hence it would be nice to know (for the sake of educating Debian) that GPL apps may link to Libpq (new-style BSD) even though libpq may or may not link to libraries with other incompatible licenses.
In short my concerns over the GPL are:
1) In the GPL v3, political expediency took precedence over the very definition of Free Software. People wanted to sacrifice freedom in a way that would make the Bush Administration proud. (Note the optional restrictions which were dropped because "they made the license too complex" isntead of the fact that they seriously abridged freedoms 1 and 3 in the FSF's definition of Free Software.)
2) The GPL is restrictive but, perhapse deliberately, vauge about the exact nature of those restrictions.
3) THe GPL thus provides a huge "gray area" where no legal interpretation is possible.
At the same time, it is the best license we have for multi-vendor projects where there are concerns about BSD-type traps.
BSD-type licenses have their own problems though... For example, why would you contribute code to a BSD project if your competitors would make it their free lunch (unless it is a reference implementation and that is the whole point)? This does become an issue in cases like PostgreSQL where the BSD license may delay certain contributions from coming back to the community (i.e. if it is not accepted as part of the core distribution, then all you do is give it to your competitors-- it is harder decision to contribute).
Quite frankly, all software licenses suck.
> that they are required to then go purchase a license from MySQL AB in order to *use* the software? [emphasis added]
They don't need to buy a license to use it. The license you can buy only gives you a permission to use MySQL with non-free software. If you are going to use only free software, then you don't need to buy the license. To again GPL provides freedom. Don't mix GPL with the non-GPL license MySQL is selling for those who don't want freedom. Um... That is what I said, right? The point is that most people don't know that if you buy some closed-source PHP-based bulletin board software on MySQL, that you *also* have to buy a license from MySQL. They use the GPL to extort money for license fees instead of using the LGPL for client libraries.
Having worked at Microsoft PSS, I will tell you that if a customer got angry enough and threatened to sue, we sent them over to people who sent them lots of free stuff.
I am not aware of anyone even trying to sue Microsoft. Hmmm... sue and probably lose, or drop the suit and get free stuff?
Note that this applied to threats both over quality of software and quality of support.
Just a couple of nitpicks ;-)
... trademarks. Yes, the project should control its trademarks, and not accept code contributions from everyone without review. However a commitment to the principles of freedom and inclusive community are what are required.
First, "going after someone for shoddy software" doesn't necessarily mean "suing them." One case in point: LedgerSMB forked from a shoddy program. Our codebase is under total rewrite because the code is so bad as to be impossible to maintain, and the security in the original program was non-existant (using logins as session keys?!? Using timestamps for session validation-- validation meaning "this timestamp corresponds to a time in the last hour?????").
In this case "going after the author" meant "submitting lots of stuff to Bugtraq after fair warning was given" and using similar measures. These tactics proved somewhat effective. He actually began fixing "some" of the security issues (only those that didn't require a valid login to exploit, however-- he does not consider embezzlement to be a security problem according to his previous emails). One of our messages early on has been "unlike SQL-Ledger, we take security against embezzlement very seriously."
More stuff is going to Bugtraq after our next release too. He has had a few months to fix the problems and the only responses we get no are "go away."
Secondly, I would add that the question over whether the software is the real deal has to do with ownership of
However, I would agree that first, second, or third parties can provide support and guarantees. This may be the copyright holder, the internal IT department, or a third-party vendor.
Actually, I see the GPL as potentially problematic, and inadequate in some areas, but it is the best license we have for certain kinds of projects. It is also the license I use the most because most of my projects are unlikely to be the sort of "reference implementations" that the BSD license is better suited for.
However, because I do most of my work with the GPL, I will have to say that it does have problems and I hope that over time those problems are corrected.
What can you not do under the GPL?
1) CHoosing your own license for your own code.
2) linking to OpenSSH or other old-style BSD-licensed projects, or works like PHP or SugarCRM which are licensed under other incompatible FOSS licenses.*
3) Gain greater legal clarity by adding a jursdiction clause.
* IANAL. Limitations according to the FSF. However, definitions such as "derivative work" and "work as a whole" may vary according to jurisdiction, but you may have no control over where a case is actually tried. Therefore I suspect that most lawyers will advise that one interpret these as broadly as possible when deciding what can be enforced against you but as narrowly as possible in determining what to enforce.
Don't get me wrong-- most of my contributions are under the GPL. THis is why I am aware of limitations and shortcomings of the license. It may be a decent license which meets most peoples needs relatively well, but there are a lot of restrictions that I consider to be somewhat burdensome (for example compatibility with other FOSS licenses). These restrictions are real and to pretend that they are not is just... silly.
The issue with the GPL is that people can get away with what look like violations to the rest of us because we all have to interpret the license as broadly as possible to avoid different jurisdictional issues, while someone could take a more narrow interpretation if they review appropriate jurisdictions carefully. Thus those of us who do larger-scale projects are held hostage to a higher standard than those who use our code.
Every license has traps. Despite the above points, most of my work is released under the GPL because, though it has many problems, it is still the best we have for many kinds of projects.
The Qmail license is more restrictive and fits the OSI definition of OSS (barely). It does *not* meet the definition of Free Software however, nor does DJB characterize Qmail as "open source." so this example is slightly debatable.
:-)
:-)
I consider the Afferro Public License to be more restrictive. Thank goodness adding those terms to the GPL v3 didn't happen
THis being said, the GPL is still one of the most restrictive OS licenses. Whether or not those restrictions are right for your project depends on what you want to accomplish
The scarce resource is developer and engineering manpower, not the software itself. License-models use the licenses as a way of distributing access to that scarcity. However it is not the only possibility.
One option (that I do) is to charge customers for access to the actual scarcity-- my time! Want x feature? Pay me $y.
The tragedy of commons does apply to free software however in a limited way. People like to make feature requests, and not everyone wants to pay to make those things happen. If we treat our time as a common resource, we never get paid. So paid features are implemented before those requests which are not associated with financial incentive.
This argument is silly. However, there is a valid point that the GP makes that is hidden in the rhetoric.
If I want to make a truly FOSS-based server product, I would either stick to open standards for access or I would release the client libraries under a suitably free license (LGPL or BSD). Some companies, such as MySQL AB, however, like to twist this around to sell *proprietary* software licenses to those who don't run 100% FOSS software. And MySQL AB at various times in the past has had odd ideas about what constitutes derivation (MySQL-only applications connecting via ODBC were considered to be derivative, but multi-RDBMS ones were not). Only when they got a *lot* of flack and PHP threatened to drop support for them did they add the linking exceptions.
How many people know that if they buy a copy of some closed-source MySQL-based bulletin board software, that they are required to then go purchase a license from MySQL AB in order to *use* the software?
Personally, I think that the GPL is a good choice for self-contained programs, and the LGPL should be the preferred option for libraries and connectors to other programs.
The GPL has a few other annoyances that I don't like:
1) No clear definition of areas which are clearly non-derivative. For example, if a Radius plugin links to FreeRadius and libpq, then is it a derivative work of OpenSSL (whose old-style BSD license is incompatible with the GPL) even though it is possible though unlikely that the individual has not built libpq without linking to that library? Is it illegal to install the radius plugin if you have this linking in place? The "let the court decide what is derivative" is a problem in the GPL in my view, but IANAL.
2) No possibility of a jurisdictional clause (I would like to see a clause that specifies the jurisdiction of the code author alleging infringement) meaning that nobody has any clear rules since these things vary from one jurisdiction to the next.
The GPL is both restrictive and overly vague. But it is the best tool for the job in many open source projects. Just because it is the best shouldn't mean that we should overlook its substantial shortcomings.
First, I think that all FOSS licenses will keep us free (GPL, BSD, MIT, Apache, etc). In fact, I have made contributions to BSD-licensed software and GPL-licensed software. It doesn't matter to me what license is used provided that it doesn't contain onerous restrictions (I have no plans to do anything under the Affero Public License, for example because it is too EULA-like and I am *very glad* that the FSF saw the light and only gave a linking exception to that license rather than allowing for the worst terms of the license to be included as optional terms for the GPL v3).
Secondly, many of us contribute to FOSS because it makes business sense to do so. Simply saying "we believe in it so we can keep it going agaisnt the world" in some ways devalues the real economic and business reasons and hence shortchanges the community on an opportunity for recruitment.
FOSS is good for business. Freedom is an economic good (and more freedom may or may not be better-- there are valid business reasons for choosing either the GPL or BSD license over the other depending on what you are trying to do). THe main reason for choosing the GPL is that you may not want your competitors to take your code and run with it. The main reason for choosing the BSD license is that you may want to help foster competition in an industry that is complimentary to your products or services.
First, I generally only buy Linux-friendly hardware because most of my stuff runs Linux. There are exceptions where required (the Symbol MC50 is really nice for taking inventory in a retail business but I *hate* Windows Mobile sucks, and that is being polite) but I figure I should point out that although TFA suggests that this is the socially responsible path, I do this just because it is easier.
I dont have time to reverse engineer hardware and write drivers. Bravo to those that do!
I don't have the expertise to reverse engineer hardware and write drivers. Bravo to those that do!
If someone wants to go out and buy non-Linux-friendly hardware for whatever reason, go for it. I won't hold it against anyone. However, if you seriously want to run Linux, you will find that this is usually a waste of time and money.
I can't recall if I've seen this around but: if nobody "owns" software, is it subject to tragedy of the commons?
Nobody owns the software as a whole. Lots of pieces are owned by lots of people with agreements between them. Think of owning a city lot where a portion of the lot is owned by you but is public right-of-way (i.e. the city is legally allowed to come and build a road or sidewalk on part of it if they want without further compensation to you).There are probably arguments either way, but because software isn't a scarce commodity I don't know how that old idea applies.
No, but developer effort is a scarce commodity. Business models, whether open or closed source which develop software for the public use generally have to have a way to make back the costs of the use of that scarce commodity. Software license fees are one way. Charging customers for development they need is another.Effective competition against software license models can only happen with the understanding of the real economic bottleneck-- software developers and engineers.
I would suspect that as long as there are enough people willing and able to create new software and / or modify what's out there the issues would be minimized. The big problem I see with no "owners" of software is that ensuring you had "the real deal" would be difficult, because there's nobody to go after for "shoddy" software. Essentially, without an owner there is no responsibility. This could be detrimental, because it would mean that every organization that wants to use software would then have to hire competent software folks to evaluate and analyze the software, or make it all proprietary in the first place.
Don't confuse code with trademark. Linus owns the Linux trademark. It is only Linux if Linus says so. He does not own all the code in the project, however.PostgreSQL has taken a similar approach. As has LedgerSMB, but in both these cases, there is a core committee who retains ownership of the trademarks for QA purposes.
Sure the local crowd here on /. is capable of evaluating most small projects, but in an environment that really relies on software as a tool, you can't "guess" that it will do what you want, and having the luxury (yes it's a luxury) of a software "owner" on which to place responsibility is probably a good thing.
What exactly needs to be owned? The project as a whole needs to be managed by a small group of people at most. The trademark needs to be owned and managed. But this does *not* correspond with a need for ownership of the source code."The software" is a pretty vague term in the open source world. As is "ownership."
Having software so "open" that responsibility cannot be assigned is actually a bad thing.
Now, the balance between those two concepts - responsibility and freedom - is a tricky one to be sure. At the very least, I agree that software should be "open" in the sense that you should be able to change what you have locally to do whatever you want; responsibility only comes in when you distribute those changes to others (or the use of modified bits can affect others).
Not really. Most community-driven (rather than company-driven, such as MySQL) projects end up eventually with three levels of community:1) Core team (sometimes called a Steering Committee or Project Management Team), most of which have commit rights, and all are involved in managing the project.
2) Committers who have earned the right to commit based on past performance. Their rights are granted and managed by the core team.
3) Other community members including both users and developers. Any contributions from them have to go through committers.
The key to making this work is the commitment to community and transparency of process. Sure, just anyone can't go commit to svn-- only those who have proven themselves.
Any reason why contact lenses can't block certain wavelengths of light?
;-)
Actually I can think of one in this specific case: mechanism.
To block the light, it would either need to reflect that frequency, absorbe it, or flouresce.
Not sure if reflection is an option.
Absorbtion would heat up the contact and possibly damage your eye.
Flourescence could be cool though depending on the wavelength, it could either interfere with your vision or damage your eye. OTOH, flourescence into the visual range would at least let you know someone was trying to blind you
This doesn't meant that you couldn't block some wavelengths. It just means that you couldn't block them at this sort of power without causing problems as the energy has to go somewhere.
While I think that the GP engages in some stereotyping, I think there is a valid point hidden inside.
:-)
:-)
The basic question that I get from a *lot* of business types is:
"if this is so great, why do people give it away for free?" This is actually an easy question to answer, but you have to start with the economic model of many open source businesses and actually discuss why people contribute. In other words it isn't free love hippie communes, but rather a valid approach to doing business in a somewhat complex industry.
In short, these people think about business in terms of an ability to monetize assets and efforts. They see giving away the software as being contrary to that when in reality, it is actually a very rational business decision to make.
Economic model: Do you absorb the costs and hope to make them back later on license fees? Or do you start charging people *now* for the work you are doing? How do you deal with the economy of scale when facing the likes of Microsoft who can *always* undersell you while still making a profit?
Why people contribute:
1) Maybe they need the improvements themselves and don't want to be stuck with the maintenance work across versions. Note that the solid majority of software is written for in-house applications so this allows for a lot of code to be shared and ongoing labor costs to go down
2) Maybe they want some practice working on concepts in a peer reviewed environment to build marketable job skills. How is this different from an internship?
3) Maybe they want their name out there. Working on resume pieces, etc. Standard loss leader stuff.
4) Maybe they are charging customers for work the customers need and don't want to be stuck with all mainetance work themselves. This is simply creating value for customers while being able to do some advertising with a negative net cost
But it all boils down to: Maintenance costs go down-- marketing exposure and potential for revenue go up. Why wouldn't you want to contribute?
The point is-- there are solid reasons to choose open source in a business, but it involves getting beyond the stereotype that all open source essentially amounts to people doing work without getting paid.
I think that it is time that we really move away from the "Linux costs less" mantra. In reality, Linux costs whatever you want to pay (the base stack usually is free of charge, but there are a lot of services, etc. that go with it and you can pay as much as you want here).
My experience (oddly born out in the Microsoft Get the Facts papers) is that people who go with Linux usually end up paying more once you factor in these services. However, the real reason is not that they find that the absolutely must, but rather that they find that they get greater benefits out of strategically investing in their infrastructure. Hence they can afford to profitably take on projects that would have been prohibitive under WIndows.
Windows is really the cheap option in most senses of the word (both in thers of quality and longer-term price). Linux can range from a DIY stack which is very powerful but takes a lot of invested labor from the company to a high-end optimized business solution which required a lot of effort by consultants etc.
The ugly part here is in the amortization in the accounting sense and the concept of depreciation. Obviously the previous post doesn't need a lecture on the basics, but most people obviously do from a quick look at the off-the-wall posts below. Sadly, I'm short of time so let's just make it a real quick summary.
What makes capital expense golden and labor costs shit is the concept of depreciation. You cannot depreciate labor costs, but you can depreciate capital expenditures. This is the fundamental basis of corporate welfare. The state subsidizes businesses through tax refunds on capital expenditures.
Get it?
Of course there are other nefarious factors as well that drive the process even more such as the fact that by raising capital costs you can create barriers to entry and thus form the basis for the plutocratic system we use in the States today where the meaning of competition has been twisted to mean at least two brands used in marketing for each product category. I actually disagree with your characteristic of depreciation. The basic idea has nothing to do with taxes but rather the idea that one needs to try to track costs of obtaining revenue with that revenue. This is a basic accounting principle on which both the financial and tax disciplines are built.
Basically, labor may or may not be subject to amortization/depreciation depending on whether this is a one-time expense (like a capital asset purchase) which affects a substantial time frame. In this case, I would argue that it is proper to amortize the labor over the time that it is in effect.
Note that this principle cuts both ways, however. Just as you have to account for costs which are paid once but affect a substantial time frame, you also have to account for revenue that is collected once but refers to obligations over a time period. For example if you purchase a one-year support contract from my company on October 1, at the end of the year (assuming a year-end of Dec. 31), I have to adjust that revenue down by 3/4 (and essentially move that on to the next year).
In this view, the only way to account for project labor (as opposed to ongoing administrative and labor costs) would be to amortize it over a period of time (from a financial accounting perspective-- tax laws may vary...). This is the only way to be able to get good financial information regarding the real cost of revenue over any time covered in the project.
My preferred stack is Linux/Apache/Perl/PostgreSQL (though you can substitute Python or even PHP for Perl). To tell you the truth, it is better documented than MS's stack. It comes with awesome documentation and community assistance as well. Although it is geared towards a more advanced user than the MySQL docuemntation, the PostgreSQL docs are *great.* Perl is well documentated, and so is Linux and Apache.
;-) ).
Apache probably doesn't have as much documentation as IIS though this is probably because Apache itself has fewer things that can break without warning (like the metabase
Not sure I agree. Note that most of this money goes to *on-going administrative expenses* wrt the shipping company. Jet fuel, maintenance, labor, and the like which are used up in the process of actually shipping the package.
;-) ).
Furthermore, from the shipper's perspective, it doesn't make a bit of differences to their finances whether that shipping expense is going towars the purchase of a new jumbo-jet or not. THey don't get to amortize that expense on their books.
Here is a better example to mull over. Support I buy a few raw materials and hire someone to manually produce goods for sale out of them. Does the labor I pay him go into an expense account immediately? No. It goes into an asset account (inventory). In essence the *total* cost to acquire an item for sale goes into the inventory account and only moves to an expense account when the item is either sold or converted for internal use and if it is a capital good (say, a large storage container) that labor cost initially becomes part of the capital asset value and then would be subject to normal depreciation processes as an asset (i.e. be moved into an expense account over a period of time). I see no reason why there is concern over treating larger computer network projects the same way.
In fact, I would argue that this is the right way to track consulting labor in projects because it better allows you to match your expenses with your revenue (and if you are not interested in such a correlation, you should just stick with cash-based accounting
However, IANACPA, and I know of no FASB/IASB rules on this. It is just my reasoning based on my understanding of GAAP.