[ I'm also crossposting this to the fsfeurope discussion list as many points are quite general to Free Software licensing. ]
On Tue, Aug 12, 2003 at 03:07:17PM +0200, Radim Blazek wrote as answer to a post On Monday 11 August 2003 09:11 by Jan-Oliver Wagner:
Here are some LGPL disadvantages: (by application I mean any application using LGPL library)
Naturally I consider the valid points as advantages, because the freedom of the software part under LGPL is protected.
- Staticaly linked application must be probably distributed also as source code.
They must not be distributed as source code.
The GNU LGPL wants to protect against that you get in the position that you cannot fix a bug in the Free Software code part that was included in the end product. If this protection would not be in place a vendor might use a bug or special behaviour in the library to do a extend and embrace tactic in that his product will only be compatible with his product.
So the LGPL requires that the end user must be able to exchange the LGPL part. The static part of the license is not relevant in many cases as using dynamic libraries has gotten increasingly easy in the last years. Object code before static linking would be enough for the cause; dynamical linking really makes it easy to fulfill that requirement just having the library.
http://www.fsf.org/copyleft/lesser.html If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it.
Yes, I say 'probably', because LGPL is not very clear, and I found on the Web two kinds of explanations for article 6. a), one states that object code is enough, the second that source code is required.
The GNU LGPL is legally very clear, but complicated in itself, because the legal coyright situation in the US is complicated.
The indention of that paragraph is made clear in other sections of the license. E.g. at the end of paragraph 6: For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it.
Some people obviously read "object code and/or source code" as "object code or source code", but it does not seem to be right.
It depends on what is necessary to reproduce the executable after an exchanged library part with the same interface. With a shared library or object code for static linking you do not need the source code. So for this situation "or" is correct.
Also "permit modification of the work for the customer's own use" imposes distribution of source code, but that would apply to dynamicaly linked application as well.
No, because the distributed work is the binary. So you can modify the binary, which was a more common thing to do and some (proprietary) licenses do not allow this (nor reverse enginerring).
Unfortunately, I cannot find any FAQ for LGPL.
Most questions are answered in the FAQ for the GNU GPL. Others are answered in the archives of mailinglists. If you have a question, which happens even of only because the legislative system changes around you, licensing@gnu.org is your friend. (It might take a while for them to answer.)
- The application cannot use any third party libraries or tools needed to build the application which are not standard part of OS and cannot be distributed with the application. For example library which can read proprietary data format, available for download on Web, but without permission to redistribute it. On Windows, compiler like "Visual C" is also such tool. This is of course valid regardless the application is proprietary or free!
You missinterpret the end of paragraph 6 and mix something up with option a) from the same paragraph.
If you don't have permission to distribute the third party library in executable form (tple), then you cannot distribute it anyway no matter what the GNU LGPL licenced part says. That is a drawback of the license of the tple.
On the other hand, if you have permission to distribute the tple, paragraph 6 only says that you must be able to also distribute the necessary tools to be able to reassemble the executable. All because of the intended goal to be able to exchange the LGPL part.
This tool usually is a linker or a dynamic loader. So you can of course use a proprietary tple not usuablly distributed with the operating system. E.g. there is no problem on windows if you use dlls because the loader comes with the operating systems or objects compiled by "Visual C" for static linking, because you can link them on windows with Free Software linkers like ld.
- "You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change." this does not block the use, but it is annoying and extra work.
If you use version control like CVS, you can easily produce this by a script. Also some editors and the diff application will make this quite easy. It is a minor hassle but a very sensible one that even helps the quality of the software. It is also protecting the freedom, because proprietary companies cannot slip nasty tricks or backdoors by the user as easily as without it.
If I look around, successful open source GIS projects don't use (L)GPL: GDAL/OGR: MIT/X License Mapserver: MapServer License (almost MIT/X) PROJ4: MIT/X License
It depends on how you define success. E.G. PostGIS, GRASS, GMT, GPSDrive, JTS, KFLog, Vis5d, Geotools, GnuGaMa, BBBike and R use GNU GPL; OSSIM, OpenEV, VRS and degree both also utilse the LGPL. All those can be called successful in their area or targetted use.
GDAL/OGR are format exchange libraries for which LGPL and X11 have a higher strategic value. PROJ4 also is a core library similiar like ogg/vorbis. Even the FSF found the X11 license to be of strategic advantage for ogg/vorbis.
Additionally the question is: Could e.g. Mapserver even be more successfull when it would use a different license? This can also be asked the other way round of course and makes up the difficult strategic question which license to use.
Finally, I've found no evidence at all that L(GPL) harms the practical aspects of software. It only protects the freedom - thus if you mean that the license harms your practice to derive proprietary products from Free Software then of course you are right.
The problem is that it complicates/disables the use of the LGPL library for both free and proprietary programs.
It also protects the freedom of the software part under LGPL and history shows that some companies will otherwise have no reason not to use the results and make money with proprietary software on the efforts of the Free Software community.
But in that case your anyway not interested in the ideas and values of Freedom and Free Software.
I am interested in free software when it is feasible and sensible.
The upcoming of GNU/Linux systems is credited to a huge part to the GNU project and the licensing efforts of Richard Stallman and the FSF. I've made some simple analysis about license and it seems that the GNU GPL still is the most important Free Software license. http://mail.fsfeurope.org/pipermail/discussion/2001-June/001167.html
I am not interested to force people to do what FSF considers to be the best.
If we do not defend our freedom it will slowly be taken away. As author of software you have the right to decide on its license. The Free Software community (which included much more than the FSF or the people of the GNU project) has been using copyleft for about 15 years now and it is a sensible and viable concept.
Regards, Bernhard
It depends on how you define success. E.G. PostGIS, GRASS, GMT, GPSDrive, JTS, KFLog, Vis5d, Geotools, GnuGaMa, BBBike and R use GNU GPL; OSSIM, OpenEV, VRS and degree both also utilse the LGPL. All those can be called successful in their area or targetted use.
just a quick correction both versions of geotools are released under the LGPL not the GPL.
Ian
On 12 Aug 2003 at 16:26, Bernhard Reiter wrote:
If we do not defend our freedom it will slowly be taken away. As author of software you have the right to decide on its license. The Free Software community (which included much more than the FSF or the people of the GNU project) has been using copyleft for about 15 years now and it is a sensible and viable concept.
What do we think about IBM's first legal test of the GPL in their case against SCO?
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
And you can just bet that all those cash-strapped technology ventures being consolidated in silicon valley right now (many of whom are doing far less ethical things than SCO, but it's just not reported widely) will be watching for any loopholes which may be opened by this case.
Cheers, Niall
On Tue, 2003-08-12 at 20:54, Niall Douglas wrote:
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
I guess in a way it might be interesting. But, I don't really think that the GPL is going to be examined much - I would guess the argument would be whether or not SCO's distribution of Linux under the GPL actually means anything.
Personally, I suspect it doesn't. I can't see how it would be fair otherwise. I'm trying to think of analogies, and the best I can think of is a video rental store selling traded second-hand computer games that were originally stolen from them rental some months before. Or something :/
Maybe someone can convince me otherwise, but I don't think the onus is on the distributor to audit source code before distribution. I can't see how it would benefit anyone for things to be that way. So, my personal feeling is that the GPL issue will be rendered moot. But, who knows?
Cheers,
Alex.
The part at issue in this case is article 7 of the GPL (see below). If, for any reason, you can't comply with the conditions of the license (which includes distributing as Free Software) then you are not allowed to distribute the software. So, the only way for SCO to distribute linux code legally under the GPL was authorising the use of their patents or any copyrighted code included in it.
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
A Ter, 2003-08-12 às 21:14, Alex Hudson escreveu:
On Tue, 2003-08-12 at 20:54, Niall Douglas wrote:
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
I guess in a way it might be interesting. But, I don't really think that the GPL is going to be examined much - I would guess the argument would be whether or not SCO's distribution of Linux under the GPL actually means anything.
Personally, I suspect it doesn't. I can't see how it would be fair otherwise. I'm trying to think of analogies, and the best I can think of is a video rental store selling traded second-hand computer games that were originally stolen from them rental some months before. Or something :/
Maybe someone can convince me otherwise, but I don't think the onus is on the distributor to audit source code before distribution. I can't see how it would benefit anyone for things to be that way. So, my personal feeling is that the GPL issue will be rendered moot. But, who knows?
Cheers,
Alex.
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
On Tue, 2003-08-12 at 21:37, João Miguel Neves wrote:
The part at issue in this case is article 7 of the GPL (see below).
No, I understand that. I just don't see that it applies.
Clearly, the GPL wouldn't allow SCO code to be distributed as a derived work. However, that doesn't nullify the case that SCO have that their code has been misappropriated. (And there is a separate argument that says SCO are still distributing Linux, and are therefore contravening the terms of the GPL in bad faith; I think that's a separate issue again).
People seem to be saying that section 7. is saying that since they distributed Linux (with their code) they were giving licence for people to use their code. I don't believe that could ever be the case. It does mean that the code was unlicensed for use, and cannot be distributed, but SCO cannot be made to turn their act into a legal one retroactively. They were breaking the licence unknowingly, I can't see how it can be argued otherwise.
Cheers,
Alex.
A Ter, 2003-08-12 às 21:48, Alex Hudson escreveu:
On Tue, 2003-08-12 at 21:37, João Miguel Neves wrote:
The part at issue in this case is article 7 of the GPL (see below).
No, I understand that. I just don't see that it applies.
People seem to be saying that section 7. is saying that since they distributed Linux (with their code) they were giving licence for people to use their code. I don't believe that could ever be the case. It does mean that the code was unlicensed for use, and cannot be distributed, but SCO cannot be made to turn their act into a legal one retroactively. They were breaking the licence unknowingly, I can't see how it can be argued otherwise.
They have been warned about the need to license the allegedly infringinf linux code before distributing (even through cease&desist letters) and they keep distributing it. They have the right to do it, as long as they license the alleged infringing code under the GPL.
On Tue, 2003-08-12 at 22:03, João Miguel Neves wrote:
They have been warned about the need to license the allegedly infringinf linux code before distributing (even through cease&desist letters) and they keep distributing it. They have the right to do it, as long as they license the alleged infringing code under the GPL.
Yes, but that assumes they are distributing legally. My point is that in all likelihood, they're not.
Of course they can get slapped down in court, have an injunction put on their distribution and sued for damages, but I don't think they can be forced to re-licence their code under the GPL - I'm sure that's not available as a remedy.
So, the consequence of them distributing Linux would be opening themselves up to legal action, but I don't think it has a bearing on their case against IBM for misappropriation.
It may be the case that they get into trouble for distributing Linux for other reasons - not adequately protecting the code say is misappropriated, for example. But at the end of the day I don't really think the GPL is going to come into it - unless they are found to have been the people who originally placed the code in question into the kernel, which seems highly unlikely.
Cheers,
Alex.
** Alex Hudson home@alexhudson.com [2003-08-12 21:50]:
On Tue, 2003-08-12 at 21:37, Jo?o Miguel Neves wrote:
The part at issue in this case is article 7 of the GPL (see below).
No, I understand that. I just don't see that it applies.
<snip>
People seem to be saying that section 7. is saying that since they distributed Linux (with their code) they were giving license for people to use their code. I don't believe that could ever be the case. It does mean that the code was unlicensed for use, and cannot be distributed, but SCO cannot be made to turn their act into a legal one retroactively. They were breaking the license unknowingly, I can't see how it can be argued otherwise.
** end quote [Alex Hudson]
Catching up on my mail, so a bit slow to reply here, but...
I'm no legal expert and I don't know how things differ in the US, but surely ignorance is no defense in the eyes of the law? If somebody, particularly a corporate entity, is in a position where there is a legal implication to an action (e.g. distributing software under a license) it should take steps to examine the implications of said action (e.g. if you are distributing software under a license you should be aware of the terms of the license and what it implies to the code you own).
In SCO/Caldera's case, they had a product that had a close relationship to the Linux code they were/are distributing. As such they should have examined to code to ensure they weren't 'giving away' anything they didn't want to, and if/since they didn't that is their own problem.
The main issue in this case is probably that Caldera was distribution Linux prior to owning the SCO code. Where this leaves them I have no idea. Logically I would say that on purchasing the SCO code they should have stopped distribution of their Linux distribution until they had examined the code - thus ensuring that during their ownership of the code they did not 'release it' under the GPL. Of course this would leave them as both the plaintive (as SCO/Caldera) and the defendant (as Caldera) to some respect, but nobody has said this is a straightforward case!
Just my 2 pence (or 2 cents) worth.
On Sun, 2003-08-24 at 11:51, Paul Tansom wrote:
Catching up on my mail, so a bit slow to reply here, but...
Tell me about it :o)
I'm no legal expert and I don't know how things differ in the US, but surely ignorance is no defense in the eyes of the law?
Well, ignorance is actually a defence. For example, if someone cons you into signing a document that is actually a contract for something, that signature doesn't really mean much and you are not considered bound by the contract.
The point I was making was that it seems to me to be different to redistribute software and to grant a copyright licence to your own software. The reason I think people argue the point is because with free software, you can see what is in it, and people think SCO should have been aware. I don't really think that matters though. They didn't give permission for people to distribute the code, so the fact they were effectively conned into distributing it shouldn't automatically GPL it.
I just think any other scenario would be unfair, in general, no matter what I might think about SCO themselves.
In SCO/Caldera's case, they had a product that had a close relationship to the Linux code they were/are distributing. As such they should have examined to code to ensure they weren't 'giving away' anything they didn't want to, and if/since they didn't that is their own problem.
I don't think so. The UnixWare/Linux groups were apparently very far apart (different continents). They purposefully kept the groups separate so that code couldn't 'migrate' from one to the other. On that basis, which of these groups was in a position to warn that Unix code was getting into Linux? Neither, in my opinion.
The only people I know who regularly audit their whole code base would be the BSD people, especially OpenBSD. As I understand it, the majority of that auditing is done mechanically. If you expect people to audit free software before redistribution, you effectively remove their freedom to redistribute, because it's an almost unsatisfiable burden. It would also be a burden that only free software would bear, since with proprietary software you cannot see what is inside it and therefore cannot audit it.
If SCO had redistributed their Unix code as free-as-in-beer proprietary closed-source software, what would happen in your scenario? Are they still liable, even though they cannot actually see the source code and verify it? Or, are they not liable? If they are not, then you're making proprietary software much, much easier to deal with. Free software would become even more distasteful.
Cheers,
Alex.
Alex Hudson wrote:
Well, ignorance is actually a defence. For example, if someone cons you into signing a document that is actually a contract for something, that signature doesn't really mean much and you are not considered bound by the contract.
This varies a *lot* from country to country, but a typical pattern is that ignorance is no excuse from criminal law, and in contract law it becomes fuzzy.
In criminal law however there is a great deal of emphasis placed on motive. Usually this is more important in the investigative stage and plea bargaining -- though sometimes during a trial a series of circumstantial evidence can be held together with a strong motive.
In contract law again, motive often plays an important role -- and this is very relevant for the GPL (again, depending on country, and I've not seen so many contract cases in the USA). When entering a contract both sides agree to a form of reasonable compensation (countries usually establish a series of tests to determine whether something is a valid contract, I'm only familiar with Canada in this regards).
In the case, for whatever reason, the contract is invalid, and a deal cannot be struck between the parties, an arbitrator or judge will try to make sense of the contract and assign terms and obligations on both parties -- that is, the judge will try to fix it. First by removing illegal clauses, then by resolving ambiguities, and then whatnot more...
In the case of distributing code dervied from a GPL licensed codebase (from party A) and them claiming your (party B) own code is not GPL, this removes the original parties compensation in the contract. When party B decides they made a serious mistake and effectively withdraw their code from the GPL, an arbitrator/judge has two reasonable options, considering that party B has already profited from the contract: a) Party B compensates party A in a reasonable amount based on the amount of profit they made off the product; or b) Party B abides by the terms of the contract and allows their code to be released as GPL. (option A is very difficult when there are potentially thousands of people who would need to be compensated)
Any Judge, or contract law, that allows Party B to both start disallowing their code from being used, and not provide any form of compensation to Party A, is seriously flawed.
The motive comes into play as well, since contracts are supposed to be entered within a set of fair and honest negotiations. If one party can prove the other was unfaithful when they signed the contract, it *may* give them leverage before a judge.
On Sun, 2003-08-24 at 17:59, edA-qa mort-ora-y wrote:
This varies a *lot* from country to country, but a typical pattern is that ignorance is no excuse from criminal law, and in contract law it becomes fuzzy.
Not really. Ignorance of the law is indefensable; ignorance in general is. We're talking about the difference between knowing whether or not an act is right or wrong, and knowing whether or not an act is taking / has taken plac, apologies if you are misunderstanding the use of the word.
For example, let's say you have your video machine stolen by a friend. Even if you've been around to their house subsequently to watch videos on it, if at some point later you can show it was stolen from you then it's still yours. The defence of "you saw it a number of times and didn't realise it was yours" doesn't exist, as far as I know.
In the case of distributing code dervied from a GPL licensed codebase (from party A) and them claiming your (party B) own code is not GPL, this removes the original parties compensation in the contract. When party B decides they made a serious mistake and effectively withdraw their code from the GPL, an arbitrator/judge has two reasonable options, considering that party B has already profited from the contract: a) Party B compensates party A in a reasonable amount based on the amount of profit they made off the product; or b) Party B abides by the terms of the contract and allows their code to be released as GPL. (option A is very difficult when there are potentially thousands of people who would need to be compensated)
Any Judge, or contract law, that allows Party B to both start disallowing their code from being used, and not provide any form of compensation to Party A, is seriously flawed.
I really don't see what this example has to do with anything. I presume Party B are SCO, I'm not sure who Party A are supposed to be (Linux developers?). The example fails mainly because we're not talking about contract law (the GPL is not a contract). But it's also not an accurate description of what's happening at the moment.
SCO aren't distributing code derived from GPL code (at least, not that we know ;), they are claiming that GPL code being distributed derives from theirs. The argument being put forward was because they had redistributed this code, it must be covered by the GPL already, not that they must now GPL the code for some reason of damages.
Cheers,
Alex.
Alex Hudson wrote:
Not really. Ignorance of the law is indefensable; ignorance in general is. We're talking about the difference between knowing whether or not an
Agreed, I meant ignorance of the law, not ignorance in general.
I really don't see what this example has to do with anything. I presume Party B are SCO, I'm not sure who Party A are supposed to be (Linux developers?). The example fails mainly because we're not talking about contract law (the GPL is not a contract). But it's also not an accurate description of what's happening at the moment.
The GPL is a contract. Copyright law prohibits individuals from making copies, the GPL effectively offers the right to make copies and more as a benefit of the contract. If the GPL is not a contract, then it is nothing, and you really can't do anything with GPL'd code.
A contract is roughly defined as an agreement made between two or more parties involving the exchange of value/benefits. (This last bit is important in the discussion of whyt EULA's may not be valid contracts, and therefore are nothing.)
SCO aren't distributing code derived from GPL code (at least, not that we know ;), they are claiming that GPL code being distributed derives
SCO did distribute GPL code, as part of their Linux system offerings. It is to be seen if *their* code was part of this offering at the time they offered it (which was still quite recently).
What I am saying is that they wish to back out of the agreement they made under the GPL, stating that others may further modify and/or distribute their code (whether they put their own code in their intentionally or not is irrelevant).
The point I made about damages is that they wish to break the contract they made with the GPL, and the GPL doesn't have such a clause stating what happens, so a judge/arbitrator would have to assess SCO's liabilities for damages under the contract.
If SCO's ideas/patents were not present in any Linux which they were distributing, at any point while they were distributing it, then their code based on these ideas never were released under the GPL and my explanation is irrelevant.
On Tue, 2003-08-26 at 18:02, edA-qa mort-ora-y wrote:
The GPL is a contract. Copyright law prohibits individuals from making copies, the GPL effectively offers the right to make copies and more as a benefit of the contract. If the GPL is not a contract, then it is nothing, and you really can't do anything with GPL'd code.
That's not the standard description, and I don't think it's a point of view the FSF would subscribe to. The GNU GPL is a license, not a contract - it permits the free copying, modification and distribution under certain conditions. If I remember correctly, one of Larry Lessig's criticisms of the GPL is that it's not a contract: I'm sure the OSI have an alternative licence they dreamed up that did use contract law as it's lever (i.e., more like a EULA).
The GPL isn't a covenant between two individuals, therefore isn't a contract. I'm fairly sure that's the standard/intended thinking.
SCO did distribute GPL code, as part of their Linux system offerings. It is to be seen if *their* code was part of this offering at the time they offered it (which was still quite recently).
They distributed it, but did not release it. They did not licence it under the GPL, and the people who released it didn't have rights to licence it under the GPL (iff SCO are correct ;). It's a copyright license violation, I'm not sure that automatically means the GPL would apply though. As far as I'm aware, you cannot force people to relicence code on the basis of a violation - although I would guess it is a remedy available.
For example, if a company released a proprietary version of a piece of GPL'd software, I'm not sure you could force them to GPL that software: the law would allow you to stop them selling the product, and allow you to claim damages, but I don't think you can automatically gain access to the code.
Cheers,
Alex.
Alex Hudson wrote:
That's not the standard description, and I don't think it's a point of view the FSF would subscribe to. The GNU GPL is a license, not a
The GPL isn't a covenant between two individuals, therefore isn't a contract. I'm fairly sure that's the standard/intended thinking.
This is where, as I mentioned, contract law starts to become fuzzy from country to country. From the viewpoint in Canadian law, it is a contract, plain and simple -- otherwise it is nothing, and has no merit beyond a work of fiction.
I always saw the GPL as an agreement between two parties: 1) the distributor; 2) the recipient. The distributor is allowing you to further distribute the code, and derivaties, on the premise that you distribute under the same terms.
I am talking strictly about distribution, the "right to use" the software is very unclear, stands in the same ground as EULA's do.
They distributed it, but did not release it. They did not licence it
I see a judge with many headaches... In any case, if this makes it to trial, the judgement will be required reading for contract and IP lawyers. ;)
under the GPL, and the people who released it didn't have rights to licence it under the GPL (iff SCO are correct ;). It's a copyright license violation, I'm not sure that automatically means the GPL would
Yes, and no. Two options: a) SCO willingly entered the contract but made a mistake. The assessment of damages and reasonable actions is thus open for debate, but it is unlikely for a judge/arbitrator to open up the code -- they tend to only think in dollar values. b) SCO maintains, and succeeds in showing, they never entered the contract. In this case it is pretty much up to SCO to decide what to do, within the realm of reasonable action. Charging a license fee for linux is well within reason, as you stated before, it is really not their problem that it removes the ability to further distribute Linux. But as I said after, they then participated in unfair trade practices and open themselves up to lawsuits of those that bought their Linux.
For example, if a company released a proprietary version of a piece of GPL'd software, I'm not sure you could force them to GPL that software: the law would allow you to stop them selling the product, and allow you to claim damages, but I don't think you can automatically gain access to the code.
I'm not sure that you couldn't force them to GPL that software. If I am a copyright holder in the code, and they sell it, they have agreed then to the GPL I had on my original code (as they have no other right to distribute). If their code is not GPL, then they have failed to meet their obligation in the agreement.
From my viewpoint, I don't find it hard to believe that a Judge would accept that the company needs to uphold its obligation. I could simply refuse a monetary compensation, or I could agree to them ceasing to distribute the code.
What is clear is that the company has to offer *something* of value in exchange for distributing the code. And if I disagree with that offer, it will end up in the court system and a judge or arbitrator will have to decide what I get in return.
On Tue, 2003-08-26 at 19:24, edA-qa mort-ora-y wrote:
The GPL isn't a covenant between two individuals, therefore isn't a contract. I'm fairly sure that's the standard/intended thinking.
This is where, as I mentioned, contract law starts to become fuzzy from country to country.
This isn't anything to do with contract law; it's purely copyright law. From the Copyright Act,
"The owner of the copyright in any work may assign the right, either wholly or partially, and either generally or subject to limitations relating to territory, medium or sector of the market or other limitations relating to the scope of the assignment, ..., and may grant any interest in the right by licence, but no assignment or grant is valid unless it is in writing signed by the owner of the right in respect of which the assignment or grant is made, or by the owner's duly authorized agent."
13.4, "Assignment and licences"
Copyright law explicitly allows the creation of licences, encompassing any of the rights given by the law, with any limitations on the scope of the licence. It also notes the grant of licence is not valid without the owner of the right endorsing it - hence my point that if SCO's code is in Linux, it is not endorsed and therefore is a breach of copyright.
Canadian law does not view this as a contract. Contract law is therefore irrelevant. I think that also renders your contract-based arguments irrelevant, since you're talking about the GPL as the contract. Contract law will definitely come into this argument, however, the contract in question will be that between SCO and IBM.
Cheers,
Alex.
On Tue, 2003-08-26 at 18:02, edA-qa mort-ora-y wrote:
The GPL is a contract. Copyright law prohibits individuals from making copies, the GPL effectively offers the right to make copies and more as a benefit of the contract. If the GPL is not a contract, then it is nothing, and you really can't do anything with GPL'd code.
A software license is _NOT_ a contract (although it is somewhat analogous).
In the specific case of the GNU GPL, you do not even have to agree with anything to use the software: we're talking about an unilateral grant of permission to use for any purpose so there's no agreement between two parties.
If you want to redistribute copies or derived works, you are also granted permission to do it, so long as you give the same rights to whoever receives to software.
If you don't want, then this does not apply to you. If you do, you don't have to agree with the author for permission to do it as long as you do it in a certain way.
Where does this fall under contract law where you have to have an agreement between at least two parties and witnesses?
Nowhere. Conclusion: not a contract.
Hugs, Rui
Rui Miguel Seabra wrote:
A software license is _NOT_ a contract (although it is somewhat analogous).
If it is not a contract, then it is nothing. Private individuals do not have the right to draft up agreements that dictate the terms under which another individual can live their life, or use/distribute their software... unless that agreement is a contract.
If you want to redistribute copies or derived works, you are also granted permission to do it, so long as you give the same rights to whoever receives to software.
I am speaking solely about distribution rights, since I agree there is a whole unusual can of worms lurking in the "right to use" agreements, like EULA.
If you do, you don't have to agree with the author for permission to do it as long as you do it in a certain way.
Yes, you do have to agree with the author. The author has put his code under the GPL, which is a grant of contract to anybody who should accept its terms. It is an agreement between two parties.
My viewpoint comes from Canada, but I assume it is similar elsewhere. A contract does not need to have a formal set of signatures or a witness, indeed it doesn't even need to be written down. Oral agreements are legally still contracts.
Based on the contracts I've had hear in Germany, and those I've received from France, Russia, and the USA, it seems, to me, then GPL would qualify as a contract when the code is distributed (whether it is legal in all these contexts I am not sure).
(Point to clarify. The GPL on its own is not the contract, the contract is the GPL + the will of the copyright holders to distribute under its terms + the will of the recipient to accept those terms. This point is not relevant to this discussion though.)
** Alex Hudson home@alexhudson.com [2003-08-24 13:16]:
On Sun, 2003-08-24 at 11:51, Paul Tansom wrote:
Catching up on my mail, so a bit slow to reply here, but...
Tell me about it :o)
Well it's like this, after a short spell working commercially with free software I've ended up starting my own business,... :-)
Only kidding, I'm not about to list out my life history, don't panic!
I'm no legal expert and I don't know how things differ in the US, but surely ignorance is no defense in the eyes of the law?
Well, ignorance is actually a defence. For example, if someone cons you into signing a document that is actually a contract for something, that signature doesn't really mean much and you are not considered bound by the contract.
Agreed, but in this case there is also the act of deception to take into consideration.
The point I was making was that it seems to me to be different to redistribute software and to grant a copyright licence to your own software. The reason I think people argue the point is because with free software, you can see what is in it, and people think SCO should have been aware. I don't really think that matters though. They didn't give permission for people to distribute the code, so the fact they were effectively conned into distributing it shouldn't automatically GPL it.
A fair point if Caldera(SCO) were simply distributing the code with an amount of customisation to the distribution. In this case they were actually involved with the kernel development and as such had a close working knowledge of both the code and the process. (*)
I just think any other scenario would be unfair, in general, no matter what I might think about SCO themselves.
Whatever my views on SCO's actions, if I agreed I would say so. In the true tradition of freedom of speech/thought/etc. we'll have to agree to differ though. (*)
In SCO/Caldera's case, they had a product that had a close relationship to the Linux code they were/are distributing. As such they should have examined to code to ensure they weren't 'giving away' anything they didn't want to, and if/since they didn't that is their own problem.
I don't think so. The UnixWare/Linux groups were apparently very far apart (different continents). They purposefully kept the groups separate so that code couldn't 'migrate' from one to the other. On that basis, which of these groups was in a position to warn that Unix code was getting into Linux? Neither, in my opinion.
I which case it would be down to the UnixWare group to look at the Linux code. It's not as if they wouldn't have had access to it. It would be down to the upper management to ensure that they were properly briefed on the implications of running the two groups - they were certainly aware enough to separate the divisions.
I will agree that it is an extremely difficult situation for a company to be in. If a third party takes code from one group (UnixWare) and puts it into code being worked on by the other group (Linux) then the Linux group will have no way of realising this. The action should then be against the third party though. If Microsoft had used SCO code within Windows I would not expect SCO to be going after Windows users.
(*) I'm wavering a bit on my stance having written this in that if SCO can prove that none of their programmers had any involvement whatsoever with the sections of the Linux kernel containing the offending code then they have not made it available under the GPL license. If on the other hand they have hand involvement with that code then SCO, however unwittingly, have released the code under the GPL license.
The only people I know who regularly audit their whole code base would be the BSD people, especially OpenBSD. As I understand it, the majority of that auditing is done mechanically. If you expect people to audit free software before redistribution, you effectively remove their freedom to redistribute, because it's an almost unsatisfiable burden. It would also be a burden that only free software would bear, since with proprietary software you cannot see what is inside it and therefore cannot audit it.
I'm not saying anyone should audit the code in order to distribute it, just that parties in a position such as SCO's (similarly IBM and Sun) should take the necessary steps to protect their intilectual property if the value it. I'm not saying it is an easy situation to be in, but one they should take responsibility for.
If SCO had redistributed their Unix code as free-as-in-beer proprietary closed-source software, what would happen in your scenario? Are they still liable, even though they cannot actually see the source code and verify it? Or, are they not liable? If they are not, then you're making proprietary software much, much easier to deal with. Free software would become even more distasteful.
From reading my above comments the answer would be clear to this - no
they would not be liable since they have not worked with the source code. If they had been involved with the code of the closed source software then yes they would have released it under the license used. There would be less of an issue here though, as the code would still be closed source so the license would only apply to the binary and not the source code.
I wouldn't say distasteful, in fact I don't follow the 'more distasteful', but yes proprietry software is easier to deal with on its own. Free software is also easier to deal with on its own. In a tidy world there would be one or the other, in an ideal world there would only be free software (imho). Unfortunately in the untidy, less than ideal world we live in both have to coexist - and it's not at all easy sometimes!
** end quote [Alex Hudson]
On Mon, 2003-08-25 at 23:30, Paul Tansom wrote:
Tell me about it :o)
Well it's like this, after a short spell working commercially with free software I've ended up starting my own business,... :-)
... as a comedian? :o)
A fair point if Caldera(SCO) were simply distributing the code with an amount of customisation to the distribution. In this case they were actually involved with the kernel development and as such had a close working knowledge of both the code and the process. (*)
The above doesn't sit well with....
I which case it would be down to the UnixWare group to look at the Linux code. It's not as if they wouldn't have had access to it. It would be down to the upper management to ensure that they were properly briefed on the implications of running the two groups - they were certainly aware enough to separate the divisions.
... since you are saying that their Linux developers should be spotting the stolen code, but that the UnixWare team should be the ones reviewing Linux. Doing either/both would be suicidal for SCO, so I don't agree with either scenario. IBM are in the same position (developing Linux and AIX), as are Sun (I would guess), HP (to an extent) and probably all the guys doing embedded work.
If you have one team working on a proprietary kernel and one on a free software kernel, I don't see how the two can be allowed to mix, and one to review the code from the other. I don't think any companies mentioned previously would countenance doing it, either.
If the UnixWare chaps were reading the Linux code, they would have to be doing this regularly to pick up any copying (given the vast size of the code). To do this well, they would become immersed in the code to a sufficient degree that they may well copy it into UnixWare unthinkingly. SCO would never allow that, neither would any other developer. There is no onus on them whatsoever to do it. If they keep things separate themselves, they have no reason to look for cross-pollenation.
I will agree that it is an extremely difficult situation for a company to be in. If a third party takes code from one group (UnixWare) and puts it into code being worked on by the other group (Linux) then the Linux group will have no way of realising this. The action should then be against the third party though.
That's exactly what's happening. They're not taking action against users. I also think SCO's licensing system is subtley clever: they are ensuring it continues to be infringment to run Linux, but not to use it (if you have a SCO licence). This doesn't conflict with the GPL, AFAIK (in terms of use of the software).
The problem they have with their licensing system is that it would be impossible to reconcile the conflict with the GPL for distribution going forwards, but I don't think they would care about that: they're going after the Linux distributors, so blocking distribution would suit them fine. I think it's fairly clear that if they did find Linux 2.4+ to be infringing, then we would pretty much be back to Linux 2.2 - I don't think the subsequent code could be salvaged, except maybe device drivers, without a lot of work, which would involve starting with 2.2 and pulling in newer stuff.
I'm wavering a bit on my stance having written this in that if SCO can prove that none of their programmers had any involvement whatsoever with the sections of the Linux kernel containing the offending code then they have not made it available under the GPL license. If on the other hand they have hand involvement with that code then SCO, however unwittingly, have released the code under the GPL license.
How can you release something unwittingly? Only if they released the actual code in question, would they be doing that. I would go back to my previous example of stolen video recorder.
I just don't see how they could be expected to detect the code, if it was indeed copied from Unix. Their Linux programmers wouldn't know what it looked like, even if they came across it.
If SCO had redistributed their Unix code as free-as-in-beer proprietary closed-source software, what would happen in your scenario? Are they still liable, even though they cannot actually see the source code and verify it? Or, are they not liable? If they are not, then you're making proprietary software much, much easier to deal with. Free software would become even more distasteful.
From reading my above comments the answer would be clear to this - no they would not be liable since they have not worked with the source code. If they had been involved with the code of the closed source software then yes they would have released it under the license used. There would be less of an issue here though, as the code would still be closed source so the license would only apply to the binary and not the source code.
Less of an issue how? Their code has still been nicked. Source and binary are not licensed differently (in fact, they might fall under 'translations' - not sure).
It seems to be that you are setting a barrier of detection: that there are certain scenarios in which you expect them to detect the stolen code, and others in which you don't. Quite apart from the fact that the hurdle you set is arbitrary, I also don't see that it is relevant. If someone steals something from you, it remains stolen under all circumstances (statutes of limitations not withstanding). The flagrancy of the theft doesn't matter.
I wouldn't say distasteful, in fact I don't follow the 'more distasteful'
Distasteful to companies who are already scared of the GPL. If the result of this case is that your proprietary code can be lost as a result of someone else stealing it and publishing it, then that will make Free Software verboten in a huge number of companies. It would perpetuate this 'GPL IP virus' meme; to a horrible extent. The only 'crime' SCO would be guilty of - in your world - is not detecting the theft soon enough. But, they have lost their 'valuable' proprietary code. If other companies see that happen, that would serve to kill off a huge amount of development that could otherwise happen. I can't think of many worse scenarios.
Cheers,
Alex.
** Alex Hudson home@alexhudson.com [2003-08-26 15:57]:
On Mon, 2003-08-25 at 23:30, Paul Tansom wrote:
Tell me about it :o)
Well it's like this, after a short spell working commercially with free software I've ended up starting my own business,... :-)
... as a comedian? :o)
Ba boom :-)
A fair point if Caldera(SCO) were simply distributing the code with an amount of customisation to the distribution. In this case they were actually involved with the kernel development and as such had a close working knowledge of both the code and the process. (*)
The above doesn't sit well with....
I which case it would be down to the UnixWare group to look at the Linux code. It's not as if they wouldn't have had access to it. It would be down to the upper management to ensure that they were properly briefed on the implications of running the two groups - they were certainly aware enough to separate the divisions.
... since you are saying that their Linux developers should be spotting the stolen code, but that the UnixWare team should be the ones reviewing Linux. Doing either/both would be suicidal for SCO, so I don't agree with either scenario. IBM are in the same position (developing Linux and AIX), as are Sun (I would guess), HP (to an extent) and probably all the guys doing embedded work.
No, I am not commenting at all about the logistics of how it should be done. What I am saying is that if employee U of a company S writes a piece of code and releases it under license P the code belongs to company S; then employee L of the same company S gets the same piece of code and works with it without knowing that he shouldn't have it, and subsequently releases it under license F, the code still belongs to company S, and it is still company S releasing it under a different license; hence I don't see how company S can then say "oops, we didn't realise we'd done that, I'm really sorry but everyone who bought the code under license F now has to pay us X amount extra", when it is their internal processes that allowed them to release the code they owned under the wrong license. Admitedly in practice this is a very complex issue, made even more so by the involvement of third parties not directly employed by the company.
If you have one team working on a proprietary kernel and one on a free software kernel, I don't see how the two can be allowed to mix, and one to review the code from the other. I don't think any companies mentioned previously would countenance doing it, either.
If the UnixWare chaps were reading the Linux code, they would have to be doing this regularly to pick up any copying (given the vast size of the code). To do this well, they would become immersed in the code to a sufficient degree that they may well copy it into UnixWare unthinkingly. SCO would never allow that, neither would any other developer. There is no onus on them whatsoever to do it. If they keep things separate themselves, they have no reason to look for cross-pollenation.
If they had no reason to look, then why did they? The fact that they did look means that there must be a practical method of doing so!
I will agree that it is an extremely difficult situation for a company to be in. If a third party takes code from one group (UnixWare) and puts it into code being worked on by the other group (Linux) then the Linux group will have no way of realising this. The action should then be against the third party though.
That's exactly what's happening. They're not taking action against users. I also think SCO's licensing system is subtley clever: they are ensuring it continues to be infringment to run Linux, but not to use it (if you have a SCO licence). This doesn't conflict with the GPL, AFAIK (in terms of use of the software).
I disagree here to some extent. While they are not actually taking direct action they are saying that they consider themselves entitled to. As such they are using the threat of taking action as a means of 'selling' their license. To my mind they appear to be running a hi-tech protection racket, but this is not the point being discussed here.
The problem they have with their licensing system is that it would be impossible to reconcile the conflict with the GPL for distribution going forwards, but I don't think they would care about that: they're going after the Linux distributors, so blocking distribution would suit them fine. I think it's fairly clear that if they did find Linux 2.4+ to be infringing, then we would pretty much be back to Linux 2.2 - I don't think the subsequent code could be salvaged, except maybe device drivers, without a lot of work, which would involve starting with 2.2 and pulling in newer stuff.
I'm wavering a bit on my stance having written this in that if SCO can prove that none of their programmers had any involvement whatsoever with the sections of the Linux kernel containing the offending code then they have not made it available under the GPL license. If on the other hand they have hand involvement with that code then SCO, however unwittingly, have released the code under the GPL license.
How can you release something unwittingly? Only if they released the actual code in question, would they be doing that. I would go back to my previous example of stolen video recorder.
I had to remind myself of this, but to follow the analogy hows this:
Company S has a batch of videos that they wish to sell at shop U which sells at high prices; a sub-contractor moves some of the videos sitting in the warehouse to an area due to be shipped to shop L which sells at low prices; the videos are shipped and sold from shop L; given that company S owns both shop U and shop L the customer woundn't expect the company to then turn round and say "sorry, if you want to continue to be able to watch your video then you'll have to pay us X amount, otherwise we might take legal action".
I just don't see how they could be expected to detect the code, if it was indeed copied from Unix. Their Linux programmers wouldn't know what it looked like, even if they came across it.
Again, I'm not going into the how's, just stating that a different division of the same company has unwittingly released the code under a different license. Should the company be able to charge people who have "bought" the software in good faith to continue to use it? I don't think so myself.
If SCO had redistributed their Unix code as free-as-in-beer proprietary closed-source software, what would happen in your scenario? Are they still liable, even though they cannot actually see the source code and verify it? Or, are they not liable? If they are not, then you're making proprietary software much, much easier to deal with. Free software would become even more distasteful.
From reading my above comments the answer would be clear to this - no they would not be liable since they have not worked with the source code. If they had been involved with the code of the closed source software then yes they would have released it under the license used. There would be less of an issue here though, as the code would still be closed source so the license would only apply to the binary and not the source code.
Less of an issue how? Their code has still been nicked. Source and binary are not licensed differently (in fact, they might fall under 'translations' - not sure).
To my understanding, in the closed source world you are purchasing the right to run the binary, and get no rights whatsoever to the source, hence if they sold the binary and had no access to view the source then I would agree with you. Likewise, if they had simply been distributing the code without working on developing it, then I would also agree with you. It is the fact that they were Linux developers (to my understanding of things) and have therefore taken the act of releasing their work under the GPL license. If they have not, as a company, worked with the relevant code, then once more I will agree with you.
It seems to be that you are setting a barrier of detection: that there are certain scenarios in which you expect them to detect the stolen code, and others in which you don't. Quite apart from the fact that the hurdle you set is arbitrary, I also don't see that it is relevant. If someone steals something from you, it remains stolen under all circumstances (statutes of limitations not withstanding). The flagrancy of the theft doesn't matter.
It is a very, very difficult situation to reconcile, but having thought a bit about it I would suggest that detection of the code is not necessarily the only solution. Again, not being a lawyer I'm not 100% sure of this suggestion, but if SCO had been a parent company owning two other companies, say Caldera (for the Linux code) and Unixware (for the Unix code) then Caldera would have no rights over the Unixware code and the code would therefore not have been published by the owner under the wrong license. Just a thought, and continuing that train of thought I cannot say that I am aware of whether this may actually be the case - I am assuming not, but if it is, once again I would then be agreeing with you!
I wouldn't say distasteful, in fact I don't follow the 'more distasteful'
Distasteful to companies who are already scared of the GPL. If the result of this case is that your proprietary code can be lost as a result of someone else stealing it and publishing it, then that will make Free Software verboten in a huge number of companies. It would perpetuate this 'GPL IP virus' meme; to a horrible extent. The only 'crime' SCO would be guilty of - in your world - is not detecting the theft soon enough. But, they have lost their 'valuable' proprietary code. If other companies see that happen, that would serve to kill off a huge amount of development that could otherwise happen. I can't think of many worse scenarios.
I see, yes there is a risk that other companies could see this as demonstrating how the GPL could be a risk to their own code. This would be on the development side rather than the using side, and I'm not entirely sure how much of an impact the SCO case would have on this. It all comes down to the perception of the validity of their claim I guess. I do see your point though. I would hope that it would be seen that SCO was guilty of not doing 'due diligence' to protect their code in a situation that is quite clearly requiring a great deal of care.
** end quote [Alex Hudson]
I seem to be coming up with a number of scenarios where I would agree with you, but unfortunately I am not yet convinced that they apply in this case. Ho, hum, tiddely pomme.
On Wed, 2003-08-27 at 00:27, Paul Tansom wrote:
No, I am not commenting at all about the logistics of how it should be done. What I am saying is that if employee U of a company S writes a piece of code and releases it under license P the code belongs to company S; then employee L of the same company S gets the same piece of code and works with it without knowing that he shouldn't have it, and subsequently releases it under license F, the code still belongs to company S, and it is still company S releasing it under a different license; hence I don't see how company S can then say "oops, we didn't realise we'd done that, I'm really sorry but everyone who bought the code under license F now has to pay us X amount extra", when it is their internal processes that allowed them to release the code they owned under the wrong license.
Ah, I think we're arguing about different things here. This isn't SCO EULA vs. GPL (P vs F ?). The problem here is that employee L of other company Y released the code. Releasing and redistributing are different acts, and I think it's fairly obvious SCO/Caldera made clear they were redistributing it (modulo their patches).
If you read the section of the GPL which talks about applying the GPL, it states how important it is to have an accurate copyright claim and licence. Releasing something without it puts you in a grey area; I suspect that it's not possible to license your copyrights implicitly (certainly, the snippet from the Canadian Copyright Act I posted yesterday appears to explicitly say that cannot happen).
If SCO have indeed released the code themselves, then fair enough. But that's not what they are saying has happened.
If they had no reason to look, then why did they? The fact that they did look means that there must be a practical method of doing so!
No-one actually knows if they did look. For example, there is a third-party with known interest in Linux that has extremely good knowledge of the codebase (they developed it) and recently gave SCO a lot of money.
I'm not sure the point is relevant anyway; they are not under any onus to check that people are not infringing their copyright: unlike trademarks, it's not something you have to defend actively. You don't even need to enforce it consistently.
That's exactly what's happening. They're not taking action against users. I also think SCO's licensing system is subtley clever: they are ensuring it continues to be infringment to run Linux, but not to use it (if you have a SCO licence). This doesn't conflict with the GPL, AFAIK (in terms of use of the software).
I disagree here to some extent. While they are not actually taking direct action they are saying that they consider themselves entitled to. As such they are using the threat of taking action as a means of 'selling' their license. To my mind they appear to be running a hi-tech protection racket, but this is not the point being discussed here.
Oh, I'm not disagreeing with that ;) I wasn't trying to evaluate the morals of such an action (I think they are completely wrong), just that it seemed quite cute. The GPL covers distribution, their licences are run-time. They're offering people who use Linux an easy exit without conflicting with the GPL, but still cutting off distributors.
Sorry, it was a side-issue, and probably deserves separate commentary. I would be interested to know whether or not people think it's legal or not; other than false claims/fraud, it seems fairly sound.
I see, yes there is a risk that other companies could see this as demonstrating how the GPL could be a risk to their own code. This would be on the development side rather than the using side, and I'm not entirely sure how much of an impact the SCO case would have on this. It all comes down to the perception of the validity of their claim I guess. I do see your point though.
To be honest, it's likely the damage has already been done - people are aware the problem exists (at least in the mind of SCO), that basically makes the problem real. People would probably associate Linux with the SCO issue for years to come unless SCO are shot down in a very public manner. By this logic, the absolute worst thing that could happen is that SCO and IBM come to a private settlement. Thankfully, it looks fairly unlikely that will happen.
I would hope that it would be seen that SCO was guilty of not doing 'due diligence' to protect their code in a situation that is quite clearly requiring a great deal of care.
Hmm. I'm personally hoping the GPL doesn't come into it. If code was stolen, I say the licence the stolen code was released under shouldn't matter (GPL or not). However, I strongly suspect the code wasn't 'stolen' and that SCO will just be shown to be wrong.
If there is an argument in court, I think it will probably be about two things: whether or not the IBM contract covers the derived works of AIX, and what the definition of a derived work actually is. I think both arguments are incidental to the GPL, except for the fact that derived work decisions obviously have an effect on the scope of the GPL (since they are effectively demarquing the scope of copyright law, at least in the US). In past years, I think it's the case that the notion of a derived work is quite a broad one, so it could come down basically to the contents of the contract.
Cheers,
Alex.
** Alex Hudson home@alexhudson.com [2003-08-27 14:27]:
On Wed, 2003-08-27 at 00:27, Paul Tansom wrote: Ah, I think we're arguing about different things here. This isn't SCO EULA vs. GPL (P vs F ?). The problem here is that employee L of other company Y released the code. Releasing and redistributing are different acts, and I think it's fairly obvious SCO/Caldera made clear they were redistributing it (modulo their patches).
I think you're right here, we are working on differing basic assumptions. As I see it you are working on the premise that SCO did not work on the offending code and are simply acting as a distribution channel for it (probably along the lines of some of the smaller Linux distros that largely package and compile the code), whereas I am working on the premise that they are a long standing distribution that have had direct development involvement with the kernel (including embeded work in the past) and therefore probably have worked directly with the code. If your assumption is correct, then they have not released it under the GPL; if mine is then it is likely they have.
If you read the section of the GPL which talks about applying the GPL, it states how important it is to have an accurate copyright claim and licence. Releasing something without it puts you in a grey area; I suspect that it's not possible to license your copyrights implicitly (certainly, the snippet from the Canadian Copyright Act I posted yesterday appears to explicitly say that cannot happen).
Absolutely, there is an amazing amount of misconception being written the the press on this issue. It is quite simply not possible for anyone other than the copyright holder to release the code under any license, GPL or otherwise.
If SCO have indeed released the code themselves, then fair enough. But that's not what they are saying has happened.
As with everything in the SCO case, the true facts are not available, and SCO show no signs of changing this. I guess the key question is, if they did actually work on the code in question (or some of it) and knowingly applied the GPL license to it by including it, but didn't realise that it originated from the Unixware side of the company do they have any comeback on anyone except themselves?
No-one actually knows if they did look. For example, there is a third-party with known interest in Linux that has extremely good knowledge of the codebase (they developed it) and recently gave SCO a lot of money.
I'm not sure the point is relevant anyway; they are not under any onus to check that people are not infringing their copyright: unlike trademarks, it's not something you have to defend actively. You don't even need to enforce it consistently.
Thinking it through, there is no way without knowing:
- whether the code in question is genuinly SCO's, and.. - what route it took betwen the Unixware and Linux groups
there is no way of knowing whether it is their own fault and they should have checked. If the route was internal, then more fool them; if on the other hand the route was external things get more complicated - if via an unrelated third party then they probably have a legal case against that third party, - if via a third party privvy to the Unixware code then it may well come down to processes and checking again (should the third party have been restricted from passing the SCO between parts of the SCO company? Should/was the source of the code identified?), then again we may be back to the legal case again!
This seems to boil down to the crux of the case they have against IBM (in which they conveniently ignore any potential involvement by the SCO Linux group), and all of it boils down to what the code is and whether they have a legal claim to it in the first place.
<snipped for another thread!>
To be honest, it's likely the damage has already been done - people are aware the problem exists (at least in the mind of SCO), that basically makes the problem real. People would probably associate Linux with the SCO issue for years to come unless SCO are shot down in a very public manner. By this logic, the absolute worst thing that could happen is that SCO and IBM come to a private settlement. Thankfully, it looks fairly unlikely that will happen.
Indeed, apart from the fact that I can't see IBM doing it (but then I'm no expert), SCO have attacked in so many different directions that I (still as a non expert) can only see it as how long, and how much collateral damage to Linux/GPL/GNU/etc. before they go down.
Hmm. I'm personally hoping the GPL doesn't come into it. If code was stolen, I say the licence the stolen code was released under shouldn't matter (GPL or not). However, I strongly suspect the code wasn't 'stolen' and that SCO will just be shown to be wrong.
The license is, as you say, largely irrelevant to the technicalities, however the fact that it is the GPL in this case is what is raising the profile so high.
If there is an argument in court, I think it will probably be about two things: whether or not the IBM contract covers the derived works of AIX, and what the definition of a derived work actually is. I think both arguments are incidental to the GPL, except for the fact that derived work decisions obviously have an effect on the scope of the GPL (since they are effectively demarquing the scope of copyright law, at least in the US). In past years, I think it's the case that the notion of a derived work is quite a broad one, so it could come down basically to the contents of the contract.
If I can remember the right bits from the vast amount of writing there has been on the subject, and assuming some degree of accuracy/truth in the reporting, the derivative works could have a massively wide reaching implication should SCO win the case. iirc the only company with 'clean' code as far as SCO are concerned is Sun, which leaves both Apple and Microsoft potentially in the firing line, not to mendiong BSD (even though they've already been there!), and the demise or near demise of things like AmigaDOS, OS/2, BeOS, etc. would be the only things keeping them out of the firing line. Just to keep things interesting and bubbling along there's also the Red Hat case and their fund in concunction with SuSe, and I've read of Linux groups in both Australia and Canada taking some form of action, although I don't see them as being anything more than a news story for a month or so!
** end quote [Alex Hudson]
A Ter, 2003-08-12 às 20:54, Niall Douglas escreveu:
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
I couldn't disagree more with you on this. The force of the GPL and the reason why no company so far, after hundreds of GPL violations, dared to go to court against the GPL is because there aren't much doubts about its meaning.
If you want to understand how much work has gone into getting the GPL to this point read the "Enforcing the GPL" series in http://emoglen.law.columbia.edu/
On 12 Aug 2003 at 21:21, João Miguel Neves wrote:
A Ter, 2003-08-12 às 20:54, Niall Douglas escreveu:
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
I couldn't disagree more with you on this. The force of the GPL and the reason why no company so far, after hundreds of GPL violations, dared to go to court against the GPL is because there aren't much doubts about its meaning.
If you want to understand how much work has gone into getting the GPL to this point read the "Enforcing the GPL" series in
I appreciate your point in this, but I've not met many lawyers who think it's watertight. And indeed, quite a few management bods have thought about contesting it and backed down after realising how awful it would be for PR.
The GPL is far more a social contract than a legal one. To violate it invokes the ire of a very vocal group and even if you don't agree with it in itself, every programmer in the world doesn't like people doing things with their code they specifically said not to do.
However in situations where sales are already predetermined (ie; bespoke solutions), GPL violation is endemic according to a lawyer I talked to in British Aerospace systems. This is because PR image doesn't matter to sales and as the lawyer said, the FSF wouldn't want to test the GPL against military contractors who have plenty of cash and no sales to lose lest the GPL be struck down.
(His words, not mine)
Cheers, Niall
A Qua, 2003-08-13 às 00:11, Niall Douglas escreveu:
I appreciate your point in this, but I've not met many lawyers who think it's watertight. And indeed, quite a few management bods have thought about contesting it and backed down after realising how awful it would be for PR.
I've never met one lawyer that thinks that anything is watertight. If you start talking about judges and law professors, that's another thing.
The GPL is far more a social contract than a legal one. To violate it invokes the ire of a very vocal group and even if you don't agree with it in itself, every programmer in the world doesn't like people doing things with their code they specifically said not to do.
However in situations where sales are already predetermined (ie; bespoke solutions), GPL violation is endemic according to a lawyer I talked to in British Aerospace systems. This is because PR image doesn't matter to sales and as the lawyer said, the FSF wouldn't want to test the GPL against military contractors who have plenty of cash and no sales to lose lest the GPL be struck down.
(His words, not mine)
I would doubt that's the case. I know a few defense contracts and giving the conditions that are part of them, most of them are Free Software by requirement. But, as always, if you have evidence of such violation, check http://www.gnu.org/licenses/gpl-violation.html and e-mail license-violation@gnu.org.
Yes, I've seen too many lawyers misunderstanding the GPL to the point that they see a lot of violations where they don't exist.
On Wed, 2003-08-13 at 00:11, Niall Douglas wrote:
I appreciate your point in this, but I've not met many lawyers who think it's watertight. And indeed, quite a few management bods have thought about contesting it and backed down after realising how awful it would be for PR.
Yes. Being accused of copyright violation because you choose not to respect your "neighbour" is bad PR, so all cases got settled out of court.
My opinion about those lawyers who say a lot of things (showing little to no understanding of the GNU GPL) is that they have their right to an opinion, but I'd enjoy defending myself against them in court over a GNU GPL issue.
Just imagine the sport headlines: 0-1: lawyer looses at home against tech
Hugs, Rui
On Tue, Aug 12, 2003 at 09:21:32PM +0100, João Miguel Neves wrote:
A Ter, 2003-08-12 às 20:54, Niall Douglas escreveu:
My own opinion is given recent historical judgements by US courts with regard to similar issues, it does not bode well. The fact the GPL has the sweeping power it does it because it can be interpreted in so many ways ie; it's not been fixed.
I couldn't disagree more with you on this. The force of the GPL and the reason why no company so far, after hundreds of GPL violations, dared to go to court against the GPL is because there aren't much doubts about its meaning.
Legally the GNU GPL is a well examined license due to its wide use over that long period. So I completely agree with João here, the GNU GPL ist clear and legally very effective.
If you want to understand how much work has gone into getting the GPL to this point read the "Enforcing the GPL" series in http://emoglen.law.columbia.edu/
On Tue, 2003-08-12 at 15:26, Bernhard Reiter wrote:
[ I'm also crossposting this to the fsfeurope discussion list as many points are quite general to Free Software licensing. ]
And I'm replying only on the FSFE mailinglist :)
On Tue, Aug 12, 2003 at 03:07:17PM +0200, Radim Blazek wrote as answer to a post On Monday 11 August 2003 09:11 by Jan-Oliver Wagner:
Here are some LGPL disadvantages: (by application I mean any application using LGPL library)
- Staticaly linked application must be probably distributed also as source code.
So what? It's their choice to use this code. They could buy that much more expensive license from somebody else and make statically built versions (thus these ones could be more expensive).
Yes, I say 'probably', because LGPL is not very clear, and I found on the Web two kinds of explanations for article 6. a), one states that object code is enough, the second that source code is required. Also "permit modification of the work for the customer's own use" imposes distribution of source code, but that would apply to dynamicaly linked application as well.
In the case of the Lesser GPL, what must be kept Free is the software part licensed under the GNU Lesser GPL. The applications that use it can be covered by other licenses, most will give their user less Freedom... a pity for them.
- The application cannot use any third party libraries or tools needed to build the application which are not standard part of OS and cannot be distributed with the application. For example library which can read proprietary data format, available for download on Web, but without permission to redistribute it. On Windows, compiler like "Visual C" is also such tool. This is of course valid regardless the application is proprietary or free!
But you don't have a license to redistribute Microsoft Visual C, for instance, do you? And people _are_ required by law to have a legally authorised copy of Microsoft Visual C, should they want to use it for any reason, so how can a library continue to be Free Software if it depends on a non-Free third party executable? That would kind of destroy the purpose, now wouldn't it?
- "You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change." this does not block the use, but it is annoying and extra work.
Well, imagine developer D from company C writes some code W on software S by date T.
Doing that, you know that on T, D wrote W for S on the behalf of C.
Now imagine that someday you are sued because of copyright violation over W. You can pinpoint exactly who did it (D), when he did it (T) and what he did (W on S).
You can now proceed to removal of W and whipping D until he makes some real W' of his own.
Imagine you never did such a thing... who do you have to pass blame on?
If I look around, successful open source GIS projects don't use (L)GPL: GDAL/OGR: MIT/X License Mapserver: MapServer License (almost MIT/X) PROJ4: MIT/X License
What's the definition of success here?
A successful drug dealer surely uses guns, but by holding a gun will I be a successful drug dealer? I'd most likely end up shooting myself in the foot.
Finally, I've found no evidence at all that L(GPL) harms the practical aspects of software. It only protects the freedom - thus if you mean that the license harms your practice to derive proprietary products from Free Software then of course you are right.
The problem is that it complicates/disables the use of the LGPL library for both free and proprietary programs.
Of course it adds complexity to linking with the Lesser GPL covered library. That's an intentional purpose to prevent copyright violation (making non-Free libraries), while allowing the use of the library.
But in that case your anyway not interested in the ideas and values of Freedom and Free Software.
I am interested in free software when it is feasible and sensible.
I thought sensibility and feasibility are independent qualities that a person can have.
If the developers are capable, the software will be feasible. If the developers are sensible, the software will be sensible.
If the developers care for the Freedom of all the users of the software they wrote, they will most likely use a Free Software license that will enforce the continuity of that freedom.
I am not interested to force people to do what FSF considers to be the best.
No one forces anyone to do anything.
I'm sure a lot of people don't care about the software license of the software they use because they don't give a rat's ass to copyright (which is an artificial government granted monopoly right), that's why you have a "rampaging piracy". It's not that in some countries 90% (or more) of the people are evil and rich black bearded pirates with patch-eyes that think of nothing else than not giving more money to the starving poor developers that must eat.
It's only that it just isn't natural to not share.
On 13 Aug 2003 at 11:48, Rui Miguel Seabra wrote:
I'm sure a lot of people don't care about the software license of the software they use because they don't give a rat's ass to copyright (which is an artificial government granted monopoly right), that's why you have a "rampaging piracy". It's not that in some countries 90% (or more) of the people are evil and rich black bearded pirates with patch-eyes that think of nothing else than not giving more money to the starving poor developers that must eat.
Actually, I think it's self-evident to anyone half intelligent that technology has made existing IP law for anything wholly representable inside a computer obsolete.
That means all those file-sharers are not the ones robbing the authors of their cash. It is in fact the fault of the governments for not establishing adequate regulation to ensure the survival of their industry.
It's only that it just isn't natural to not share.
I'm afraid that's bunk. Those who hoard are those who survive and those willing to cut down their neighbour to steal their food also have an advantage in simple situations. The entire current western europe derived world empire is based on invading other countries, subjecting them forcibly to our rule and getting them to work for our benefit. Studies show that that exploitation has increased year-on- year for the last two hundred years - why else has food production & available capital exceeded world population growth worldwide and yet with each year a greater percentage of humankind slips in poverty and hunger?
However, we /can/ learn to behave differently and slowly, I think we are. But you can't claim it's natural to share - it isn't outside your family unit.
Cheers, Niall
El Wed, Aug 13, 2003 at 07:22:07PM +0100, Niall Douglas deia:
It's only that it just isn't natural to not share.
I'm afraid that's bunk. Those who hoard are those who survive and those willing to cut down their neighbour to steal their food also have an advantage in simple situations. The entire current western europe derived world empire is based on invading other countries, subjecting them forcibly to our rule and getting them to work for our benefit. Studies show that that exploitation has increased year-on- year for the last two hundred years - why else has food production & available capital exceeded world population growth worldwide and yet with each year a greater percentage of humankind slips in poverty and hunger?
However, we /can/ learn to behave differently and slowly, I think we are. But you can't claim it's natural to share - it isn't outside your family unit.
IMHO sharing food has nothing to do with sharing knowledge.
Only one person can eat one thing, but you don't lose knowledge by sharing it. This does not mean you want you necessarily want to share all the knowledge you have, but any comparison with material goods is misleading.
On 13 Aug 2003 at 23:31, Xavi Drudis Ferran wrote:
However, we /can/ learn to behave differently and slowly, I think we are. But you can't claim it's natural to share - it isn't outside your family unit.
IMHO sharing food has nothing to do with sharing knowledge.
They are closer than you think.
Only one person can eat one thing, but you don't lose knowledge by sharing it. This does not mean you want you necessarily want to share all the knowledge you have, but any comparison with material goods is misleading.
You don't lose the knowledge itself, but you /do/ lose the advantage gained by you knowing it and no one else. That's what patents in general are about, company secrets, government intelligence services and indeed all schools in the western educational paradigm (see "Deschooling society" by Ivan Illich).
If you look at the first actions the British empire took after conquering India, they destroyed the schools, factories and anything which could compete with English industry. In two generations, India had been set back at least a hundred years. This kept them under the imperial yoke until the British sent a really stupid governor over there and prevented the India tea company from doing what it did, and it was only this idiocy that caused the rise of nationalism.
If you take this still further, there is an alarming tendency in British and American companies to try and prevent their employees learning new tricks in case they might up and leave for a better job. I have seen it so many times it hurts, because really they are damaging the common pool of national employees. Then they have the gall to complain about skills shortages and want to import third world labour who can't complain, switch job or do anything but work for peanuts for fear of losing their work visa. This of course means all the locals become unemployed and suck the country dry by being unproductive!
Welcome to the modern working world!
Cheers, Niall
On Thu, 2003-08-14 at 00:54, Niall Douglas wrote:
On 13 Aug 2003 at 23:31, Xavi Drudis Ferran wrote:
However, we /can/ learn to behave differently and slowly, I think we are. But you can't claim it's natural to share - it isn't outside your family unit.
IMHO sharing food has nothing to do with sharing knowledge.
They are closer than you think.
Actually Niall,
If I share a bread with you, we may have, roughly, half a bread each.
By reading this message, we're sharing all it's contents with all other subscribers (plus people that read archives).
None of us got it in part unless we have some communication problem (from network problems to very common PBCAKs).
Rui