Skip to content
Snippets Groups Projects
  1. Oct 26, 2022
    • Paul Barker's avatar
      Licenses: Clarify exceptions for standalone apps · 47ef860a
      Paul Barker authored and Tom Rini's avatar Tom Rini committed
      On 2010-01-27, an email [1] was sent to the mailing list by Wolfgang
      Denk which clarified the intended licensing exceptions for standalone
      applications. As the "export.h" header and the "stubs.c" source files
      are required to implement a standalone application, the intention was
      that these files be covered by the licensing exception. This is made
      clear in the following quotes from that email:
      
      	"exports.h" should be added to the "allowed" file list; there should
      	be no need to include "common.h". Eventually this needs fixing.
      	Patches are welcome.
      
      	"examples/standalone/stubs.c" should be added to the "allowed" file
      	list (the ppc_*jmp.S files are LGPLed).
      
      	There should be no doubts - the intention is clear, the current state
      	may need improvement. Help (read: patches) welcome.
      
      [1]: https://lists.denx.de/pipermail/u-boot/2010-January/067174.html
      
      
      
      Signed-off-by: default avatarPaul Barker <paul.barker@sancloud.com>
      Cc: Wolfgang Denk <wd@denx.de>
      Acked-by: Wolfgang Denk <w...
      47ef860a
  2. Apr 11, 2022
    • Sean Anderson's avatar
      Add valgrind headers to U-Boot · fba0882b
      Sean Anderson authored and Tom Rini's avatar Tom Rini committed
      
      Valgrind uses magic code sequences to define an ABI that the client may use
      to request behavior from the host. In particular, this may be used to
      inform valgrind about custom allocators, such as the one used in U-Boot.
      
      This adds headers defining these sequences to U-Boot. It also adds a config
      option to disable emission of these sequences entirely, in the (likely)
      event that the user does not wish to use valgrind. Note that this option is
      called NVALGRIND upstream, but was renamed (and inverted) to
      CONFIG_VALGRIND. Aside from this and the conversion of a few instances of
      VALGRIND_DO_CLIENT_REQUEST_EXPR to STMT, these headers are unmodified.
      
      These headers were copied from valgrind 3.16.1-4 as distributed in Arch
      Linux. They are licensed with the bzip2 1.16 license. This appears to be a
      BSD license with some clauses from Zlib.
      
      Signed-off-by: default avatarSean Anderson <seanga2@gmail.com>
      Reviewed-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      fba0882b
  3. Sep 30, 2021
  4. Aug 14, 2020
  5. May 23, 2018
  6. Nov 26, 2017
  7. Jan 30, 2016
  8. Apr 23, 2015
  9. Sep 16, 2014
  10. Oct 14, 2013
  11. Sep 20, 2013
    • Wolfgang Denk's avatar
      SPDX: fix IBM-pibs license identifier · 1b387ef5
      Wolfgang Denk authored
      
      The SPDX License List version 1.19 now contains an official entry for
      the IBM-pibs license.  However, instead of our suggestion "ibm-pibs",
      the SPDX License List uses "IBM-pibs", with the following rationale:
      "The reason being that all other SPDX License List short identifiers
      tend towards using capital letters unless spelling a word.  I'd prefer
      to be consistent to this end".
      
      Change the license IDs to use the official name.
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      1b387ef5
  12. Aug 19, 2013
  13. Aug 10, 2013
  14. Jul 24, 2013
    • Wolfgang Denk's avatar
      e85427fd
    • Wolfgang Denk's avatar
      a53002f4
    • Wolfgang Denk's avatar
      eee479cf
    • Wolfgang Denk's avatar
      Licenses: introduce SPDX Unique Lincense Identifiers · eca3aeb3
      Wolfgang Denk authored
      Like many other projects, U-Boot has a tradition of including big
      blocks of License headers in all files.  This not only blows up the
      source code with mostly redundant information, but also makes it very
      difficult to generate License Clearing Reports.  An additional problem
      is that even the same lincenses are referred to by a number of
      slightly varying text blocks (full, abbreviated, different
      indentation, line wrapping and/or white space, with obsolete address
      information, ...) which makes automatic processing a nightmare.
      
      To make this easier, such license headers in the source files will be
      replaced with a single line reference to Unique Lincense Identifiers
      as defined by the Linux Foundation's SPDX project [1].  For example,
      in a source file the full "GPL v2.0 or later" header text will be
      replaced by a single line:
      
              SPDX-License-Identifier:        GPL-2.0+
      
      We use the SPDX Unique Lincense Identifiers here; these are available
      at [2].
      
      Note: From the legal point of view, this patch is supposed to be only
      a change to the textual representation of the license information,
      but in no way any change to the actual license terms. With this patch
      applied, all files will still be licensed under the same terms they
      were before.
      
      Note 2: The apparent difference between the old "COPYING" and the new
      "Licenses/gpl-2.0.txt" only results from switching to the upstream
      version of the license which is differently formatted; there are not
      any actual changes to the content.
      
      Note 3: There are some recurring questions about linense issues, such
      as:
          - Is a "All Rights Reserved" clause a problem in GPL code?
          - Are files without any license header a problem?
          - Do we need license headers at all?
      
      The following excerpt from an e-mail by Daniel B. Ravicher should help
      with these:
      
      | Message-ID: <4ADF8CAA.5030808@softwarefreedom.org>
      | Date: Wed, 21 Oct 2009 18:35:22 -0400
      | From: "Daniel B. Ravicher" <ravicher@softwarefreedom.org>
      | To: Wolfgang Denk <wd@denx.de>
      | Subject: Re: GPL and license cleanup questions
      |
      | Mr. Denk,
      |
      | Wolfgang Denk wrote:
      | > - There are a number of files which do not include any specific
      | > license information at all. Is it correct to assume that these files
      | > are automatically covered by the "GPL v2 or later" clause as
      | > specified by the COPYING file in the top level directory of the
      | > U-Boot source tree?
      |
      | That is a very fact specific analysis and could be different across the
      | various files.  However, if the contributor could reasonably be expected
      | to have known that the project was licensed GPLv2 or later at the time
      | she made her contribution, then a reasonably implication is that she
      | consented to her contributions being distributed under those terms.
      |
      | > - Do such files need any clean up, for example should we add GPL
      | > headers to them, or is this not needed?
      |
      | If the project as a whole is licensed under clear terms, you need not
      | identify those same terms in each file, although there is no harm in
      | doing so.
      |
      | > - There are other files, which include both a GPL license header
      | > _plus_ some copyright note with an "All Rights Reserved" clause. It
      | > has been my understanding that this is a conflict, and me must ask
      | > the copyright holders to remove such "All Rights Reserved" clauses.
      | > But then, some people claim that "All Rights Reserved" is a no-op
      | > nowadays. License checking tools (like OSLC) seem to indicate this is
      | > a problem, but then we see quite a lot of "All rights reserved" in
      | > BSD-licensed files in gcc and glibc. So what is the correct way to
      | > deal with such files?
      |
      | It is not a conflict to grant a license and also reserve all rights, as
      | implicit in that language is that you are reserving all "other" rights
      | not granted in the license.  Thus, a file with "Licensed under GPL, All
      | Rights Reserved" would mean that it is licensed under the GPL, but no
      | other rights are given to copy, modify or redistribute it.
      |
      | Warm regards,
      | --Dan
      |
      | Daniel B. Ravicher, Legal Director
      | Software Freedom Law Center (SFLC) and Moglen Ravicher LLC
      | 1995 Broadway, 17th Fl., New York, NY 10023
      | (212) 461-1902 direct  (212) 580-0800 main  (212) 580-0898 fax
      | ravicher@softwarefreedom.org   www.softwarefreedom.org
      
      [1] http://spdx.org/
      [2] http://spdx.org/licenses/
      
      
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      eca3aeb3
Loading