Skip to content
Snippets Groups Projects
  1. Jul 24, 2013
    • 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
  2. Oct 18, 2011
    • Simon Glass's avatar
      Correct dependency rule to fix SPL build · eaeecde7
      Simon Glass authored
      
      Commit 47508843 introduced a change in the dependency generation which
      breaks SPL, because the source files being built are not initially present
      and are symlinked as part of the build.
      
      The .depend file must depend not only on the files in the DEPS list but
      also on the sources which did not contribute files to the DEPS list, since
      these sources will otherwise not get a dependency and will not be built.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Tested-by: default avatarWolfgang Denk <wd@denx.de>
      eaeecde7
  3. Oct 17, 2011
    • Simon Glass's avatar
      Adjust dependency rules to permit per-file flags · 47508843
      Simon Glass authored
      
      The dependency rules are currently done in a shell 'for' loop. This does not
      permit Makefile variables to adjust preprocessor flags as is done with normal
      compile flags, using the CFLAGS_path/file.o syntax.
      
      This change moves the dependency generation into the Makefile itself, and
      permits a CPPFLAGS_path/file.o to adjust preprocessor flags on a file or
      directory basis.
      
      The CPPFLAGS_... variable is also folded into CFLAGS during the build.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      47508843
  4. Sep 07, 2011
  5. Jul 28, 2011
  6. Jul 14, 2011
  7. Oct 06, 2010
  8. Dec 02, 2009
    • Scott Wood's avatar
      makefiles: fixes for building build tools · d984fed0
      Scott Wood authored
      
      Currently, some of the tools instead set CC to be HOSTCC in order to re-use
      some pattern rules -- but this fails when the user overrides CC on the make
      command line.  Also, the HOSTCFLAGS in tools/Makefile are currently not
      being used because config.mk overwrites them.
      
      This patch adds static pattern rules for files that have been requested to
      be built with the native compiler using $(HOSTSRCS) and $(HOSTOBJS), and
      converts the tools to use them.
      
      It restores easylogo to using the host compiler, which was broken by commit
      38d299c2 (if this was an intentional change,
      please let me know -- but it seems to be a build tool).
      
      It restores -pedantic and the special flags for darwin and cygwin that were
      requested in tools/makefile (but keeps the flags added by config.mk) --
      hopefully someone can test this on those platforms.  It no longer
      conditionalizes -pedantic on not being darwin; it wasn't clear that that was
      intentional, and unless there's a real problem it's just inviting people to
      contribute non-pedantic patches to those files (I'm not a fan of -pedantic
      personally, but if it's on for one platform it should be on for all).
      
      HOST_LDFLAGS is renamed HOSTLDFLAGS for consistency with the previous
      HOST_CFLAGS to HOSTCFLAGS rename.  A new HOSTCFLAGS_NOPED is made available
      for those files which currently cannot be built with -pedantic, and replaces
      the old FIT_CFLAGS.
      
      imls now uses the cross compiler properly, rather than by trying to
      reconstruct CC using the typoed $(CROSS_COMPILER).
      
      envcrc.c is now dependency-processed unconditionally -- previously it would
      be built without being on (HOST)SRCS if CONFIG_ENV_IS_EMBEDDED was not
      selected.
      
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      d984fed0
  9. Jul 23, 2009
  10. Sep 01, 2006
    • Marian Balakowicz's avatar
      Add support for a saving build objects in a separate directory. · f9328639
      Marian Balakowicz authored
      Modifications are based on the linux kernel approach and
      support two use cases:
      
        1) Add O= to the make command line
        'make O=/tmp/build all'
      
        2) Set environement variable BUILD_DIR to point to the desired location
        'export BUILD_DIR=/tmp/build'
        'make'
      
      The second approach can also be used with a MAKEALL script
      'export BUILD_DIR=/tmp/build'
      './MAKEALL'
      
      Command line 'O=' setting overrides BUILD_DIR environent variable.
      
      When none of the above methods is used the local build is performed and
      the object files are placed in the source directory.
      f9328639
  11. Jun 27, 2003
    • Wolfgang Denk's avatar
      * Code cleanup: · 8bde7f77
      Wolfgang Denk authored
        - remove trailing white space, trailing empty lines, C++ comments, etc.
        - split cmd_boot.c (separate cmd_bdinfo.c and cmd_load.c)
      
      * Patches by Kenneth Johansson, 25 Jun 2003:
        - major rework of command structure
          (work done mostly by Michal Cendrowski and Joakim Kristiansen)
      8bde7f77
  12. Apr 28, 2001
  13. Dec 14, 2000
  14. Jul 10, 2000
Loading