Originally posted by Redeeman
View Post
Announcement
Collapse
No announcement yet.
Mixing open and closed source
Collapse
X
-
Originally posted by Jake View PostOkay, I'll bite. Let's break this down a bit.
DRM is a form of content protection - but for digital, it is no different than Macrovision, CGMSA and so on. Content protection is a technical mean to enforce copyright rights. Hopefully we can all agree on that. Let me repeat. It is a technical means to enforce copyright rights. I will continue to use Content Protection (CP) instead of DRM for clarity.
As a human, we don't like being told that we aren't trusted. We are fundametnally talking about a technical means to enforce copyright rights because the copyright owner doesn't trust us.
Now let's play a game of swap the players nouns and pronouns.
- DRM allows the MPAA to ensure you don't copy movies.
- Technical means of copyright protection allows the copyright owner to ensure you don't violate the copyright owners protected (copyright wise) works.
- The GPL_ONLY flag allows the Kernel Developers to ensure you don't derive from their kernel code.
Now I know people will claim but it's different, both are interpretations from the copyright holders point of view, not the users. Interpretation is just that.
This view is not just mine, here is a good link from LKML.
Play the swap the nouns and pronouns a bit in a lot of the posts in this article, and a surprisingly large number would look quite bad from the kernel developers point of view.
I am not saying DRM is right, but I am saying that it is just as right as the GPL_ONLY flag in the kernel.
Regards!
Comment
-
Originally posted by givemesugarr View Postfor what i know gpl_only ensures that no software could be derived from that code and sold to someone without releasing the source code that is unde gpl and that in the kernel you can only introduce stuff that has open source code. and this is to protect your freedom. i ask for forgiveness if i misunderstood this.
Basically it uses copyright laws to ensure that no matter what the code will always be available to copy. It's genius if you ask me. It takes the very problem and turns it into the solution. While DRM is exactly the opposite. It is designed to ensure that content cant be copied, and is nothing at all what the GPL tries to do.
Comparing the GPL to DRM is easily the stupidest thing anybody has ever tried to do.... period...
Comment
-
Originally posted by glisse View PostWell, i likely didn't explain properly here is what i mean, you got the idct register:
MMIO offset 0xDEADBEEF IDCT_SETUP
bit 0 enable IDCT
bit 1 enable MACROVISION
bit 2 ....
Now here what AMD could make public:
MMIO offset 0xDEADBEEF IDCT_SETUP
bit 0 enable IDCT
bit 1 unused have to been set to 1
bit 2 ....
You see if you expose bit 0 and all others bits in this register there will be people wondering what the hell this bit is for and they will try to see and find out quickly that by clearing it you can disable macrovision. I have debileratly taken an easy example but i hope you get the idea why they can't expose decoding possibilities and what they mean by tightly bind together with DRM well at least this is my understanding of their problem.
It's easy and glib to say that this was a party that was going to happen anyway. That's not quite what the real story is. If the media companies weren't so pedantic about worrying about "piracy" (Let's be dead honest about it here... They want "control" and they want to force us into a rental situation instead of a purchase situation- they want all the benefits of Copyright protection, but none of the "disadvantages" they perceive that this has.) that this wouldn't have been a party that would have actually happened in the first place had they been reasonable about all of it in the first place.
Of course people can RE things but you won't see me and likely not many others people starting doing RE on windows, i haven't installed one in more than 8 years and i would have to learn many things to know how to RE on that crap.Last edited by Svartalf; 09 February 2008, 02:48 PM.
Comment
-
Originally posted by bridgman View PostIntel seems to be leaving out the same features out of their docs, and NVidia isn't releasing any docs at all. Tell me again how this makes us the bad guys ?
The discussion of the lack of a real need for the support to be combined (For example, Macrovision's dead worthless on video these days- why keep USING it in the first place?) is different from the discussion of why we can't get hardware decode support for unencrypted content. But some people don't get that you're kind of stuck in a mess that didn't really need to have happen to you and it's damned difficult to get back out of it.Last edited by Svartalf; 09 February 2008, 03:01 PM.
Comment
-
Originally posted by Redeeman View Postwell obviously i dont think its okay for other vendors either. I am picking on you(AMD/ATI) because you have made a graphics card design where even though you seem to be opening up most of the docs, you are leaving out key features, because of DRM.
Intel does the same as was already pointed out, and it's even worse with nvidia...
On those boards Bridgman also said they will look into h.264 decoding after 3d release and if it's possible the doc will be there. Is it that bad that it's just a possibility? Should they drop the 3d now and look into video decoding instead because you want it? .. Your constant nagging doesn't really help and hardware video decoding isn't a key feature of graphic card for most people.
If you want to nag more, please just wait with it until we know the final word on releasing video docs.
Yep that means after the 3d most likely. Although others know better when it will be as I'm not working for AMDLast edited by val-gaav; 09 February 2008, 03:19 PM.
Comment
-
Originally posted by givemesugarr View Postfor what i know gpl_only ensures that no software could be derived from that code and sold to someone without releasing the source code that is unde gpl and that in the kernel you can only introduce stuff that has open source code. and this is to protect your freedom. i ask for forgiveness if i misunderstood this.
for what i know DRM ensures that no copies of the media are made and sold to someone without paying the appropriate fee and that you only make copies of the music under the direct guidance of the copyright owner. and this is to protect the artists rights. i ask for forgiveness if i misunderstood this.
Note that I am not arguing the morality (for profit vs for freedom), but rather that DRM is a technical means of enforcing the media companies view of fair use, and is fundamentally no different than the kernel authors enforcing their view of fair use.
Please don't interpret this as a flameworth response, I am just trying to ensure that you have a clearer understanding of my point.
Regards.
Comment
-
Originally posted by duby229 View PostBasically it uses copyright laws to ensure that no matter what the code will always be available to copy. It's genius if you ask me. It takes the very problem and turns it into the solution.
DRM is technical implementation to support the same thing. It is uses copyright laws (including DMCA) to ensure that no unauthorised copies are made no matter what (the no matter what may be naive, but it is still there).
While DRM is exactly the opposite. It is designed to ensure that content cant be copied, and is nothing at all what the GPL tries to do.
Comparing the GPL to DRM is easily the stupidest thing anybody has ever tried to do.... period...
You obviously didn't click the link that was quoted, since both Linus Torvalds and Theodore Tso have both made the exact same comparison.
Quoting from the thread within the link.
Originally posted by Theodore Tso
That's the big thing about dynamic linking. The GPL has always said it is about distribution, not about use. The dynamic linking of a kernel module happens in the privacy of someone's home. When we try to dictate what people are doing in the privacy in their home, we're no better than the MPAA or the RIAA.Originally posted by Linus Torvalds
For example, GPL_ONLY is intended to support a developers view that their interface is Linux unique, and any modules using that interface is clearly a derivation of the kernel, and consequently must be GPL.
In no way, should a non-GPL module be considered a deriviative work if it uses a standard Unix function such as udelay. But yet, if PARAVIRT is enabled in the kernel, the udelay function gets hidden behind the GPL_ONLY data structure and the compile fails.
As Linus and Theodore indicate, any form of fair use enforcement is fundamentally broken in the same way. Evil is purely a point of view.
Comment
-
Originally posted by Redeeman View Postquite wrong.
the EXPORT_SYMBOL_GPL is there to guide people, it doesent prevent anyone from doing stuff.. and it most certainly does not prevent people from removing it, or doing whatever. its made as a tool to help people know if what they are doing is a derived copy or not.
As I have said in another post. For 2.6.22, if you enable PARAVIRT in the kernel suddenly udelay - a function that exists in nearly any unix style system in the universe, is reported as a GPL_ONLY function.
Just like DRM, it is a fundamentally broken way
that is, it doesent stop people from using their FAIR USE rights.
I am always amazed at the number of people who openly flout DRM, but then cry foul about people removing the GPL_ONLY flag. Both are removing technical measures that are intended to guide against copyright violations.
Comment
-
As I told before...
Guys please lets focus on the present problems, which are quite a lot, and then we can melt this DRM issue discussing solutions!!
Most of us cannot even play a HD-BD movie not to tell about copy or so...
We do not even know which media format will finally win in the HD-BD war...
Also we have another parameter now, DisplayPort against HDMI!
Can we have XV, XvMC, Crossfire-CrossfireX, Avivo Crossfire, HD AGP cards working, Better AIGLX and better Xorg 7,3 support by either of the 3 drivers for now??
Then we can break our heads searching for a working DRM solution-workaround...
Comment
Comment