That's not his definition, it's the (English) legal one: "the taking away of property with the intent of permanently depriving the owner of its use". (Without the last part, it's larceny rather than theft).
Cite one FAST case which has resulted in someone being convicted of
*theft* (rather than e.g. copyright infringement).Copyright infringement is unlawful, sometimes criminal. But it isn't legally *theft*.
But WHY do you need a source code? I do my projects. To do that in the most efficient manner, I use tools and libraries developed by professionals. I pay for solutions; I don't have time to dig through the code and fix the problems of somebody else. The ideal code is the the code that compiles and works at once; the ideal support is when there is no need for support.
Amateurish crap lacking essential features.
VLV
The fundamental problem is that the so-called IT industry attracts enormous resources but creates no real value :-) And the world starts to realize that :)))
VLV
... snip ...
Yes you can so restrict it, IF YOU OWN IT. However the user can choose to use the GPL license and abide by its restrictions. If he wants a different combination he must negotiate WITH THE OWNER. GNU will not negotiate on items it owns.
No, they don't need to work to the same license. For example, I have put hashlib up under GPC licence. Anybody can use it under those terms. That means they have to release source code of anything using it. This may not be satisfactory to some commercial enterprises. They can avoid using hashlib, or can negotiate another license with me. I will allow them to retain their own source code if they provide me with compensation, probably in the form of money. I will not allow them to take control of hashlib. And, if I find they are using hashlib in contravention of the GPL license (or another negotiated license) I am free to sue them. Ownership is valuable, even of GPLd systems.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
I think the Thompson hack is not viable today. There are many compilers and systems around. While the hack will work as long as you can limit code revisions to a small set of software, today there are far too many varieties. How many C compilers do you have on your machine, and how many linkers?
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
[...]
My copies of 'gcc' come with a 'testsuite' folder. Okay, it's not validated against Perennial / Plum Hall, but since I have already found bugs in compilers claiming to be validated against those, I don't trust a P+P sticker in the glossy brochures more than the 'testsuite' folder of gcc. (I chose this example because we already had this here a while ago...)
I have heard and used the term "crippled trial version" long before I knew what "GNU" and "GPL" mean. Many DOS shareware programs had "crippled trial versions".
I haven't found the respective thread in my archive. If it involved "cracking" the dongle, I wouldn't call that a "solution"; I would call that a "workaround" at best. Plus, it can be illegal.
If that were true, it would forbid people from turning their hobbies into jobs. Which would be tragic, as employers normally prefer to employ people who like what they do. Electronics companies like to hire radio amateurs, because those know what HF is, and where the hot end of the soldering iron is. On the bottom line, I'm quite certain that people who code for fun are better at coding for profit, and my employer benefits from me having C++ knowledge (from my hobbyist compiler stuff) going far beyond that you learn in normal university courses.
Of course my employer has a "no competition" clause in our contract. As long as he pays me for developing embedded media players, I'm not permitted to develop embedded media players for anyone else. Plus, it has even been ruled in Germany that a "no competition for 6 months after you leave the company" clause in a contract is illegal unless they keep paying your salary, so I'd hope courts are "employee-friendly" in this case.
"Too obviously"? If we'd use the software on more seats than allowed, that would never be visible externally.
Dongles? If you ask me as a techie: they are the problem, not the solution. (I know accountants see the world the other way around.)
Stefan
... snip ...
No, that is your idea. I don't think that most Open Source writers are idiots. If you are so knowledgeable of GPL license ignorance I think you should report the details and evidence. The owners of that software could make some money. Your failure to so report indicates that you consider they don't deserve that chance.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
[...]
But I also don't have the time to wait for the vendor support to even acknowledge that there is a problem, not even speaking of fixing it.
Of course. But we know the world is not ideal. And I am feel much more comfortable when I at least have the chance to understand the problem (and maybe develop workarounds or get a feeling of the "dark corners" of the foreign code, to know where I have to watch out for twip-wires in the future) than when I have to sit there twiddling thumbs (and reading Usenet :-) waiting for the vendor support to fix my problem - or not.
Stefan
But you do have the time to dig through the source code and understand how it is organized, figure out how to build it, debug the code, learn where and how to make the fixes, and figure out how the product should be the properly tested?
It seems being too long on the Usenet can have an effect on the brain. I was trying to find the (nonexistent) sarcasm in your comment.
-- Pertti
What is this real value thing you speak of? Is it something to do with increased profits, or is it to do with getting more for your ever decreasing $? Is it something that reduces the costs of having kids? Or maybe reduces the price of entertainment?
Have fun without payment, before they make it illegal!!
cheers jacko
Do you have some hard data to back this up? My hunch is that a very large portion of commercial use of open source is covered by two cases:
1) use of gcc in product development, which does not impose any requirements to distribute anything, and 2) use of out of the box embedded Linux, with applications in userland, which also does not impose distribution requirements.There is also a large amount of open source software that uses MIT, BSD, etc. licences, which do not require distribution of modifications.
-- Pertti
Chris H wrote: > In message , David Brown > writes >> Chris H wrote: >>> In message , John Devereux >>> writes >>>> Chris H writes: >>>>
You sell software protected with dongles (and other protection schemes), and the people who buy the software do not see the dongles as a stopping point. Do you think that there is a small possibility that "the people you know" is perhaps a biased sampling?
Again, I haven't claimed that they are "universally detested". But the more intrusive the protection mechanism, the more they are disliked. And many people have had a bad experience (dead dongle, dead PC with node locked software, etc.) and thereafter will dislike them. Those that haven't had such a bad experience will often not think about it and therefore not care.
I really don't know where you have got this fantasy that the "majority" of users of GPL software misuse it in some way. You are certainly correct that license abusers are not going to be bothered by the terms of the license - be it an open source license or a closed source license.
One of the great benefits of open source software, especially in countries with - how shall I put it? - traditionally lax views regarding software licenses, is that it is far easier to obey the license. For software users, the GPL (and other FOSS licenses) give you the right to use the software as you want, for free. You can distribute the software, for free. You can modify the software as you want (such as for localisation), for free. The only thing you have to do is make the modified source code available (if you distribute it rather than keeping it to yourself), which is generally also virtually cost-free. It is extremely easy to obey the licenses, and the huge majority of users would not even know how to go about breaking the license if they tried (since most users can't program).
On the other hand, it *is* very easy to break the license terms for commercial closed source licenses - illegal copies of Windows abound, for example.
FAST is not the law, nor a legal definition - they are a pressure group with a strong interest in making people *think* that illegal copying is theft and a crime.
"Software theft" is when you pinch a boxed copy of some software from a shop, not when you make or use an unlawful copy.
No, they have not - software publishers (along with groups like FAST) have taken people to court and *sued* them for license and contract breaches. These are *civil* law suits, in which the complainant sues for damages and/or other punishments such as for restrictions on the rights to sell or distribute the software. This is very different from
*criminal* law, where the complainant is the state, and the defendant faces a jail sentence. Note that there have also been cases of people being prosecuted for the crime of profiteering from unlawful copies of software (i.e., selling unlicensed software) - again, the crime is not one of "software theft", and certainly not "software piracy".
No, most people who make unlawful copies don't care about such distinctions. To the extent that they use logic at all to justify what they do, it is simply a matter of "everyone else does it" or "we would never have paid for it anyway, so no one loses".
Making or using unlicensed copies of software is still illegal and unlawful - and still wrong - but it is not a crime in itself, and it is by no means "theft" or "piracy".
Fixing other people's code isn't *always* difficult. If the sort of code, and the language it is written in, is familiar to you, then it could be a quick and simple job to fix the code. I've done it with library code (open source and commercial library code with appropriate licenses), and I've done it with debugger code (open source).
Regarding testing - I've found bugs in commercial library code, and fixed them. The suppliers could barely be persuaded to acknowledge that there was a bug, and had no interest in fixing it - they wouldn't even give the usual "we'll fix that in the next version, due out in six months' time", despite the fact that I'd included the single-line fix that was needed. So I had the choice between using "official" "tested" "supported" library code with a known bug, or my own corrected version. Testing in commercial products is often not all it's cracked up to be (and this was no cheapo tool).
In this case, the issue was in commercial code with source code for the library that I could fix and use. This is why I stress that requirement
- if the source code is for reference only (and if you are obsessed with your supplier's testing, then the source code is for reference only despite the licensing), then it is useless except as documentation.
In another case I found a limitation in some open-source debugger code that affected my particular combination of host, target, and debugger hardware. It happened to be a combination the developers did not have. I was able to fix the code within a few hours, and the developers were happy to integrate the fix in future versions. Of course, not all open source code is equally accessible to fixing by the users. But you have a lot better chance if you have the source code, you have a suitable license, and you have an active mailing list (or support forum) where the developers and other users hang out.
There are bugs in all sorts of code - commercial and open source. Having the source code available to users in a manner that lets them find and fix bugs, and spread those fixes with the developers and other users, is one way of lessening the burden of such bugs. Spending a great deal of time and money on test suites is another way. The two are not mutually exclusive, nor are these the only way to reduce bugs, and nor are either open source or high price automatically an indication of quality.
You've got the right idea, but are mixed up on the details. There is no "GNU" entity - you are probably thinking of FSF - the Free Software Foundation. FSF own copyrights to many gnu projects, such as gcc and related tools. They make a specific point that any contributors to these projects must sign over the copyright on those contributions to the FSF, so that the FSF owns everything in the project. This makes it much easier to go to court, since there is only one owner (compare this to Linux - if kernel developers wanted to sue someone over GPL violations of Linux kernel code, they'd have much more complicated job since contributors each own copyright to their own code).
There are also groups like the Software Freedom Law Center that provide legal help and advice to people dealing with violations of FOSS licenses. And using a specific known FOSS license like the GPL can help you, since it will be familiar to lawyers, and since it has written by lawyers.
A variant of the Ken Thompson hack is that some commercial compilers have been known to spot patterns used in common benchmarks and specifically cheat with such code (this has also been known for closed-source graphics drivers). It is difficult to conceive the level of conspiracy you would need to get such code or backdoors into gcc or other open-source compilers, whereas closed-source vendors could do so easily (not that I'd imagine they would want such backdoors, even though cheating at benchmarks has been known).
In particular, a closed-source vendor who does not also release fully usable source code (at a price, and with restrictive licenses, obviously) could easily include "extra" code if they wanted. That's why Microsoft's "shared source" license is useless - if you suspect them of putting in a backdoor in windows, pay for access to the source code, and find no backdoor, you have proved nothing - you can't re-compile that code and compare it to the original binary, nor can you take the source, re-compile it, and use and distribute that instead of the official binary. And even some companies that *do* allow you to do such a re-compile yourself have NDA's in place preventing you from talking about the results - thus if you find something suspicious, you can't tell anyone.
i doubt if anyone would tell you if they are using your hashlib functions.
I prefer not having to.
But doing it is always better than sitting there and twiddling thumbs while other people battle their way through the support ("Have you rebooted it?", "Have you reinstalled it?", "I'm out of office, I'll reply by next Friday."). If you get the support answer earlier: fine, but you have at least learned something.
Stefan
On Sun, 12 Apr 2009 09:19:26 -0500, Vladimir Vassilevsky wrote:
You make some good and typical arguments about why you don't need it and I don't think anyone will argue with them, directly. Yes, it is very difficult to consider the idea of digging through complex software with an idea of modifying it for any reason. In many cases, it's prohibitive -- and more so if you are in a position where you must pay premium dollars to hire talent for that effort.
However, there are still _some_ reasons and I've experienced them. They aren't decisive reasons for everyone. The particular circumstances will dictate how much they apply. And, looking with
20/20 hindsight right now, I must say that I and others haven't had the insights at the time to know that some of these would later become important issues and I might have wished we had had such insights.(1) Having access to the source code is an insurance policy. Access here doesn't _have_ to mean "right now, access" -- it may just mean that the source code is placed in the hands of a disinterested 3rd party broker with specific instructions about when the source must be released (demise of the vendor, for example, might be one such criteria; so might be the sale of it or the "reverse takeover" of it as happened between Philips and FEI, etc.) But it permits a consumer company, if it otherwise decides the circumstances are sufficient to warrant it, to have yet another option to take.
I'll provide one example. It's not the only one. And if you are any good at creative thought, you will have sufficient imagination to come up with others to meet your own questions about this.
I've been involved, from earlier stages, in a product that was at the pinnacle of skill and technology in 1986. To achieve the necessary performance, the then-fastest/best c compiler was used (Lattice c) along with Intel's own assembler and build tools to apply all this for embedded use (the linker in Lattice was inadequate.) The talent involved in designing this tool was pre-eminent; probably one of the best physicists in the world on the topic and a very good group of others, besides. There was a lot of assembly code, driven solely by the need for achieving speed on the 1985's technology. Initially, it had been largely written in c, but significant parts had been forced into assembly. Other parts had to be in assembly to handle the unique memory layout and initialization of initialized c variables, and other reasons. This product was so advanced at the time that it is still being sold today for the same purpose, though recently some new competition has cut into its marketplace.
In the mid-1990's when Lattice was gone and Borland and Microsoft were now the better options, I was asked to consider the possibility of converting this very large, multi-module base of complex software into the new tool options. I spent some initial time examining the call interfaces, the amount of assembly code and how it interlinked with the c code, and unique issues related to libraries and other aspects and the decision was made NOT to go ahead. Instead, the old Lattice c compiler (which was luckily saved) was used. Almost 20 years later in
2004, I was involved in a near complete re-purposing of the existing base of software to use the older, but good, hardware to develop a second real-time process variable that it never produced before and that would be combined with the original process variable to greatly widen the application space. In fact, there were specific customers who were willing to pay significant amounts just to have a few such instruments available, so it was worth the effort.Once again, I faced using Lattice c or switching. But the schedule didn't allow any options for me. I had to use the existing base of software. I would have felt just a little more comfortable had I known that the source code was available, had I run into some corner case of the compiler... but well into my new development when it would be very hard to unwind and go back. I didn't encounter this problem, but I certainly thought about it because of another case, Microsoft.
Back in the earlier days, I'd been using Microsoft's c compiler for a client. It was version 5.0, memory serving. That version of Microsoft's c had a profound bug when compiling c routines using the __interrupt keyword -- it would simply lock up the computer during compilation. I reduced the example to just a few lines, demonstrated the lockup, and called Microsoft. This, in the middle of an active project where I suddenly found myself at a stand-still as I tried to add interrupt code written in c. Microsoft at first simply took down the information and positively refused to tell me when they would be able to confirm the problem. About a month later, they confirmed the problem with their compiler. When I spoke to them then, they refused to provide any information about when it would be fixed, or even _if_ it would be fixed. (They also wouldn't say when the next version might be coming out, so I couldn't even guess about when I might be able to find out on my own.)
I was 3 weeks into a project (money, to my client) and going out to buy another compiler tool would be a very expensive decision. So was, in fact, having to reorganize and rewrite the code to work around a bug in code generation on their tool. And their only comments were that "we may or may not fix it in the next release" and "no, we can't say when the next release might be coming out."
I had experience then, recent experience, in developing a small compiler for c. This particular problem was exactly the kind for which I'd likely be able to track down and fix, had I had access to the source code. And it would have been an option I might have considered at the time, had I had the source, taking control and getting going again. But I didn't have that option.
Taking that experience and thinking about using that Lattice c compiler for an important project reminded me about the value of having access. It doesn't mean I'd necessarily save time -- some problems with compilers may be very expensive to find and solve. But in some circumstances I can now imagine because of my own long experiences, it could be worthwhile. Not often.
But as I said, this can be an insurance policy for unusual cases.
(2) Having access to the source code can permit re-purposing of the compiler tool chain to new cross-compilation hosts or targets where the costs of retraining personnel are higher than the costs of the initial work involved and where the current maintainer of the toolset isn't interested in those areas, for whatever reason. A current example of this problem is illustrated in the JTAG debugging arena for ARM. The debug interface is well documented and hardware abounds. But the software to operate many of these inexpensive and readily available proprietary hardware tools is proprietary. And they many times don't provide a version to operate (or operate well) under Linux or other operating systems beyond Windows. It's just not important, for a variety of reasons probably in a unique mix of motivations for each vendor. If one is already committed to development platforms other than Windows, this can become an issue. Granted, there are some websites which help describe all the machinations to make this work in certain circumstances that may be of interest, not ever circumstance is covered. What is really nasty about all this is that without careful research beforehand (and it is easy to fall prey here), one might imagine they can just buy "that cheap dev board" that comes with this really nice "JTAG debugger tool" and be off and running with a GNU c compiler running on Linux.... when that may not be the case, without having to pay yet another (and hidden to view at the time) fee to buy a special debugger library -- or, even, to not have the option no matter what because the company simply doesn't make any software at all for that case. Having access, knowing a priori that you do, means you know that if something slips past your initial due diligence, that you at least have the promise of a remedy. It may not be easy, but at least it exists and you can choose to pay the price, if you want to.
...
I can imagine other reasons, too. I've a good imagination and long experience, though.
In no way does any of the above mean I think that having access to source code is important for every, most, or even very many projects. But it is a GOOD thing to have that option in the marketplace. For some, they will decide it is worth the other trade-offs. But that is a decision each of us is empowered to make, taking into account our own factors and weighing them as better we are able.
It is decidely NOT the case that no one has any possible, legitimate use for access to the source code. Lack of access is not a universal panacea for all and sundry.
It's good to have more options and I'm glad they are out there. That doesn't mean I choose them -- I rarely do -- but I like knowing that I can, if I feel it is an element worth having. And with better open source tools and libraries in some markets, the purchase price regarding other factors is lower than ever before.
Jon
What was the war about? I forgot.
Jon
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.