Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Incredible restrictive CMSIS license

Hello,

while ARM changed the license for CMSIS headers to BSD some time ago, TI still has a very restrictive license on their part specific CMSIS headers, found in spmc018.zip and 4212.svd-tiva-11073.zip. The latter tells e.g.

DO NOT CLICK "I AGREE" UNLESS :

1. YOU ARE AUTHORIZED TO AGREE TO THE TERMS OF THIS LICENSE ON BEHALF OF YOURSELF AND YOUR COMPANY; AND

2. YOU INTEND TO ENTER THIS LEGALLY BINDING AGREEMENT ON BEHALF OF YOURSELF AND YOUR COMPANY.

I work as engineer in some lab of our university. The license implies that I go to the central legal department to negociate clearance to enter the legal binding agreement before doing anything with the headers. It that really intended?

At the moment these obstacles keep my from using TIVA.

  • I'll look into this. If ARM is using BSD for CMSIS files now, it doesn't seem sensible, given that large portions of TivaWare are also using BSD, for us to use a different license for our CMSIS files. I suspect this was just an oversight and those files were missed when we changed the licensing on the other portions of the package.

  • Hi Dave,

    are there any news on this? I'd really like to use those microcontrollers for some real-world applications, but the license is, ahem, not exactly preferable.

    Thanks and best regards,

    Philipp

  • Hi Dave,

    we went into the same problem as well. For a new project we are evaluating the TI microcontrollers to be used as our
    central component. We would like to use them with an OpenSource RTOS, which is licensed under BSD license.
    Unfortunately the TI license is not compatible with the BSD license of the RTOS, so we could not add support for TI microcontrollers here.

    I would really appreciate, of the TI CMSIS header would be licensed under the same license (or something compatible) like the standard ARM CMSIS headers as well, so we could use them for our product and also add support for TI chips to the RTOS as well.

    Best regards,


    Ole Reinhardt

  • Thanks for the reminder - to be perfectly honest, I had forgotten about this! I'm waiting for final approval to make the license change and, assuming this is received soon, we'll try to get a new CMSIS header release built and released with a BSD license alongside our next TivaWare release.

  • Hi!

    These are really good news. I'm looking forward to the next TivaWare release!
    Is there just any time schedule planned?

    Best regards,

    Ole Reinhardt

  • Some time in 1Q2014. That's as detailed a commitment as I'm willing provide right now.

  • Bad news on this, I'm afraid. I got a reply from our legal department and we can't release CMSIS under a BSD license. The CMSIS license is dictated by ARM and contains a requirement that CMSIS code be used only on ARM processors. As a result the files can't be re-released under BSD because that would remove a restriction imposed by the owner of the content.

    <Edit> Re-reading the original post, I see it mentioned that ARM changed the CMSIS license to BSD. I can't find any evidence of this. Can you point me at a document that states this?

    <Later Edit> I found some references and bounced this back to legal. More later...

  • What, TIVA is not ARM based?

    Here is the header of a current ARM provides CMSIS file, like found on

    http://www.keil.com/dd/docs/arm/nxp/lpc11xx/lpc11xx.h

     * @par
     * ARM Limited (ARM) is supplying this software for use with Cortex-M 
     * processor based microcontrollers.  This file can be freely distributed 
     * within development tools that are supporting such ARM based processors. 
     *
    
    I didn't find some recent actual CMSIS license on the web, however at least TI competitors got clearance to release under BSD license:
    http://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/
  • Uwe,

      Tiva parts are ARM based so, obviously, you can use CMSIS headers with them. The license you quote is the one I've seen and is not BSD compatible due to the first line which restricts use of the software to ARM-based microcontrollers. The BSD license does not contain this restriction.

      I've found several references that state that the CMSIS headers have now been released under a BSD license but I understand that you need to accept the original ARM license to download the package which contains the BSD files so there's still some debate over exactly what is distributable under BSD and what is not. I'm waiting to hear from the people who understand these things and will post more once I have the information.

  • Dave,

    thanks for your replies. But even if the license is not pure BSD, it is much less restrictive than your actual license that starts with: "Go to the legal department of your company and testify that you may speak for the whole company"

    B.t.w. perhaps we have a problem with names. What the posters here need are device specific headers files defining interrupt numbers, device register structures,  register bit definitions and device placement. No need the the Cortex internas in these headers.. Beside such file often found in the context of CMSIS, I see no real connection of theses files with CMSIS. Maybe these files are automatically produced from device HDL design files and the automatical translator is ARM provided and imposes restrictions. But  I don't see how the CMSIS license can impose restrictions on the way you distribute information on _your_ devices.

  • Dave,

    are you still on the license problem?

  • I can do nothing more with this until I hear back from our legal people and, last I heard, they were not inclined to allow us to change the license.

  • Dave,


    can you trigger the legal people again? Term 1 of the license is really rediculous...

  • Actually, it's not the license terms in the source code that are objectionable (they look relatively standard), it's the "license agreement" that you have to check off on when "installing" the code.  It's essentially a full proprietary-sw-grade agreement even though the SW being installed is open source.  Perhaps that is (or could be) separately controlled?  I'm inclined to agree that it would prevent any engineer at a "real company" from agreeing, if they were attempting to evaluate the TI parts with anything less than the full weight of the company behind them.


    (here's an example license from some tivaware sw)

    // hw_gpio.h - Defines and Macros for GPIO hardware.
    //
    // Copyright (c) 2005-2013 Texas Instruments Incorporated.  All rights reserved.
    // Software License Agreement
    //
    //   Redistribution and use in source and binary forms, with or without
    //   modification, are permitted provided that the following conditions
    //   are met:
    //
    //   Redistributions of source code must retain the above copyright
    //   notice, this list of conditions and the following disclaimer.
    //
    //   Redistributions in binary form must reproduce the above copyright
    //   notice, this list of conditions and the following disclaimer in the
    //   documentation and/or other materials provided with the  
    //   distribution.
    //
    //   Neither the name of Texas Instruments Incorporated nor the names of
    //   its contributors may be used to endorse or promote products derived
    //   from this software without specific prior written permission.
    //

    (blah, blah, "as is ..."  blah)

  • BTW, does anyone find it odd that TI slaps a license agreement on the .c/.h files generated by the PinMux utility?

    I guess it doesn't matter since it's going to rely on including other TI code that has the same license in your program, eventually, but...  is machine generated code even copyrightable?  (It reminds me of when Berkeley slapped a copyright/ license agreement on the "true" shell script...

  • It looks like I forgot to post a follow-up after talking with our legal people. Sorry about that!

    The result of my discussion was, I'm afraid, that the existing license language has to remain. Apparently, that's the language that we were told to use by ARM and, until they tell us otherwise, it has to stay.

    Regarding accepting the license agreement when installing TivaWare, note that the source code in TivaWare is covered by many different licenses. I'm pretty sure that the clickthrough only relates to the TI-proprietary license which stipulates that some source may only be used on TI processors and I suspect that's there because it's the most restrictive license covering any of the code in the package that we produced. That particular license only covers a subset of the code, though, and quite a large chunk is covered under a vanilla BSD license. To find out which license covers which code, look in the manifest file which you can find in the top level installation directory. This will also list all the licenses for each of the different modules in the third_party directory.

  • I'm with you on the license header in the PinMux-generated files. I fought that battle when the tool shipped but lost, I'm afraid. Sorry.

  • Dave Wilson said:
    Regarding accepting the license agreement when installing TivaWare, note that the source code in TivaWare is covered by many different licenses

    Dave,

    sorry for being so persistant. But have a look at http://www.ti.com/lit/sw/spmc018/spmc018.zip. This is the content I am interested in. That file contains the pure device headers , like LM4F/Include/LM4F122E5QC.h and startup code for different compilers. The header files are generated with SVDConv and contain no explicit copyright statement. All C and .s file are BSD licensed.  I see no other licensed material in that file. But still the .exe file is protected by this hard wording:

    DO NOT DOWNLOAD OR INSTALL the software programs unless you agree on behalf of
    yourself and your company to be bound by the terms of this License Agreement.

    1. YOU ARE AUTHORIZED TO AGREE TO THE TERMS OF THIS LICENSE ON BEHALF OF
    YOURSELF AND YOUR COMPANY; AND

    and the hard license is deployed too.

    How should I even comply with  restriction 1. ?

    I work as electrical engineer in a lab at a university. So I have no autorization to talk for our whole university. To get such autorization, I would have to go to the legal department which would either laugh at me or would not understand at all, what I want. I think very few engineers at a company can agree on some legal binding "on behalf of (their) company".

  • All I can say at this point is that I agree with you and feel your pain. We're working on a new SVD release and hopefully we'll get the license issues resolved in that. I can't, however, give you any specific timeframe for this. Sorry.

  • Feel the pain - of both sides!  Dave W. is clearly not the "bad guy" here - nor are most (such as Uwe) who seek to, "play by/within the rules" and avoid unwanted legal entanglements. 

    There may be a superior method - to achieve each side's goals!   As somewhat of a regular here - years past I became concerned w/the lack of protection afforded any/all outsiders - in offering contributions here.  Via this vendor's "Blake Ethridge" (he appears w/in the sticky - 4th post from top, here) I was able to secure this addition to the "boilerplate" - bottom of this/other forum pages:  "respective suppliers and providers of content."  (i.e. we outsiders qualify thus as, "providers of content" and receive similar, umbrella protections...)

    Blake worked with great effect w/vendor's legal dept. - accepted my input/concern - perhaps such magic can, "flow again..."  (one hopes)

  • note that the source code in TivaWare is covered by many different licenses.

    Maybe it would be better to break up tivaWare so that the installer license agreements would more closely match the licenses of the code that was actually installed.  It seems silly to have the same license agreement for the basic processor register definitions as is used for the usblib and iqmath  libraries (which do have the "only on TI products" clause.)

  • You definitely won't see TivaWare broken up into pieces since we want to provide as simple an installation process as possible and telling people they need to download some subset of a dozen different packages definitely doesn't aid that goal :-)

    That said, the basic processor register definitions, as shipped in current TivaWare, are all covered under a simple BSD license. From MANIFEST.txt in TivaWare:

    Software Name:  Tiva Device Header Files
    Version:        2.1.0.12573
    License Type:   BSD-3-Clause
    Delivered As:   Source
    Modified by TI: N/A
    Location:       ./inc
    Obtained From:  TI

    The problem with the CMSIS files is entirely independent of this.

  • Hi all,


    so, does this mean that we should just ignore the license concerning the executable's installer and use the clause at the top of each single file in question? That would make life easier, but never argue with a lawyer about what is easier...

    Anyway, TI won't sell many more of those TIVA-Microcontrollers if they don't fix the parametric search/product list soon.

    ** ERROR ** Load app data error: Results not found for the given familyId

    (http://www.ti.com/lsds/ti/arm/arm_cortex_m_microcontrollers/arm_cortex_m4/stellaris_arm_cortex_m4f/products.page)


    Not really helpful. Noone seemed to care about my entry on the contact form, so maybe Dave could slap one of the webmasters while he's on the way to the legal department again ;)

    Thanks,

    Philipp

  • Rather than resort to violence (which would be tricky for me anyway because the web guys are 200+ miles away), I can point you to the correct parametric search links for the Tiva products ("Stellaris" went away a year or so ago when the name changed. Yes, I agree that the web folks should have tried to maintain and redirect old URLs but...)

    For TM4C123-class parts:

    http://www.ti.com/lsds/ti/arm/arm_cortex_m_microcontrollers/arm_cortex_m4/tm4c123x_mcus/tm4c123x-mcus-products.page

    For newer TM4C129-class parts:

    http://www.ti.com/lsds/ti/arm/arm_cortex_m_microcontrollers/arm_cortex_m4/tm4c129x_mcus/tm4c129x-mcus-products.page

    Actually, now that I look at the information these two links provide, I see that it's totally bogus and seems to list a bunch of unrelated parts so perhaps I need to slap someone up in Dallas after all. I'll update the post as soon as I find out what's going on.

    EDIT: In writing my email to the web folks, I checked the URLs again and both are now working correctly for me. I guess this must have been a temporary problem or my browser was playing up again. Everything looks OK to me now but, if you see continued problems. let me know.

  • Hi Dave,


    thanks for the Links. I somehow must have missed the two subcategories on the left, which point to the working pages. I've always only found the graphical overview with the ARM-based processors (http://www.ti.com/lsds/ti/arm/overview.page) in which the "Tiva C Series MCUs" link is obviously wrong. I didn't use old URLs/bookmarks or something like this.

    Anyway, sorry for hijacking this thread for that problem, I know that it's not really related to the licensing issue.


    Regards,

    Philipp

  • No problem. Could you let me know exactly which link you are seeing which is broken? All the ones I've tried from that page, including the hotspot on the graphic, appear to go to the right place.

  • Hello everyone,


    I'm now actually starting software development for a new product using the Ethernut OS and a TM4C1294 and would like to revive this topic. The device headers are still not available as a separate archive file, so I downloaded the "SW-TM4C-DRL:
    TivaWare™ Peripheral Driver Library for C Series". It looks like TI has relaxed the license conditions. When downloading the package "SW-TM4C-DRL-2.1.0.12573.exe", I must agree to the following:

    -------------

    (a) I understand that this Software/Tool is subject to export controls under the U.S. Commerce Department’s Export Administration Regulations ("EAR").

    (b) I am NOT located in Cuba, Iran, North Korea, Sudan or Syria. I understand these are prohibited destination countries under the EAR or U.S. sanctions regulations.

    (c) I am NOT listed on the Commerce Department’s Denied Persons List, the Commerce Department's Entity List, the Commerce Department’s General Order No. 3 (in Supp. 1 t o EAR Part 736), or the Treasury Department’s Lists of Specially Designated Nationals.

    (d) I WILL NOT EXPORT, re-EXPORT or TRANSFER this Software/Tool to any prohibited destination, entity, or individual without the necessary export license(s) or authorization(s) from the U.S. Government.

    (e) I will NOT USE or TRANSFER this Software/Tool for use in any sensitive NUCLEAR, CHEMICAL or BIOLOGICAL WEAPONS, or MISSILE TECHNOLOGY end-uses unless authorized by the U.S. Government by regulation or specific license.

    (f) I understand that countries other than the United States may restrict the import, use, or export of the Subject Product. I agree that we shall be solely responsible for compliance with any such import, use, or export restrictions.

    • I / We hereby certify that we will adhere to the conditions above.
    • I / We do not know of any additional facts different from the above.
    • I / We take responsibility to comply with these terms.
    • I / We understand we are responsible to abide by the most current. versions of the Export Administration Regulations and other U.S. export and sanctions laws.

    ---------------

    After unpacking the installer, I found a file "TI-BSD-EULA.txt", which basically contains the BSD license and a "MANIFEST.txt". The latter lists the device include files as "BSD-3-Clause". The header files itself then contain the BSD license header as well.

    As far as I can tell now, it should be perfectly valid to include the used header files in the Ethernut source tree. Please comment if this is correct or if I missed something important.


    Thanks and best regards,
    Philipp