1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Source Code License

Discussion in 'General Chit Chat' started by Mihail Atanassov, Mar 2, 2015.

  1. Mihail Atanassov

    Mihail Atanassov New Member

    Joined:
    Feb 25, 2015
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Gender:
    Male
    Location:
    United Kingdom
    Hi Tom & co.,

    I've been browsing through the SVN repository, looking at the available goodies there. My main interest is in the Saturn flash config tool and more importantly, its license. The only license mention I managed to locate was a CC-BY-SA 3.0 which is not appropriate for the source code and its use is discouraged by CC (https://wiki.creativecommons.org/Fr...ply_a_Creative_Commons_license_to_software.3F).

    On that note, I'd like to see that utility available on Linux at some point, and I'll do it myself in July unless somebody beats me to it ;); however, the current license is a bit awkward and I'm not sure I should proceed with a fork of the code given that I'm not sure what the implications are. Are you guys willing to re-release it with a source-code specific license (e.g. BSD, MIT, GPLv2)? Thanks.

    Mihail
     
  2. admin

    admin Administrator Staff Member

    Joined:
    Jan 23, 2015
    Messages:
    169
    Likes Received:
    11
    Trophy Points:
    18
    Hello Mihail,

    Very relevant point. We are happy that somebody brought this up to our attention. As you can guess, we did not put a lot of thought when we decided to select the licences long ago(unfortunate :(). You will see content scattered throughout with different licenses and even with no license at all. This certainly needs to be fixed and we are willing to do that. Suggestions and opinions from people like you can help us decide a licensing strategy that can cater to our complete spectrum of customers and the types of content we share. Let me explain a bit.

    We share three different kinds of stuff through numato.com and numato.cc. They are,
    1. Documentation (including product documentation, blog entries etc... )
    2. Source code and binaries (Firmware, tools/application, HDL, scripts etc...)
    3. Design files (PCB layout, Schematics, CAD drawings etc...)
    Two kinds of customers use assets shared by us.
    1. Customers who wants to use some of the above mentioned assets as part of their commercial offerings and not willing to opensource their code.
    2. Opensource enthusiasts who wants to reuse and build on top of what we share.
    We could do separate licensing for commercial and opensource users so that both groups requirements will be met. And withing the open source realm, we could choose different licenses for different content types (for example, GPL for code, CC-BY-SA for documentation and some kind of OHL for hardware designs). Do you have any specific strategy to suggest ? I'm all ears!

    Thanks,
    Tom
     
  3. Mihail Atanassov

    Mihail Atanassov New Member

    Joined:
    Feb 25, 2015
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Gender:
    Male
    Location:
    United Kingdom
    Hi Tom,

    Sorry for the delayed response, my internet went bonkers.

    Disclaimer: I am not a lawyer.

    Now that we got that out of the way, I think you're right on the money with using a software-specific license for the source code, a hardware license for the design files, and CC-BY-SA for documentation. I can't comment on the OHL since I haven't looked into licensing hardware designs at all, but I can give you my personal opinion on the source code license.

    As far as my planned contribution is concerned, I have no problems working with a GPL, MIT, Apache-2.0, or BSD licensed code base. However, given your customers, I'd be more inclined to think that the more commercially-oriented ones would not object to a permissive license like MIT or BSD. As for the alternative (having separate licenses), I think you'd just be opening yourselves to a whole lot of legal murkiness (e.g. which license applies where, can the licenses be exchanged on a whim, and who knows what else). With that in mind, I think the best course of action would be to start a slightly wider discussion about what all your customers want in terms of the code licenses. I'm sure some will be adamant on GPL, and others won't mind a permissive license even if they don't plan to lock up the code for their own use.

    Hope that helps at least somewhat. It's a shame I can't offer actual legal advice.

    M

    P.S. My personal vote is on BSD because it's simple to understand and is GPL-compatible. If you have patented works in the software, then it's Apache.
     
    Last edited: Mar 4, 2015
  4. admin

    admin Administrator Staff Member

    Joined:
    Jan 23, 2015
    Messages:
    169
    Likes Received:
    11
    Trophy Points:
    18
    Hi Mihail, thanks for the comments. I'm now reading more about dual licensing and how that can compare to BSD license.

    For one thing we like BSD license because it is easy to understand and makes life easier for everyone. I personally like open source to be free as in "free speech", not "as in GPL" (http://www.howtogeek.com/howto/31717/what-do-the-phrases-free-speech-vs.-free-beer-really-mean/). Not surprisingly, this is especially true when I'm in the receiving end :). GPL let you have the beer but it is not free enough that you can sell your(?) bottle of beer and buy a sandwich (may be not a perfect metaphor). We have no patents so far (not planning to do any in the near future either) so one less thing to worry about.

    Dual licensing could allow our paid customers to integrate the code in their closed source products and we could still allow the code to be available to general public under GPL or similar license to make sure that the changes made to the code will be shared back with the community. With BSD license, there is no guarantee that people will share code improvements with the community.

    For hardware files, we will probably select CERN OHL or a similar license.

    That being said, we have a director board meeting coming up before end of this month and I will present these two options there. So we will have a definite answer as to what license we will go for by end of this month.
     
  5. Mihail Atanassov

    Mihail Atanassov New Member

    Joined:
    Feb 25, 2015
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Gender:
    Male
    Location:
    United Kingdom
    Hi Tom,

    Just one more thing I'd like to add to the topic. I've looked at the code in more detail; it was a bit hard to follow what libraries you've actually used, but I found you've utilised FTDI's proprietary libMPSSE. That most definitely means that GPL is not an option with the current code base. I don't know how (or if) BSD or others accommodate proprietary libraries. On the bright side, there is a GPLv2-licenced MPSSE library here: https://github.com/sfarbotka/libmpsse. This is a fork that allows building with MinGW on Windows. The original code base is currently here (migrated from Google Code): https://github.com/devttys0/libmpsse. The license is in docs/COPYING.
     
  6. cyrozap

    cyrozap Moderator

    Joined:
    Apr 12, 2015
    Messages:
    9
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    USA
    Disclaimer: I'm not a lawyer and this isn't legal advice.

    My recommendation for software licenses are as follows (I like the FSF's recommendations):
    • GNU General Public License 3.0 for software over 300 lines long and important programs (i.e., the FPGA configuration tools, other programming tools, microcontroller firmware)
    • Apache License 2.0 for software under 300 lines (i.e., demo/example code)
    • The Unlicense for small snippets of code you would like released into the public domain
    I haven't done much research on hardware licenses, but the CERN OHL is probably fine. While most people (myself included) probably won't end up building our own boards, it's nice to have schematics and a board layout when the documentation is ambiguous or otherwise hard to understand.

    Where things get really tricky is in the HDL licensing. I would still recommend Apache 2.0 and the Unlicense for HDL (based on code length as before), but the GPL was not designed with FPGAs in mind. Because of this, the "spirit" of the GPL (and the LGPL) could be lost if it were applied to HDL. If you want something similar to the GPL that might work for HDL, the Mozilla Public License Version 2.0 is worth a look.

    Finally, I'd just like to add that licensing something under the GPL does not prevent commercial use--it simply prevents commercial interests from restricting use of the software, thereby removing the user's freedoms. Additionally, the copyleft restrictions put in place by the GPL are designed to ensure that the user of a piece of software has the same freedoms as the original developer of the software. Unlike permissive licenses like the MIT/X11, BSD, and Apache 2.0, the GPL actively preserves those freedoms through the small restrictions it places on those who redistribute the software (it places no restrictions on users of the software).

    If you don't care for this moral argument for the GPL, the practical argument is that by releasing software under a permissive license, you give those who write proprietary software an advantage over those who write Free software. For instance, if a competitor uses your permissively-licensed code in one of their products and does not contribute back, you have given them an advantage over you. If you were to instead release that code under a copyleft license like the GPL, they would either have to contribute code back to you or write their own code from scratch.

    If any of you have any questions about software licensing or would like me to clarify any of my points, I'm always eager to help!
     

Share This Page