Page 11 of 16 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 152

Thread: Mixing open and closed source

  1. #101
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,279

    Default

    Quote Originally Posted by Redeeman View Post
    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 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 ?

  2. #102
    Join Date
    Jun 2007
    Posts
    406

    Default

    Quote Originally Posted by Jake View Post
    Okay, 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!
    for 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.

  3. #103
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by givemesugarr View Post
    for 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.
    What that person that you quoted doesnt understand is the copyleft clause in the GPL. Which by the way will hold up to legal scrutiny when the time comes.

    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...

  4. #104
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by glisse View Post
    Well, 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.
    As it would be my understanding of the problem. This is due to what I alluded to- the components for the content control are tightly coupled to the decode portions. This is because the Media companies (While I buy John's assertion that there'd been a party anyhow, I don't buy that it would have happened had the Media companies not been clamoring for it...there's no need to make things MORE complicated by and of themselves- ever...) are so twitchy about the media being available outside of it's DRM "armor" in a way people can just pluck the stream out that they have the entire computer and electronics industry tying themselves in knots over it. I know this to be a fact- I've seen it several times and the subject specifically came up in one of my interviews with one of the mainline set-top box manufacturers over in the Metrowest area around Boston back over a year ago.

    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.
    Ugh... There's no good reason to resort to foul language here. I certainly didn't say anything to merit bringing up the subject...
    Last edited by Svartalf; 02-09-2008 at 01:48 PM.

  5. #105
    Join Date
    Jun 2006
    Posts
    3,046

    Default

    Quote Originally Posted by bridgman View Post
    Intel 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 ?
    Just ignore him, John. Heh... That one's wont to tilt at windmills and will just simply speak out without understanding the root causes of a lot of the pain or passion that motivates the comments. In the end, there's quite a few people that don't get that most of the industry's between a rock and a hard place, mostly of their own making.

    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; 02-09-2008 at 02:01 PM.

  6. #106
    Join Date
    Dec 2007
    Posts
    248

    Default

    Quote Originally Posted by Redeeman View Post
    well 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.
    Sorry but reading through your posts here I must say that you are biased toward AMD.

    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 AMD
    Last edited by val-gaav; 02-09-2008 at 02:19 PM.

  7. #107
    Join Date
    Feb 2008
    Posts
    4

    Default

    Quote Originally Posted by givemesugarr View Post
    for 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.
    That is correct... But again directly swapping nouns around... Quoting you directly with swapped nouns...

    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.

  8. #108
    Join Date
    Feb 2008
    Posts
    4

    Default

    Quote Originally Posted by duby229 View Post
    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.
    Although you seemed to have implied that my comments were about the GPL license and not the GPL_ONLY flag in the kernel...

    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.
    Again, ignoring the morality nor the intent (for profit vs for freedom), DRM and the GPL_ONLY flag in the kernel is fundamentally the same thing.

    Comparing the GPL to DRM is easily the stupidest thing anybody has ever tried to do.... period...
    I made no comparison between the GPL and DRM, I made a comparsion between the GPL_ONLY flag in the kernel and DRM as both being Technical measures used by a copyright owner to enforce their interpretation of fair use.

    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.

    Quote Originally Posted by Theodore Tso
    http://lkml.org/lkml/2006/12/16/131

    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.
    Quote Originally Posted by Linus Torvalds
    http://lkml.org/lkml/2006/12/16/75

    I find the RIAA's position and the DMCA distasteful, and in that I
    probably have a lot of things in common with a lot of people on this list.
    But by _exactly_ the same token, I also find the FSF's position and a lot
    of GPL zealots' position on this matter very distasteful.
    Let me re-iterate one more time. DRM is not fundamentally any more evil than the GPL_ONLY flag. Users get stung by DRM in the same way that naive changes to the kernel developers sting non-GPL module developers.

    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.

  9. #109
    Join Date
    Feb 2008
    Posts
    4

    Default

    Quote Originally Posted by Redeeman View Post
    quite 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.
    I disagree. No distribution would remove the EXPORT_SYMBOL_GPL flag from the functions. So it DOES prevent people from doing things in the real world. Asking for people who operate in the media market (like AMD) to ignore DRM is fundamentally no different than asking distribution to strip off the GPL_ONLY flags from the kernel. If you part of the ecosystem you must accept the technical measures of that ecosystem. For the media playback industry, DRM is a requirement.

    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.
    In the same way that DRM [CSS, AACS, etc] (ultimately - invariably it gets cracked) does 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.

  10. #110
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    250

    Default

    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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •