Yes, that's true, and a good thing. What I meant was, I knew a person who believed that a program running on an OS, by virtue of "linking" with the kernel via the syscall mechanism, was therefore derived from the OS, the same way loading a dynamic library derives from it. He was trying to show that all commercial Linux apps were on shaky legal ground. (He didn't think that Linus's comment disclaiming this at the top of COPYING was part of the license, either.) I managed to set him straight by pointing out that Windows programs "link" with the kernel also, and nobody seriously believes MS can sue everyone for copyright infringement based only on that.
My point is that in software, the definition of a derivative work is both completely undefined (no precedent) and in my opinion, way to broad. Yes, there's technical differences, but what is the real difference between being loaded by a kernel (either as a program or a module), loading a library, and running an executable? I think none of them should be considered making a derivative work.
Derivatives and the Law
on
My Visit to SCO
·
· Score: 3, Insightful
Something good will come out of this case. SCO will not win, that's given, but to fight them, IBM will have to present a much narrower definition of what it means to derive from software. When IBM wins, it could set precedent, which I think would be a good thing.
Right now, loading a dynamic library (but probably not loading an executable), and perhaps running on an OS (unless the licence allows this, as Linux's does), and statically linking, may all constitute creating a derivative work (IANAL). This uncertainty is a bad thing, and I think it would be better if the only way you could make a derivative work would by making a work that includes the original source code, not object code, output, etc.
Suppose IBM added something (b) to SCO's code(a), and SCO has a contract that they own derivative works (a+x). I think SCO then owns the derivative work (a+b), but if IBM wants to put it's code (b) in something else (c), SCO certainly doesn't own (c+b), because they had no part in it's creation, and (a) is not a part of it. Code can't be a derivative unless it includes what it derives from (in original or translated form).
I know how to solve this.
on
My Visit to SCO
·
· Score: 3, Funny
What we need is an Office of Common Sense. I propose that instead of us Slashdotters wasting our political might on many seperate issues, we concentrate on getting an ammendment to the Constitution giving Congress the power "To unleash a great big Can of Whoop-Ass upon any Company, Individual, Congressperson, or other Entity not acting in accordance with the Principles of Common Sense, as determined by a Slashdot poll;"
Then all the problems would be solved. RIAA getting you down? Whap! Don't like SCO? Splat! Microsoft is unfair? ...Bwannng! Think CowboyNeal should be president? Biff! (Yes, the OCS would always make a comical noise when it acts.)
Yeah, that's obviously the solution if you're trying to determine whether copying has occured. But if you're convinced that it has, you can abuse it very easily.
About halfway through my rant, I found the Register article I linked to, and yes, what I suggest is similar to what they're doing. They seem to think of it as an intermediate step, though, while I think it's as far as it should go. If they go farther, they're just upsetting things with no gain. MS is making too big a deal about this (not unexpected).
That said, I think Linux, BSD, etc. are in a better position than Windows to implement this transparently. We can use already existing software to modify the updater daemon when files change, but we can present the queries in a much better manner. LUFS and FUSE lend themselves perfectly to a filesystem where mkdir your query, and the directory is populated with symlinks to the results. "cd/query/?contain=copyright%20sco?location=/usr/src/ linux; ls" You only need one mount, queries would be cached, the query could have an xml index file giving extra data, and each file within the query would have a path that could be given to programs. Writing to the files would work as expected. I can't wait for someone with database expertise to make this into a reality, because it isn't actually technically difficult.
The problem, of course, is determing how much is similarity is infringing. For instance, how many times do you suppose for(v=0;vv;++v)v(v,v); or if(v|v==v)v+=v; occur? If SCO were able to choose a method, and publish the fingerprint, they'd be sure to choose a method that would have 20% of the kernel infringing, and that's assuming they're honest. It's too easy to abuse that.
FS is finally able to use it's relational roots to distribute filesystems over multiple processors in an cluster or over a network. Such a system would support atomic, distributed file updates by threads of processes on differing processors (including HyperThreaded procs). Imagine a virtual filesystem that can span your whole-house network, with a single file system image
Most of what we say is guessing, because we don't know the question MS is trying to answer. I can't think of any goals best met by WinFS.
A directory tree is a very useful structure, at least to the software. Similar stuff is grouped together, and easily cached. It provides a very clean and simple way of putting data somewhere and getting it back later. This should not lightly cast aside.
So, you want to use a relational database to keep track of files? Go for it, but instead of keeping track of the files themselves, keep track of their paths. Let the filesystem do the efficient storage, and the database do the efficient lookups. The database can be made faster and smaller, the filesystems can remain as fast as they are, and the files are still there even if the database gets corrupted.
Put hooks wherever necessary to update the database when the filesystem changes. For example, put a database in the root of each filesystem. Use a stacked mount to mount that disk, so when interesting things happen, the kernel tells a userspace process that updates the database.
Then, make some standard libraries that use the database. Make file browsers that can query it, but pass the path to programs. Make save dialogs that can also save metadata about the file, and open dialogs that can search for it. Use LUFS or FUSE to make directories that correspond to queries.
This is just as effective as what MS is doing, but it's more efficient, it's more compatible, and it doesn't reinvent the wheel.
Most of the problems with this rule would go away if the law stated that links are the only necessity. In other words, if you want to reply, it's your responsibility to host it, and the offending site must only post a link. This would quell fears of offensive Slashdotting, and it makes more sense anyway.
Can you remember 5 lines of code?
on
Settling SCOres
·
· Score: 3, Insightful
I wonder if this guy, or anyone else who's seen the code, can remember any of it. If it were me, I'd wait until I saw the big function, commit to memory 5 lines of it, and as soon as I got home, I'd have grepped the source for it. I couldn't legally tell anyone else what code it was, but in about 5 minutes I could determine whether or not SCO was full of shit.
Once I'd found the real author of the code, I'd notify him, and watch the fun as he tries to sign the NDA. It'd get real entertaining real fast.
So last night I decided to try Gentoo for the heck of it. So here I sit, reading Slashdot with Lynx while my system builds on the other console, and I read about the new kernel! I should have waited another day or so. I suppose it is Friday 13.
The quick solution is.bz2.tar, but even that can be improved upon, and still uphold the unix way. I want something similar to tar, except the info about which files it contains should be stored in the beginning (so you can tell what's in partially downloaded files). This header would also store metadata including how each file is compressed. Basically, bzip2 * && mytar *. You do lose efficiency on small, similar files, though.
I wholeheartedly agree. (I thought of it first:-) ). It should be a Wiki. The most important thing, if you want to use this to stop insane patents, is to have some trusted third party keep backups, so you can prove in court when what was submitted.
That's a good idea, but every compiler is different. You'd have to somehow compile the code (it would need to be revealed first) on SCO's compiler with their options. I suppose it might be possible, but it'd be very difficult.
Obviously that doesn't apply to the contested code, but the GPL on the other 99.9% of the kernel is valid.
Suppose SCO decided anyone using their snippets owes them $.01 per year. The instant they do that, it is no longer legal to distribute the tainted kernel, because you can't legally do it without placing further restrictions on the recipients.
At this point, the code would be known. (If not, every commercial entity with an interest in Linux would sue SCO to discover which 80 lines they aren't allowed to redistribute.), and it would be rewritten. SCO might be able to sue users of the old code, but they could just upgrade. I think the only danger to Linux (not that I'm downplaying it) is the FUD.
Congratulations, you win the stuffed Tux! The original quote is:
"While I cannot take the time to name all of the men in the State Department who have been named as members of the Communist Party and members of a spy ring, I have here in my hand a list of 205 that were known to the Secretary of State as being members of the Communist Party and who, nevertheless, are still working and shaping the policy in the State Department"
IANAL, but I don't believe the GPL allows you to do that. The entire kernel (except perhaps this code) is GPL, and nobody can distribute it unless they give the recipients the GPL rights, including redistribution for no more than a nominal charge for the media.
McBride: "While I cannot take the time to specify my claim, I have here in my
hand a list of eighty lines of code that were known to Linus
Torvalds as belonging to SCO, and which, nevertheless, are still transforming
Linux from a bicycle to a luxury car."
Slashdot Mirror
the freedom is for the users to not owe you a damned thing in return. Well, they do owe you what they build on top of your work, but that's it.
Sculpting is the same way. You just take a block of marble, and remove all parts that don't look like an elephant.
My point is that in software, the definition of a derivative work is both completely undefined (no precedent) and in my opinion, way to broad. Yes, there's technical differences, but what is the real difference between being loaded by a kernel (either as a program or a module), loading a library, and running an executable? I think none of them should be considered making a derivative work.
Right now, loading a dynamic library (but probably not loading an executable), and perhaps running on an OS (unless the licence allows this, as Linux's does), and statically linking, may all constitute creating a derivative work (IANAL). This uncertainty is a bad thing, and I think it would be better if the only way you could make a derivative work would by making a work that includes the original source code, not object code, output, etc.
Suppose IBM added something (b) to SCO's code(a), and SCO has a contract that they own derivative works (a+x). I think SCO then owns the derivative work (a+b), but if IBM wants to put it's code (b) in something else (c), SCO certainly doesn't own (c+b), because they had no part in it's creation, and (a) is not a part of it. Code can't be a derivative unless it includes what it derives from (in original or translated form).
Then all the problems would be solved. RIAA getting you down? Whap! Don't like SCO? Splat! Microsoft is unfair? ...Bwannng! Think CowboyNeal should be president? Biff! (Yes, the OCS would always make a comical noise when it acts.)
Yeah, that's obviously the solution if you're trying to determine whether copying has occured. But if you're convinced that it has, you can abuse it very easily.
That said, I think Linux, BSD, etc. are in a better position than Windows to implement this transparently. We can use already existing software to modify the updater daemon when files change, but we can present the queries in a much better manner. LUFS and FUSE lend themselves perfectly to a filesystem where mkdir your query, and the directory is populated with symlinks to the results. "cd /query/?contain=copyright%20sco?location=/usr/src/ linux; ls" You only need one mount, queries would be cached, the query could have an xml index file giving extra data, and each file within the query would have a path that could be given to programs. Writing to the files would work as expected. I can't wait for someone with database expertise to make this into a reality, because it isn't actually technically difficult.
The problem, of course, is determing how much is similarity is infringing. For instance, how many times do you suppose for(v=0;vv;++v)v(v,v); or if(v|v==v)v+=v; occur? If SCO were able to choose a method, and publish the fingerprint, they'd be sure to choose a method that would have 20% of the kernel infringing, and that's assuming they're honest. It's too easy to abuse that.
Oh, you mean like the Parallel Virtual File System, right?
Oh, sorry.
A directory tree is a very useful structure, at least to the software. Similar stuff is grouped together, and easily cached. It provides a very clean and simple way of putting data somewhere and getting it back later. This should not lightly cast aside.
So, you want to use a relational database to keep track of files? Go for it, but instead of keeping track of the files themselves, keep track of their paths. Let the filesystem do the efficient storage, and the database do the efficient lookups. The database can be made faster and smaller, the filesystems can remain as fast as they are, and the files are still there even if the database gets corrupted.
Put hooks wherever necessary to update the database when the filesystem changes. For example, put a database in the root of each filesystem. Use a stacked mount to mount that disk, so when interesting things happen, the kernel tells a userspace process that updates the database. Then, make some standard libraries that use the database. Make file browsers that can query it, but pass the path to programs. Make save dialogs that can also save metadata about the file, and open dialogs that can search for it. Use LUFS or FUSE to make directories that correspond to queries.
This is just as effective as what MS is doing, but it's more efficient, it's more compatible, and it doesn't reinvent the wheel.
All your AIX are belong to us!
NO CARRIER
Most of the problems with this rule would go away if the law stated that links are the only necessity. In other words, if you want to reply, it's your responsibility to host it, and the offending site must only post a link. This would quell fears of offensive Slashdotting, and it makes more sense anyway.
Once I'd found the real author of the code, I'd notify him, and watch the fun as he tries to sign the NDA. It'd get real entertaining real fast.
(Yes, I know how easy it will be to upgrade.)
... you insensitive clod!
The quick solution is .bz2.tar, but even that can be improved upon, and still uphold the unix way. I want something similar to tar, except the info about which files it contains should be stored in the beginning (so you can tell what's in partially downloaded files). This header would also store metadata including how each file is compressed. Basically, bzip2 * && mytar *. You do lose efficiency on small, similar files, though.
I wholeheartedly agree. (I thought of it first :-) ). It should be a Wiki. The most important thing, if you want to use this to stop insane patents, is to have some trusted third party keep backups, so you can prove in court when what was submitted.
That's a good idea, but every compiler is different. You'd have to somehow compile the code (it would need to be revealed first) on SCO's compiler with their options. I suppose it might be possible, but it'd be very difficult.
If you haven't paid for your own licence, the legality of LAME in the Land of the Free is questionable, at best.
Suppose SCO decided anyone using their snippets owes them $.01 per year. The instant they do that, it is no longer legal to distribute the tainted kernel, because you can't legally do it without placing further restrictions on the recipients.
At this point, the code would be known. (If not, every commercial entity with an interest in Linux would sue SCO to discover which 80 lines they aren't allowed to redistribute.), and it would be rewritten. SCO might be able to sue users of the old code, but they could just upgrade. I think the only danger to Linux (not that I'm downplaying it) is the FUD.
IANAL, but I don't believe the GPL allows you to do that. The entire kernel (except perhaps this code) is GPL, and nobody can distribute it unless they give the recipients the GPL rights, including redistribution for no more than a nominal charge for the media.
McBride: "While I cannot take the time to specify my claim, I have here in my hand a list of eighty lines of code that were known to Linus Torvalds as belonging to SCO, and which, nevertheless, are still transforming Linux from a bicycle to a luxury car."
Hmm... Anonymous Coward == AC == Alan Cox. Suddenly it all makes sense!