I want ot take copyright information of all open source components which are used for embedded system.Is there any short way to get the copyright information of OSS components?
Well, you've got your ${TMPDIR}/deploy/licences which has subdirectories for all recipes built. Those subdirectories inludes copies of both the license-files from those recipes, as well as the generic licenses for the declared licenses of those recipes.
There is also a subdirectory <image-name>-DATETIME, that includes eg a license.manifest, that lists all packages installed in the image, together with their licenses.
That very much depends on your concrete setup; which of course you completely fail to describe here. How should we know which OSS components you are using in your embedded system?!
But the general answer is: there is no detour. When your product is using OSS components, and you want to "track" that; then you have to do the tracking work.
That means:
You have to create a catalog of all OSS components that are included in your product (and the version in use). Ideally, that would be no-op, because your build / library setup already makes such a distinction.
Then you use that catalog as input, to determine the licence for each and any of these components.
Finally, depending on the specific licence, you determine the effects of using OSS component X for your product.
Related
Flutter provides a nice mechanism to show all license agreements within an application, since all packages from pub.dev come with structured license informations.
Suppose I want to commercialize an application and I'd like to choose the closed source model.
Can I somehow determine in a simple (programmatically) way, if the chosen packages allow this or require to open-source the application?
As jamesdlin pointed out in his comment, these licenses are copy-left licenses. And those licenses often require derivative works to use a compatible license model as well.
Since packages recursively include other packages, things get complicated soon. I estimate my current application to show around 250 lincense files - while I added only 14 packages.
Moreover, some licenses come from dart and flutter and therefore - I suppose - allows open-source and close-source distribution.
Unfortunately, I currently see no easy way to identify just those licenses, which belong to added packages by me.
My team is using more and more NuGet packages as a way to break the system into smaller pieces and share things between parts. We have adopted a sort of SRP principle for packaging, creating small and hopefully cohesive packages that do just one thing (logging, auditing, security stuff, etc).
Ideally they should be so cohesive and self-contained that it would be straightforward to know what package will contain what you need. However we are not yet there and sometimes is difficult to know what package you should add to access some functionality.
My question is: is there any way to publish and navigate package content information? Like, for instance, in MSDN you can see what assembly contains a class. Would it be possible to know something like that, at the package level?
Thanks.
It's a very localised version, but there is a package searcher for the ASP.NET 5 packages hosted on NuGet. It might be possible to host a version that looks at a wider scope at some point.
https://packagesearch.azurewebsites.net/
The closest functionality I can think of is implemented in ReSharper. However it can only search the packages in nuget.org(closed issue on GitHub). Since packages don't expose type info, JetBrains built a custom index and that's the only data source it can query.
I have several (Java) projects under maven control, developed in Eclipse, repo under Mercurial/bitbucket that I licence under Apache2 (though this question applies to any licences). What is the best way to licence this?
I have included a verbatim copy of the (Apache) LICENCE.txt in the top directory of the project. However there is no licence in any of the source files so that if they are re-used in other projects (as I hope they can be) they may get separated from the licence info. [Source files can be configuration/data as well as code and are not Java-specific]. If there are any changes to the licence then all these files will have to be edited. Possible approaches are:
use a brief sentence to refer back to LICENSE.txt
use a Maven licence tool if there is one?
use an Eclipse licence tool if there is one?
use a Bitbucket licence tool if it has one?
[I am on Windows so I don't want a sed/awk/grep approach]
UPDATE - have accepted #Nicmancol as the first answer given worked for me
UPDATE2 - Hmm. It has added a licence to all sorts of files in the distrib. Not such a good idea
You can use the Maven License Plugin or the License Maven Plugin
There are Eclipse plugins for adding / maintaining copyright notices in source file headers; e.g. see this SO question: How to manage license banners in source files of Eclipse plug-in projects. (The answers are more general than the question ...)
With a Maven project you can / should also add license details to the POM file.
From a purely legal perspective, it probably doesn't matter if a file gets separated from the "bundle" containing the copyright notice. Copyright applies irrespective of whether there is a copyright notice.
I agree that copyright applies irrespective, but authorship and licenses do not. So in an area where software is likely to be re-used we need to give the re-users that information.
Both authorship and licensing also apply irrespective of whether this is stated in each file.
Authorship is simply a fact, "William Stallings wrote Emacs" remains true even if someone strips the source headers. But knowing who the author of some piece of software is has no bearing over how someone else may use it, so it probably isn't of much relevance.
Licenses derive from copyright, and the default license is as set out in the relevant copyright law. That is, the default is that you do NOT have the right to make a copy, or have a copy that was made illegally.
If a file becomes separated from the license information, then it is up to the user of the file to deal with the problem; i.e. HE needs to find out what the license is. Because, the default is that he has no license.
Basically, if the copyright and/or license are unclear, the obligation is on the copier to find out what the copyright / license status is ... not the copyright owner / licensor. And that is as it should be. It is not possible for the copyright owner / licensor to PREVENT the information from BECOMING separated, and penalizing the copyright holder / licensor for something (illegal) that someone else did to achieve that separation would be manifestly unfair.
It is generally considered good practice to add some lines with author, version and license information to the top of source files. For instance, Gnu GPL v3 suggests to add
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms [SNIP]
I find it tedious to add it manually to each file, and to have to update them all every now and then when some of this information changes (new authors, copyright years, version bumps).
Is there a way to manage this automatically, so that I only have to edit this stuff in one place and it gets automagically copied around?
If needed, you may assume that I am using any modern revision control system.
It is generally considered good practice to add some lines with author, version and license information to the top of source files.
That depends. First of all there are two (and more) ways to do this:
manage licensing information per file
manage licensing information in a central location
If you start a project from scratch, the per-file method is often easy to do while keeping things clear. As you write, over time it becomes more difficult to keep track of things. So more and more projects switch to the central location variant.
The file-by-file method has the benefit that the scope of a work is clear. Often you write the name of the application in the file-comment. If a single file is taken out for some reason, the information is still in there and the documentation chain is not broken.
With the central location method, the benefit is that this is normally supported by your version control software, for example GIT. Commits can be signed by the committing person, and author can be given. It's documented who has written which code automatically and that information is stored in a central location: the VCS.
Keep a COPYING file with your package where you provide the main information centrally. You can easily generate the list of authors via the VCS. And per each file you can create one header that just specifies which software and where to look into, just a bare outline:
/**
* Flux Deluxe v3.2.0 - Vector Drawing Redefined
*
* Copyright 2010, 2012 by its authors.
* Some rights reserved. See COPYING, AUTHORS.
*/
If you release a new version in a new year it's a no-brainer to update all files.
Use the License Header Manager
If working with Visual Studio, you could use macro's and attach a shortcut to it.
Then, when creating a new file, use the shortcut to add a header.
If you want to be sure that a header has been included in each file, you can use StyleCop.
Following links might be helpful:
http://abhijitjana.net/2010/12/05/add-document-header-for-files-automatically-in-visual-studio/
http://stylecop.codeplex.com/
In Eclipse, there is also macro support so you should be able to do the same as suggested for VS. However, I do not have any experience with that.
For Java, there is an alternative to StyleCop:
http://stylecop.codeplex.com/
I haven't heard of any SVN-tools that adapt the files itself.
Using macro's in your editor is the closest thing to what you want.
I have minimal exposure to RPM, Windows installer mechanics, and WIX. That said, I'm interested in making a cross-platform installer tool (Linux, Windows) that supports upgrading and downgrading (versiona and patches) of my own product. I don't believe this is a topic to be approached lightly; I would like to learn the science of the art (or the art of the science). If I succeed, and build a minimally successful installer tool, it would have these features:
does not depend on a platform-specific tool (such as Windows Installer).
reads XML or a declarative syntax to fulfill installation requirements.
attempts to minimize steps to upgrade or downgrade one of my products (rather than requiring a complete uninstall and re-install).
does not require knowledge of interim product versions, in order to jump versions (i.e. can upgrade one of my products from version 1 to version 3, without passing through version 2).
I'm convinced that "the key" to achieving this goal is by seeing versions as a "point A to point B" problem, which implies that A and B are described by two XML "version" documents that hold info about all the parts and actions (files, or platform specifics such as registry entries). My installer tool would "join" or compare the two documents and determine a minimal set of changes to transform A into B. To some extent, I believe this is precisely what Windows Installer does.
Of course there are further complexities, but that is the point of this post. Where is "the bible" of information on this topic? Remember, I want to make my own installer - not use a platform-specific one. For those who care, my products are usually written in C++ or C#.
Or perhaps I should study something like Steam which is cross-platform and has "automated game updates" as part of its capabilities. In my case, the problem of online deployment is already handled. It is just the final installation step I'm examining. Does Steam use native installers (such as an MSI)? If yes, then that is not what I'm looking for.
In short, what path should I pursue to become somewhat competent on the science of this topic?
I'm not an expert and others can give you better answers but...
Don't declaratively list steps required to install your product - You'll end up making assumptions which will eventually prove wrong. Instead, you should be looking at defining the final state of the installation and let the installer worry about how to make that happen.
Another consideration is that being downgradable may involve huge complications depending on your product - Would it have to down-grade database schemas / file formats / ??? In short, every version of your app will need to be both fully forwards- and backwards-compatible (or at least fail gracefully). Also consider the scenario where V1 of your app stores settings in a file. V2 comes along and adds more settings. You downgrade to V1 - What should it do when changing settings? preserve the V2 settings? dump them? Do some of the V2 settings change the impact/meaning of the V1 settings? Are these decisions to be made by your app or your installer?
Anyway, all that aside, I'd say you need at the least:
A central server/farm with complete files for every version of your App and some API/Web Service which allows the installer to retrieve files/filesets/??? as appropriate (You may be able to tie this into a source control system like svn)
Some way of specifying the desired post-install state of the system in an environment-agnostic way (Think install paths - /usr/??? - should the map to C:\Users\??? or C:\Program Files on windows? Also don't forget it might be a 64-bit machine so it could be C:\Program Files (x86).
A very clever installer written for multiple platforms with as much code re-use as possible (Java, Mono, ???)
The installer should do (simply):
Determine the desired version of the product.
Download/read the appropriate manifest.
Compare the desired situation with the current situation (NB: What is currently on the local system, NOT what should be on the system according to the current version's manifest)
Generate a list of steps to reconcile the two, taking into account any dependencies (can't set file permissions before you copy the file). You can make use of checksums/hashing/similar to compare existing files with desired files - thus only downloading the files actually required.
Possibly take complete backups
Download/unpack required files.
Download/unpack 3rd party dependencies - Later .Net Framework Version/Similar
Perform install steps in atomic a manner as possible (at the very least keeping a record of steps taken so they can be undone)
Potentially apply any version-jump specific changes (up/down-grade db, config files, etc.)
verify installation as much as possible (checksums again)
None of this addresses the question of what to do when the installer itself needs upgrading.
A technique I've used on Windows is that the installer executable itself is little more than a wrapper with some interfaces which loads the actual installer dynamically at runtime - thus I can move files about/unload/reload assemblies, etc... from within a fixed process that almost never changes.
As I said above, I am definitely not an expert, just a novice who's done some of this myself. I sure you can get more complete answers from others but I hope this helped a little