It might be that Toybox is derivative of Busybox. Parts of Toybox were written for Busybox, and presumably are derivative of other parts of Busybox. They were then removed from Busybox and put in Toybox, which does the same thing, just without other parts of Busybox.
But the really nasty part of all of this is that Toybox's only purpose is to allow the GPL on the kernel to be infringed with impunity, because kernel developers currently aren't cooperating with SFC.
Does anyone want to sell their copyright on existing kernel code? I'd throw you a few bucks to contribute it to SFC.
The court would probably decide based on testimony of experts on both sides. See my JMRI testimony for an example of how Open Source licenses are explained to judges. In the case of Fyodor's addition, it would be both lawyers and experts on the defense side citing cases that go against Fyodor's interpretation. Some of those cases would be precedential to the court hearing the case, meaning that the court would be required to align itself with the previous opinion unless the judge can produce an explanation of why the opinion in the preveious case does not apply to the present one.
, if you bundled Emacs together with my text as a single package, then I can't see why it can't be a derivative work of both my text and Emacs.
I am afraid this might just be a matter of expertise.
If I included your text in the Emacs source code, as some sort of template, you'd have reason to believe that I was creating a derivative work. However, I also have distributed Emacs on a Debian distribution (I created some of the early Debian distribution masters) along with thousands of texts and programs. I did this free of even the hint of legal challenge that programs aggregated together were derivative of each other.
That Debian CD was self-booting, self-extracting, really very similar to the Windows installer being discussed. If I tried to testify that the Windows installer was derivative, a canny defense expert would cue the lawyer to cross-examine me about that Debian CD, and she'd be right, it would discredit my (theoretical) testimony.
The problem with the redefinition of derivative work isn't that there's no contract, it's that legal professionals already know what derivative works are, and would prove in court, easily, that what Fyodor thinks is derivative actually isn't. Fyodor would have to state it differently than he has to make this stick.
No, I am not admitted to the bar, but a good deal of my income comes from working on Open Source issues with attorneys, and I teach attorneys, with CLE credit awarded in some states, about Open Source legal issues. I am an expert witness on just the sort of issue that is being discussed.
"Aggregation" is the word we use for the combination of software items on a medium that are not derivative works of the other software. It doesn't really make sense to say "that aggregation is a derivative work", if it were derivative it would not be an aggregation.
I am just not coming up with a theory that would make the installer a derivative work of the payload. The installer package is a medium from which the payload can be extracted and becomes separate files, identical to their form before being archived, that is the function of the installer. The installer copies the and stores data the way that Emacs copies and stores the text that you type while it runs. Yet, nobody attempts to make the case that Emacs is a derivative work of your text, that would be absurd, even if the text, by itself, is highly protected and very valuable. Nor do we find people claiming that GCC is a derivative work of the software they compile.
If I was called on to testify, that's what I'd say.
Oh, biddy kid is in a bad mood. Biddy kid should know I don't have anything to do with testing nmap. But tonight biddy kid is upset because he got in trouble with his mommy. So, he's taking all of his anger to Slashdot! I'll get that Bruce Perens for what my mommy did to me!
The license, however, doesn't prohibit you from distributing the software as part of a commercial installation package. Instead, a little note off to the side of the license says that they consider a commercial installation package to be a derivative work. So, that sets the question for the judge: was the commercial installation package a derivative work? All that the judge knows of law and case law says "no".
This is why I referred to those terms as being written "in crayon". The author doesn't seem to have understood what would happen when a judge attempted to parse the information. It doesn't seem to be the work of a legal professional. And it has the effect of deceiving programmers on the project that it is a valid license term, while legal professionals would immediately know that it isn't.
Poorly-written licenses always have this effect of deceiving the programmers who work on the project. This has cost some people real money, Bob Jacobsen (JMRI) being one. His case ended up being terribly more complicated than it should have been, costing years of hardship and some money.
I think if you want it to work that way, you need to write a new, and non-Open-Source, license. The way it's stated now, as a definition of derivative works rather than a term of distribution, doesn't work.
Now, ethically, people should do what you want. But the letter of the law would not require them to do so.
Click "I Agree" where? On the CNET site? Show me the page, please.
I have NMap on my Debian system, and I never had to click "I Agree" to get it or anything else in Debian.
Yes, it's a repulsive act
that CNet did, no argument with that. But why are people getting software from Download.com? What mistakes does our community make that lead to that?
It's not a contract. No proper consent, etc. It's a license. It unilaterally conveys rights without removing any rights you already have. This is what RMS intended with GPL2 and he'd testify to that effect. It wouldn't look so good to a jury as you think.
Can you make a credible case that the conflation of the CNET name confuses the public regarding the origin of the NMap software? It sounds a bit thin to me.
Fyodor should not be clicking YES on anything when uploading his own software. Really bad legal practice.
I think CNet learned their lesson.
Be wary of blocking legitimate sites that you don't approve of. I have not heard of ECPA being used against spam blockers and site blockers, but I think it could be used that way.
Sorry, but when Fyodor crosses out some of the GPL terms and writes in new ones in crayon (meaning without the assistance of a lawyer or in a manner contrary to existing law), it doesn't really have the effect he desires.
The GPL explicitly does not define terms such as "derivative work" because these terms are defined in copyright law or case law. Case law is most important here, and in general case law is strongly against Fyodor's interpretation. Go read Judge Walker's finding in CAI v. Altai and tell me that just installing the software makes it a derivative work.
I am also dubious that anything in 18 U.S.C. 1030 (the Computer Fraud and Abuse Act) can really be used to prosecute this particular incident. Can you show me the words that you think would?
I see what you mean, the line that says "Integrates/includes/aggregates Nmap into a proprietary executable installer, such as those produced by InstallShield."
It's nice to know what they consider a derivative work, but it has no legal effect. That would not be a derivative work under copyright law no matter what they think.
It is entirely within the license terms of any OSI-approved Open Source license to aggregate any software, regardless of its nature, on the same medium as Open Source software and to install it with the same installer that installs the Open Source. Even software that is harmful. Only if the software is a derivative work of the Open Source will the license apply to it.
Sure, CNet shouldn't do this, and if they keep doing it we'll eventually start using new licenses that make them copyright infringers. But right now it's legal.
Re:EPUB should be your e-book format of choice.
on
Open Hardware Journal
·
· Score: 1
P.S. How come you didn't have an article focussing on Arduino in your initial issue??
1) What is your personal take on necessity for open source DA tools where possible?
I think we are in the equivalent to the period when RMS was writing GNU C on a Sun Microsystems workstation. We need fully Open Source toolchains. Currently, we don't have them for gate-arrays. And we have a large number of people who prefer Eagle over the various Open Source alternatives, which probably means the Open Source ones aren't good enough yet. And those folks haven't really understood the draconian Eagle license.
So, I hope to motivate people to do more work on tools.
2) What is the Open Hardware Journal's policy?
We will be editorializing on the need for people to work on tools, but not locking out projects that use proprietary tools from publication at this time. One of the issues is to lobby the manufacturers to document their devices sufficiently so that we really can have Open tools for them rather than creating our own devices. But create them we will, if necessary.
3) Is there any hope of seeing a "recursively open artifact" license for open hardware projects? (That is: a license where the design is open, the design file formats are openly documented, and at least one open source tool exists for every step in the tool chain.)
You can make some artifacts with a fully open tool-chain now. Nobody's crafted an "Open Tools Only in Derivative Works" license yet. I don't think it is time for one yet, but the time might come.
Of course the entire purpose of this is Open designs without royalties, as is amply explained on the site, in the Journal, etc. It would be nice if you and I, rather than big companies, really could reuse designs with impunity. But they stop us with their patents. Just as GPL turns copyright on its head, we need to do the same for hardware. But in hardware designs, copyright is not the main enemy - it's patents, trade secret, DMCA.
Slashdot Mirror
But the really nasty part of all of this is that Toybox's only purpose is to allow the GPL on the kernel to be infringed with impunity, because kernel developers currently aren't cooperating with SFC.
Does anyone want to sell their copyright on existing kernel code? I'd throw you a few bucks to contribute it to SFC.
That's thinking in Earth terms. This thing was in hard vacuum for more than a year.
I had a motherboard that provided a ROM flash program as a DOS application. FreeDOS ran it.
But I can't say I want one now. I gave them money so they'd stay free. They didn't stay free.
The court would probably decide based on testimony of experts on both sides. See my JMRI testimony for an example of how Open Source licenses are explained to judges. In the case of Fyodor's addition, it would be both lawyers and experts on the defense side citing cases that go against Fyodor's interpretation. Some of those cases would be precedential to the court hearing the case, meaning that the court would be required to align itself with the previous opinion unless the judge can produce an explanation of why the opinion in the preveious case does not apply to the present one.
I am afraid this might just be a matter of expertise.
If I included your text in the Emacs source code, as some sort of template, you'd have reason to believe that I was creating a derivative work. However, I also have distributed Emacs on a Debian distribution (I created some of the early Debian distribution masters) along with thousands of texts and programs. I did this free of even the hint of legal challenge that programs aggregated together were derivative of each other .
That Debian CD was self-booting, self-extracting, really very similar to the Windows installer being discussed. If I tried to testify that the Windows installer was derivative, a canny defense expert would cue the lawyer to cross-examine me about that Debian CD, and she'd be right, it would discredit my (theoretical) testimony.
The problem with the redefinition of derivative work isn't that there's no contract, it's that legal professionals already know what derivative works are, and would prove in court, easily, that what Fyodor thinks is derivative actually isn't. Fyodor would have to state it differently than he has to make this stick.
You're smoking too much of that hydroponic crap to think straight, troll. I'm not going to feed you any longer. Doobie doobie do
No, I am not admitted to the bar, but a good deal of my income comes from working on Open Source issues with attorneys, and I teach attorneys, with CLE credit awarded in some states, about Open Source legal issues. I am an expert witness on just the sort of issue that is being discussed.
"Aggregation" is the word we use for the combination of software items on a medium that are not derivative works of the other software. It doesn't really make sense to say "that aggregation is a derivative work", if it were derivative it would not be an aggregation.
I am just not coming up with a theory that would make the installer a derivative work of the payload. The installer package is a medium from which the payload can be extracted and becomes separate files, identical to their form before being archived, that is the function of the installer. The installer copies the and stores data the way that Emacs copies and stores the text that you type while it runs. Yet, nobody attempts to make the case that Emacs is a derivative work of your text, that would be absurd, even if the text, by itself, is highly protected and very valuable. Nor do we find people claiming that GCC is a derivative work of the software they compile.
If I was called on to testify, that's what I'd say.
Oh, biddy kid is in a bad mood. Biddy kid should know I don't have anything to do with testing nmap. But tonight biddy kid is upset because he got in trouble with his mommy. So, he's taking all of his anger to Slashdot! I'll get that Bruce Perens for what my mommy did to me!
I've not a windows system to try the nmap installer. Didn't figure that out, did you?
This is why I referred to those terms as being written "in crayon". The author doesn't seem to have understood what would happen when a judge attempted to parse the information. It doesn't seem to be the work of a legal professional. And it has the effect of deceiving programmers on the project that it is a valid license term, while legal professionals would immediately know that it isn't.
Poorly-written licenses always have this effect of deceiving the programmers who work on the project. This has cost some people real money, Bob Jacobsen (JMRI) being one. His case ended up being terribly more complicated than it should have been, costing years of hardship and some money.
"Intentionally deceptive means" is the key. Do we have screen shots, etc., that make a case that it was intentionally deceptive?
Now, ethically, people should do what you want. But the letter of the law would not require them to do so.
I have NMap on my Debian system, and I never had to click "I Agree" to get it or anything else in Debian.
Yes, it's a repulsive act that CNet did, no argument with that. But why are people getting software from Download.com? What mistakes does our community make that lead to that?
It's not a contract. No proper consent, etc. It's a license. It unilaterally conveys rights without removing any rights you already have. This is what RMS intended with GPL2 and he'd testify to that effect. It wouldn't look so good to a jury as you think.
Can you make a credible case that the conflation of the CNET name confuses the public regarding the origin of the NMap software? It sounds a bit thin to me.
I think CNet learned their lesson.
Be wary of blocking legitimate sites that you don't approve of. I have not heard of ECPA being used against spam blockers and site blockers, but I think it could be used that way.
Sorry, but when Fyodor crosses out some of the GPL terms and writes in new ones in crayon (meaning without the assistance of a lawyer or in a manner contrary to existing law), it doesn't really have the effect he desires.
The GPL explicitly does not define terms such as "derivative work" because these terms are defined in copyright law or case law. Case law is most important here, and in general case law is strongly against Fyodor's interpretation. Go read Judge Walker's finding in CAI v. Altai and tell me that just installing the software makes it a derivative work.
I am also dubious that anything in 18 U.S.C. 1030 (the Computer Fraud and Abuse Act) can really be used to prosecute this particular incident. Can you show me the words that you think would?
I see what you mean, the line that says "Integrates/includes/aggregates Nmap into a proprietary executable installer, such as those produced by InstallShield."
It's nice to know what they consider a derivative work, but it has no legal effect. That would not be a derivative work under copyright law no matter what they think.
Over at nmap.org, there's a GPL license. See this. They also offer a commercial license.
It is entirely within the license terms of any OSI-approved Open Source license to aggregate any software, regardless of its nature, on the same medium as Open Source software and to install it with the same installer that installs the Open Source. Even software that is harmful. Only if the software is a derivative work of the Open Source will the license apply to it.
Sure, CNet shouldn't do this, and if they keep doing it we'll eventually start using new licenses that make them copyright infringers. But right now it's legal.
Nobody offered to write one.
I'm going to try the LibreOffice plugin.
Thanks
Bruce
Sure!
I think we are in the equivalent to the period when RMS was writing GNU C on a Sun Microsystems workstation. We need fully Open Source toolchains. Currently, we don't have them for gate-arrays. And we have a large number of people who prefer Eagle over the various Open Source alternatives, which probably means the Open Source ones aren't good enough yet. And those folks haven't really understood the draconian Eagle license.
So, I hope to motivate people to do more work on tools.
We will be editorializing on the need for people to work on tools, but not locking out projects that use proprietary tools from publication at this time. One of the issues is to lobby the manufacturers to document their devices sufficiently so that we really can have Open tools for them rather than creating our own devices. But create them we will, if necessary.
You can make some artifacts with a fully open tool-chain now. Nobody's crafted an "Open Tools Only in Derivative Works" license yet. I don't think it is time for one yet, but the time might come.
Of course the entire purpose of this is Open designs without royalties, as is amply explained on the site, in the Journal, etc. It would be nice if you and I, rather than big companies, really could reuse designs with impunity. But they stop us with their patents. Just as GPL turns copyright on its head, we need to do the same for hardware. But in hardware designs, copyright is not the main enemy - it's patents, trade secret, DMCA.