The legalities over J++ had nothing to do with the Java API. It had to do with Microsoft creating their own, subtly incompatible, version of the JVM they had actually licensed. It then became a trademark argument as Microsoft wasn't using a compatible JVM that passed compliance tests. Microsoft and Sun then settled, so this was not a court ruling. J# still existed afterwards.
No. To take the present example, Google's Java API is clearly not interoperable with the original Java code.
Total and utter nonsense and this gets to the heart of the matter. I've no idea what you mean by the original Java code by the way and this is a pretty big clue that you don't have an argument here because you haven't been able to say why. There is nothing clearly about it and I'm afraid it really doesn't matter what adverbs you use for embellishment. I'm sure Oracle's lawyers will try using the same language in their arguments and why probably why they've had to come up with an additional claim.
Google's API means you could take existing Java code, recompile it to run on a Dalvik VM and have it run on an Android system Oracle didn't build. You could reverse the process. Using this nonsensical logic it would be illegal to take code written for Java and recompile it to run in a.Net VM or vice versa or in any of the countless compilers out there for C, C++ and other languages. This happens in countless development tools between various programming environments every day of the week. The parts of Google's API that aren't interoperable because Oracle doesn't have an implementation of them don't apply because they aren't part of the Java API as it is. If you're arguing that this is a problem then you've just argued that a programmer cannot implement their own classes, interfaces and API in general on top of an existing one or that look likes one. This is even more nonsensical than anything else and would destroy programming completely.
Either way, you have nothing to stand on here because you can't argue where interoperability doesn't apply. This is what happens when you get legal people making judgements on things they clearly haven't taken any effort to understand. We have been through this all before.
1) Re-read my earlier comment [slashdot.org], which explains why WINE has a fair-use defense.
It doesn't explain why WINE has a fair use defence at all. Define interoperability.
However you're looking at this the wrong way specifically because you can't provide an example as to why WINE doesn't have a fair use argument. By definition, any software that uses the same API does so for the purposes of interoperability. There is no other reason. Ditto Google. Developers could take existing Java code they were familiar with, recompile it and have it run in an environment that Oracle had absolutely nothing to do with and didn't build. All you end up doing is spending time in court arguing something that is already crystal clear - APIs can't be copyrighted - which I suspect might be the point.
Educate yourself.
Funny considering we've been over this very same ground in the 80s and 90s. These precedents have been set and we're just covering old ground.
No. I think you genuinely believe you have something to say here, but you simply don't.
1) Is a thing copyrightable? Does the author own the copyright? The answer is clearly (according to the Supreme Court) that APIs are copyrightable.
We've been round this set of houses before in the 80s and 90s with DR DOS and IBM and Phoenix BIOSes. Every time someone has tried to claim that APIs are copyrightable, and courts have agreed, the inevitable problems crop up. Hence:
2) Is there a fair use defense? This must be answered after question 1 is answered.
This makes absolutely no sense whatsoever. The very reason someone else uses the same API is, by definition, interoperability. At the very least It is done to allow the same code to be recompiled and for developer familiarity with the API. 1 simply becomes a nonsense when you understand this, but unfortunately that decision was made by people with no knowledge of the topic they made the ruling over nor the precedents set here before. If APIs were practically copyrightable then the fair use clause shouldn't even be necessary.
Unfortunately, yet again, legal people don't understand the difference between interfaces and software. It really isn't as if we haven't been here before and unfortunately we will go through the same thing all over again in this drawn out legal battle.
There is no issue here and you're getting the wrong end of the stick. The point here is this is a company who is firmly stuck in the 80s and early 90s and believes that no one is going to be able to do anything with their software as long as they enforce licensing agreements. They do also, despite her pathetic protestations to the contrary, believe they can keep security problems and ones yet to be discovered under control by using that method. Other software companies have had to learn very quickly how to manage this and Oracle has yet to do it.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.
That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.
You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?
kdbus is great technology, especially for the non-systemd distros.
Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.
Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pain over this thing until it has to be dumped. Just wait until the security holes start getting found as well (you can drive a coach and horses through docker), but that's a whole other can of worms.
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.
Ted Ts'o comments are fine but i don't get the "they don't listen" bit, if they didn't you wouldn't still be able to start your binaries with your current init scripts or have logs forwarded to syslog etc.
Because......that has nothing to do with systemd's benevolent and great leadership? Stuff works that has already worked......because it does.
Theodore is not the only kernel person to have issues with systemd, and in particular the kdbus component systemd proponents don't think should need questioned.
kdbus will never be put into the kernel. Those proposing it have been asked what they need to provide and they've done nothing but stall, hoping that the argument "Oh, it does this in userspace!" will suffice.
So an autopilot malfunction caused the plane to lose all contact with the outside world completely and fly in a corridor, in three dimensions at the right altitude, precisely where different air traffic controls would think it was each other's responsibility and allow it passage?
You think that if it gives you comfort. However, there is no getting away from the fact that this is the most alarming plane disappearance in history and even finding wreckage is unlikely to yield the answers required.
Seriously, WTF happened? Well Microsoft happened we all know that. The way forward was clear when the iPhone and then Android came about - either improve Symbian or move to Android. They could at least have been where Samsung is now as the de facto Android manufacturer and done a far better job.
The F-35 and especially the F-22 have a hopeless record at being able to stay airworthy for any length of time. They are always in maintenance for one problem or another. I'm not sure where you're getting your figures from, but for a plane that's been in development for well over two decades and where there is no sign whatsoever when it will be operationally ready you're hopelessly optimistic.
It's part of the same clusterfuck though, and for some reason the systemd people are convinced that kdbus is necessary to solve all of their problems......whatever they are.
Nope, I'm afraid they're holding off for an awful lot longer than that if kdbus isn't basically redesigned and criticisms are addressed. Greg simply doesn't get to decide this no matter how highly Linus rates him, and his reputation is taking a bit of a pounding with some of the bizarre messages he's been posting.
I bet they'll produce far more of them, and keeping their Suckhois in service that will be more than enough. You've also got to be able to keep a plane in the air, and the F-22 and F-35 has an incredibly poor record on that count.
Against a semi-credible enemy you always end up dogfighting. You can never assume that an enemy's radar and detection system won't get better, and when they do they simply upgrade them. To stay a head a stealth plane needs to be taken out of service and it's shape and materials changed.
Besides... the site has been photographed from orbit repeatedly since.
Nope, they haven't been photographed at all any detail at all. You would think NASA and people would be interested in having a look at how all the equipment on the moon is faring, and even find out where the actual coordinates of the damn things are, as opposed to looking at indistinct dots. But there you go. Maybe they just aren't bothered.
Slashdot Mirror
The legalities over J++ had nothing to do with the Java API. It had to do with Microsoft creating their own, subtly incompatible, version of the JVM they had actually licensed. It then became a trademark argument as Microsoft wasn't using a compatible JVM that passed compliance tests. Microsoft and Sun then settled, so this was not a court ruling. J# still existed afterwards.
It's not like we haven't been here before.
No. To take the present example, Google's Java API is clearly not interoperable with the original Java code.
Total and utter nonsense and this gets to the heart of the matter. I've no idea what you mean by the original Java code by the way and this is a pretty big clue that you don't have an argument here because you haven't been able to say why. There is nothing clearly about it and I'm afraid it really doesn't matter what adverbs you use for embellishment. I'm sure Oracle's lawyers will try using the same language in their arguments and why probably why they've had to come up with an additional claim.
.Net VM or vice versa or in any of the countless compilers out there for C, C++ and other languages. This happens in countless development tools between various programming environments every day of the week. The parts of Google's API that aren't interoperable because Oracle doesn't have an implementation of them don't apply because they aren't part of the Java API as it is. If you're arguing that this is a problem then you've just argued that a programmer cannot implement their own classes, interfaces and API in general on top of an existing one or that look likes one. This is even more nonsensical than anything else and would destroy programming completely.
Google's API means you could take existing Java code, recompile it to run on a Dalvik VM and have it run on an Android system Oracle didn't build. You could reverse the process. Using this nonsensical logic it would be illegal to take code written for Java and recompile it to run in a
Either way, you have nothing to stand on here because you can't argue where interoperability doesn't apply. This is what happens when you get legal people making judgements on things they clearly haven't taken any effort to understand. We have been through this all before.
1) Re-read my earlier comment [slashdot.org], which explains why WINE has a fair-use defense.
It doesn't explain why WINE has a fair use defence at all. Define interoperability.
However you're looking at this the wrong way specifically because you can't provide an example as to why WINE doesn't have a fair use argument. By definition, any software that uses the same API does so for the purposes of interoperability. There is no other reason. Ditto Google. Developers could take existing Java code they were familiar with, recompile it and have it run in an environment that Oracle had absolutely nothing to do with and didn't build. All you end up doing is spending time in court arguing something that is already crystal clear - APIs can't be copyrighted - which I suspect might be the point.
Educate yourself.
Funny considering we've been over this very same ground in the 80s and 90s. These precedents have been set and we're just covering old ground.
1) Is a thing copyrightable? Does the author own the copyright? The answer is clearly (according to the Supreme Court) that APIs are copyrightable.
We've been round this set of houses before in the 80s and 90s with DR DOS and IBM and Phoenix BIOSes. Every time someone has tried to claim that APIs are copyrightable, and courts have agreed, the inevitable problems crop up. Hence:
2) Is there a fair use defense? This must be answered after question 1 is answered.
This makes absolutely no sense whatsoever. The very reason someone else uses the same API is, by definition, interoperability. At the very least It is done to allow the same code to be recompiled and for developer familiarity with the API. 1 simply becomes a nonsense when you understand this, but unfortunately that decision was made by people with no knowledge of the topic they made the ruling over nor the precedents set here before. If APIs were practically copyrightable then the fair use clause shouldn't even be necessary.
Unfortunately, yet again, legal people don't understand the difference between interfaces and software. It really isn't as if we haven't been here before and unfortunately we will go through the same thing all over again in this drawn out legal battle.
In some cases it's fair use to re-implement an API, in some cases it's not.
Well that really cleared things up.
Most of it is just the usual LKML noise when something important is merged
No, it isn't.
There is no issue here and you're getting the wrong end of the stick. The point here is this is a company who is firmly stuck in the 80s and early 90s and believes that no one is going to be able to do anything with their software as long as they enforce licensing agreements. They do also, despite her pathetic protestations to the contrary, believe they can keep security problems and ones yet to be discovered under control by using that method. Other software companies have had to learn very quickly how to manage this and Oracle has yet to do it.
You are misinformed. The cgroups change has nothing to do with either dbus or kdbus, nor systemd.
That's Lennart speaking there. Claim everyone is misinformed when a raw nerve is touched. Lennart has clearly stated that he sees systemd as the one way of configuring cgroups in userspace and kdbus is the way that will effectively be locked in as the interface between kernel and userspace. Can't possibly have competing ways of doing this.
You will find that the change is backed by all kernel developers who thinks exactly the same as Tejun.
Bollocks. I find a lot of kernel developers who have issues with it though. See, easy this isn't it?
kdbus is great technology, especially for the non-systemd distros.
Kernel developers who have attempted to review the code have stated otherwise, and kdbus is simply not going to be merged until those concerns are addressed. What happens is things go silent, a patch is pushed to Linus with no changes and the mailing list thread kicks off again with the response "But it does this in userspace, so this is how it has to be and of course, putting it into the kernel will automatically make it go faster, because, you know, KERNEL!". There are a litany of huge issues with it too numerous to discuss here.
Using the Spinal Tap line of "But it goes all the way up to eleven" to any argument is all the systemd proponents have. It's quite sad that we're going to spend a great number of years of pain over this thing until it has to be dumped. Just wait until the security holes start getting found as well (you can drive a coach and horses through docker), but that's a whole other can of worms.
It is the cgroups maintainer Heo Tejun that wanted the change. Systemd has nothing to with it. Sure, systemd developer are working on a user side implementation of the new API, but that is it.
Alas, the net effect of it is that the single interface to it is through systemd and dbus, and Lennart claims in that passive aggressive way, as you do, that it is the 'cgroup maintainer' who wants this. However, this 'change' has been bandied around for at least a couple of years now largely because it looks as though they thought kdbus would get a free pass into the kernel. We all know that's what this means.
Ted Ts'o comments are fine but i don't get the "they don't listen" bit, if they didn't you wouldn't still be able to start your binaries with your current init scripts or have logs forwarded to syslog etc.
Because......that has nothing to do with systemd's benevolent and great leadership? Stuff works that has already worked......because it does.
Isn't that an argument that everything should be written in shell script?
No.
You really haven't the slightest idea what you're talking about, do you?
This reminds me of that Spinal Tap scene: "But.....it goes all the way up to eleven".
Theodore is not the only kernel person to have issues with systemd, and in particular the kdbus component systemd proponents don't think should need questioned.
kdbus will never be put into the kernel. Those proposing it have been asked what they need to provide and they've done nothing but stall, hoping that the argument "Oh, it does this in userspace!" will suffice.
the post was not worth a point by point rebuttal, its just the same drivel that has been rebutted many times before
That's exactly the sentence you're going to hear repeated by Lennart at a systemd conference, ad nauseum.
You're either trolling or you've genuinely no idea how systemd actually works.
So an autopilot malfunction caused the plane to lose all contact with the outside world completely and fly in a corridor, in three dimensions at the right altitude, precisely where different air traffic controls would think it was each other's responsibility and allow it passage? You think that if it gives you comfort. However, there is no getting away from the fact that this is the most alarming plane disappearance in history and even finding wreckage is unlikely to yield the answers required.
Seriously, WTF happened? Well Microsoft happened we all know that. The way forward was clear when the iPhone and then Android came about - either improve Symbian or move to Android. They could at least have been where Samsung is now as the de facto Android manufacturer and done a far better job.
The F-35 and especially the F-22 have a hopeless record at being able to stay airworthy for any length of time. They are always in maintenance for one problem or another. I'm not sure where you're getting your figures from, but for a plane that's been in development for well over two decades and where there is no sign whatsoever when it will be operationally ready you're hopelessly optimistic.
It's part of the same clusterfuck though, and for some reason the systemd people are convinced that kdbus is necessary to solve all of their problems......whatever they are.
Nope, I'm afraid they're holding off for an awful lot longer than that if kdbus isn't basically redesigned and criticisms are addressed. Greg simply doesn't get to decide this no matter how highly Linus rates him, and his reputation is taking a bit of a pounding with some of the bizarre messages he's been posting.
By the same token kernel developers are free to keep rejecting kdbus if it doesn't meet their needs or expectations.
I bet they'll produce far more of them, and keeping their Suckhois in service that will be more than enough. You've also got to be able to keep a plane in the air, and the F-22 and F-35 has an incredibly poor record on that count.
Against a semi-credible enemy you always end up dogfighting. You can never assume that an enemy's radar and detection system won't get better, and when they do they simply upgrade them. To stay a head a stealth plane needs to be taken out of service and it's shape and materials changed.
Besides... the site has been photographed from orbit repeatedly since.
Nope, they haven't been photographed at all any detail at all. You would think NASA and people would be interested in having a look at how all the equipment on the moon is faring, and even find out where the actual coordinates of the damn things are, as opposed to looking at indistinct dots. But there you go. Maybe they just aren't bothered.