Software, by definition under U.S. law, falls under the category of mathematics and mathematics, again by law, are NOT patentable.
It is perfectly legal for software to be part of a *process* that may be patentable. But under U.S. law, the process cannot consist of software alone. In this matter, the USPTO (possibly under political pressure) has made a unilateral decision to ignore the law.
Most WIPO nations have followed the U.S. decision. There are a few nations that have amended their local IP laws to expressly permit "software invention", but as yet the U.S. is not one of them.
As far as I understand it, that's roughly correct. In particular, pure algorithm methods are classified as mathematics and unpatentable by law (in all countries, AFAIK). But the US Patent Office has happily accepted such patents for a long time.
I might be wrong here, so I don't want to sound /too/ definite. But I don't believe many other countries have allowed software patents. Like the USA, pure software patents are disallowed by law. But unlike the USA, other countries' patent offices follow that law. I have heard of a few cases of pure software patents having been granted in European countries (typically following a US patent), but in the great majority of cases, the US software patents are not valid outside of the US.
Patents on inventions that /use/ software are, of course, allowed and are valid (and are no worse for hindering innovation and progress than most other types of patents - i.e., great in theory, but worse than useless in practice).
That's interesting to know - I don't know any IP lawyers myself, and have not heard any personal opinions. Sometimes it is good for non-lawyers like myself to be reminded that lawyers (or at least some of them) are human too :-)
Switzerland comes closer than most - they hold regular public referendums on major issues rather than letting them be decided by the representatives.
I have always thought that the style of government used in the West could be called "representative democracy" (this can be applied to both republics like the USA and France, and kingdoms like the UK and Norway). A "representative democracy" is a sort of indirect democracy - you vote for people who will then vote on the issues.
But I freely admit that I am no student of political science, and my terminology may not be accurate. I simply used the term "democracy" as a rough term meaning that the population as a whole is supposed to be responsible for how the country is governed and what laws it passes.
Maybe I got it wrong about the "watch it once" clause, or perhaps it varies between countries. Either way, the principle is the same - if you have kept a copy for more than 30 days, you've committed a copyright violation.
I've been bitten in the past by poor 3rd-party code. (Like perhaps a lot of perfectionists, I'm convinced that my code is the most robust code I've ever come across. It's taken 30+ years of embedded programming experience to code the way I do, and one day I shall write the Art of Embedded Programming and share my brilliance ;).)
Looking "under the hood" of so-called commercial libraries, I'm terrified - the standard of coding from so-called expert houses is appalling. Fairly recently the head honcho of a certain well-known embedded RTOS supplier (whom I won't name) published his own personal coding guidelines. I'd not bought from them yet, but I certainly won't now.
OTOH, the percentage of code that I've re-used from previous code *of mine* is quite high. I've been tuning, optimising, and re-using my own cooperative multitasker for around 20 years. Just recently re-used (and extended) a GPS library I originally used back when the GPS constellation was yet incomplete...
Appalling or just difference of style, organization, and/or unfamilarity?
You never been bitten with problems in your code?
Code magically gets better just by studing it, it seems. Complexity can can only be reduced so much, and algorithms being coded are usually complex, so it's has to be studied to be appreciated. People tend to recode a rat's nest of code only to produce another rat's nest, but it's their familar rat's nest so it seems better. It's rare to meet a coder who doesn't says the "other guys code" is total crap, with the other guy returning like critique.:)
Ultimately, I believe we rewrite code because we can. We probably do the same with all the hardware too if we had fab shop in the basement.
The alternative is copyrights to protect software. The GNU GENERAL PUBLIC LICENSE
formatting link
has done a lot to promote copyright as a primary means of software protection. From an industrial point of view software patents are preferable to copyrights, they have shorter life and do put technology in the public domain at the end of their life. Copyrights have traditionally been harder to defend but FSF has given us many case precedents that can now be used.
... which, compared to the usual speed of developments in this field of work we're in, is actually effectively infinite. Just about _nothing_ in this industry lasts anywhere as long as patents.
That's the next problem with patenting software: for (pure) software work, that amount of resources is vanishingly small. The idea behing patents was to enable inventors to set up a production plant and produce the product themselves for a significant time (and thus, earnings) before anyone else gets a right to do the same thing for free. Getting software to market once you have it in a shape that could, conceivably, be worthy of a patent, costs essentially nothing in comparison.
But the biggest flaw in the patent system, as applied to software, is that it is applied completely unjustly: if your work is pure software, you can _not_ get a patent yourself, but you're still supposed to pay others for theirs. Around here the relevant wording in the patent law is almost uncharacteristically clear and concise: "Software as such is un-patentable". They forgot to add ", nor can software as such be required a licence to use a patented method".
Getting patents was always supposed to be a race among equals: the first to make it to the patent office with a valid application wins. Everybody else pays him. But it's utterly perverse to expect people who never even had a chance to participate in the race to participate in paying the prize.
Among the perversions this has created are physical devices created and patented for no other purpose but to smuggle a software patent into the system.
I would have agreed with you 20 years ago. Most of the frivolous patents were being filed about then. A surprisingly large amount of the current software actually is 20 or more years old. If for example GNU had been patented it would be in the public domain by now as it is it is protected by copyright and is years away from being in the public domain.
New ideas in software development are getting rare which is why real breakthroughs should be commercially protected.
Town Hall governments are common in new england. I think its more of a "down home" approach to things. Of course, some things required "real" votes -- bind issues, etc. But, "should the police department have funds to purchase new radios for their squad cars" was decided by a show of hands... (though I don't recall anyone checking residency on entrance to the meeting hall! :> )
I don''t want to start a war here ... there are other forums for debating the merits of GPL ... but the current v3 GPL contains quite a lot of disincentive for a business to use it. There are *more* open licenses such as BSD, MIT, etc. that can protect the author's rights without unduly limiting business practices.
GPL v1 & v2 were not too objectionable, but there has been a general backlash against GPL v3. It's largest failure to date has been Linus Torvald's categorical refusal to put Linux under v3.
IMO, a lot of people who have embraced GPL have done so in a reactionary way and haven't really understood the implications of the various versions. Solely from a legal standpoint, I don't see how any business could choose to include v3 GPL'd software in a saleable product. [Internal use of GPL'd software is a different issue].
If you want to encourage innovation, then don't put silly obstacles in the way that others have to waste time working around. (e.g., writing your own standard libraries just to get around GPLL).
If I mention open source to a client as a possible short-circuit for some portion of the project, the first thing out of their mouth is "We don't want to use Linux". *Period* (i.e., drop this line of discussion or we'll find someone else who'll meet our goals). They equate OSS with Linux and, thus, the GPL and rule everything out in one fell swoop.
The products that *do* include GPL'd software all seem to violate at least the *spirit* of the license. Few companies make it easy to get a hold of the sources that they are supposed to make available under the license. Some go belly-up -- or are bought out (and "magically" released from their license obligations?). Others comply only with the *letter* of the license. "Here's a CD with the source code on it. *You* figure out how to unpack it, set up the build environment, etc. We don't *support* it..."
If you *really* want to encourage your software to be used and improved upon, let people use it "unencumbered". Sure, you can protect *your* rights to keep using it as your own "property" (lest someone claim you are infringing *their* copyright) but there's no real point in forcing them to pass
*their* improvements on to others as a condition for using "your" software. They'll just reinvent what you've done (probably better -- since they can still EXAMINE yours) and lock it up under their own closed copyright/TS anyway!
If your ego is so fragile that you need to see your name
*somewhere* credited with the creation of "some part of this product", then put a clause to that effect in the license. Chances are, no one other than the developers will ever see it anyway! :-/
Forcing people to give away their IP is just as bad as letting them lock you out of using it!
The open town meeting is about as close to democracy as the US gets. But it is purely a local system and not all states embrace it.
I live next door in Massachusetts. In my town we have representative town meetings in which the general public cannot participate. Each town district elects one or more "town meeting members" who are purported to represent their district's interests. [There are also open meeting towns in MA ... just not where I live.]
Copyrights and patents have different strengths and weaknesses. It is correct that patents are theoretically short-term - but in most of the software world (embedded is a little slower), 20 years is for ever. If software patents were to be of any use without being the huge hinder they are today, they should last about 3 years.
Copyrights are too long - you can blame the USA and their Mickey Mouse laws here.
But patents are an attempt to gain control of an idea and a way of solving a problem - this makes them much wider than copyrights, which only cover a particular expression of an idea. So copyright is the best tool to protect a program - with copyrights and no patents, you can duplicate the workings of someone else's program as long as you write it yourself.
Software patents are only good from the viewpoint of a company which has got a large collection of patents and an army of lawyers to sue people. This is true regardless of whether the company is just a patent troll, or is a truly inventive and productive company that is just trying to protect itself from others. In my mind, that is not an "industrial point of view".
When I write code for my company, my company owns the copyright. That means other people can't take our code and use it without our express permission. If they want something that works the same way, and don't want to pay us for it, they can do the work themselves. We get this protection automatically for no cost, without having to pay lawyers or pay bureaucratic fees. We don't have to publish or reveal the code or anything else to get that protection. We do have to pay lawyers if we want to sue someone for breaking our copyright - but the infringer must pay us for those legal fees as well as any damages. From an "industrial point of view", it doesn't get any better than that.
The GPL definitely has its strong points and its weak points, and is suitable for some types of software but not others. The GPL v3 changes the balance slightly compared to the GPL v2.
As far as Linux goes, Linus Torvalds is very much a pragmatist. When publishing Linux, he felt the GPL v2 expressed what he wanted in a license, so he used it. Since the GPL v2 did the job, he explicitly limited Linux to the GPL v2 (standard GPL's allow the the code to be re-licensed under newer versions). Having made that decision early on, it was fixed. Linus is not in the position to change it now - that would require the permission of every contributor to Linux over the years (or the removal of their code). So when the question of putting Linux under the GPL v3 came up, he made it barely bothered discussing something that was clearly impossible (and that he didn't agree with anyway).
BSD and other open source licenses licences provide a different balance between the rights and freedoms of the code authors, other developers, and end users. If you think these are "more open" than the GPL, then you don't understand the GPL or the BSD - they are "differently open". In particular, they give more freedoms to other developers who want to incorporate the code with their own code - but reduce the rights and protection of the original author. Different balances for different purposes - it is important to have a range of licenses.
I too would prefer the GPL v2 license (as used by Linux) - but I can see benefits in the GPL v3 as well.
But I certainly agree that a lot of people have used the GPL without understanding it - it is very common to equate "open source" and "free software" with the GPL, and a lot of code is released under the GPL (no version specified) because "I want other people to be able to use my code as they wish". In particular, you can find plenty of example code and libraries for embedded systems under the GPL, even though the author is quite happy for you to use the code in your own systems with any other license.
I agree with this - the GPL is (normally) a poor choice of licence for a library. But it's a perfectly good choice for an end-user product (assuming you want to give out the source code, of course).
That's clearly a client who doesn't know what open source means, and I would be very careful about a client with such vigorous opinions about licensing that they don't understand. Make sure you have very clear and tight contracts before working with such people - they are likely to believe they have more rights to the work you do for them than they should have.
There is definitely a fair amount of that going on - there is the full spectrum of attitudes from keeping everything as secret as they can (legally or illegally) to being fully open and encouraging tinkering. The majority of embedded systems using GPL'ed software probably fall into the "we'll give you a CD of the source code if you ask us" category.
But is that the fault of the GPL, or of people who publish code under the GPL? Should the busybox author have released his code under the BSD to allow companies to modify it and use it, then keep the improvements secret from their users? Or is it the fault of the abusing companies who took this substantial code for free, and ignored the license? How would you feel if you had written the code and charged for licenses, and someone had then based their products around your code without paying you your dues? It is exactly the same thing.
Programmers are under no obligation to write code to a license that /you/ find easier to use for free in your money-making products!
It is certainly /nice/ when programmers use a license that lets you use their code without giving away your own code. I like the MPL-style licence, or the "GPL with exceptions" licenses such as used by FreeRTOS. I think that is a good compromise license in many cases, especially for software in embedded systems.
But whether you like it or not, a lot of software has a GPL licence. The terms are not that bad - they are much less restrictive than in many commercial licences (even when you exclude all mention of costs). If you don't like it, get your software from some other source - just as you would with any other software under any other licence. It's no different.
It is correct that new ideas in software development are getting rare - most of the ideas that were truly novel and inspired, and could arguably justify getting patents, were developed 20 years ago (actually, most of the important stuff was 30, 40 or more years ago).
However, the rate of filings for software patents keeps growing. The obvious conclusion is that a higher and higher percentage, and absolute number, are totally frivolous.
Microsoft (they are not alone, but they are a good example who are often in the news) used to try to take patents on every idea they had, or bought in, or "acquired" in some way. But they now have a new technique
- they are trying to look at what ideas are currently in use but haven't been patented, regardless of whose ideas they were, and take patents on them. They are also trying to get patents on things that might some day be of use to someone - regardless of whether the technique is useful or even possible.
That's only partially correct. The idea behind patents was that the inventor would not have to set up a production plant - existing manufacturers would do the production. That's why patents require public disclosure - so that other manufacturers could see the details of the invention, and build on it. The point of the patent was that the manufacturers would them have to pay a reasonable fee to the inventor. The idea was that the product could be mass produced and be of benefit to the public at large without having to wait for the inventor to set up production facilities himself.
That's an interesting viewpoint - I don't think I've heard it expressed like that before.
All of the above, sure. But (putting style etc aside) ultimately lack of robustness, and just plain old bugliness.
Sure. But these days they tend to be typos, rather than car crashes.
Ah, now there I disagree strongly. I write code to be clear and obviously correct (hint: state machines; table-driven code; no globals; OOP design ethics in C). I like to be able to understand my own code at the very least ;). (Today's c*ck-up was because I'm working on a multi-build family; lots of conditional compilation. Turned out that the reason a particular state machine wasn't getting maintained was because I'd told it not to with the current build... d'oh!)
There's certainly an art to decomposing complexity into a collection of simple things (I'm not entirely sure it's something one can teach, even). I guess for me it's a survival instinct thing: I need to be able to sleep nights, and have confidence that the high-value system we've just delivered to a certain branch of a national body isn't going to fall over because of me.
Let me give you a concrete example of poor 3rd-party code. I'm currently using a CPU from AVR (AVR32 family). These come with "code frameworks", which include "drivers" for on-chip systems and example code to use them. Now, I have plenty of respect for the silicon. But I'm convinced that the code framework was put together by a summer intern (or several) with little experience and some guidance, but no QA. I made the mistake of using some of these "drivers" - and they've bitten my ass over and over.
One quick fr'instance: there's some (complex) code to manage the MACB, which looks after Ethernet traffic. It signals to higher levels that a message has been received via a Boolean flag. The higher level, running asynchronously and at a non-controlled rate, would poll this flag, read the message, and clear the flag. We started seeing cases where it seemed that the receive mechanism was one message out of step. We realised this happened when 2 (or more) messages arrived (and were properly buffered) before the higher level had a chance to poll the Boolean flag. We were picking up one message, and clearing the flag... and losing the rest.
Changing the Boolean to a counter solved the problem.
If I'd written this from scratch, I would have, without thinking about it, used a counter, not a Boolean - it's fairly obvious that multiple messages can arrive between polls. But I made the mistake of trusting the 3rd-party code, because it came from AVR...
There are loads of other examples. (The AVR TWI/I2C code is just completely hopeless. Bugs all over, and needless gotos, fer crying out loud... wound up ditching the lot and bit-banging I2C.)
Did I say I trusted the silicon? Also ran into a hardware bug. The DMA contention system ("HMATRIX") plain doesn't work. Looks great on the datasheet, but simply doesn't work. Gah. (Fortunately Mike, may his name be blessed [he reads this ng] rescued me with some FPGA magic...)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.