Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Every software I have seen, contain copyright statement at the beginning of a file and takes pretty much lines of comment. Therefore you have to scroll down to see the code, which is a bit annoying, especially when code itself is very short.
I think that it would be nicer to keep copyright statement at the bottom of a file and join all clauses into single (or few) lines. This would be just to satisfy formal issues. Easy to read version is available in LICENSE file.
But I haven't seen such practice so far. Is it just a tribal custom or is there a reason for that?
edit: Here's <list> from GNU STL library as an example:
// <list> -*- C++ -*-
// Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING. If not, write to the Free
// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
// USA.
// As a special exception, you may use this file as part of a free software
// library without restriction. Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License. This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
/*
*
* Copyright (c) 1994
* Hewlett-Packard Company
*
* Permission to use, copy, modify, distribute and sell this software
* and its documentation for any purpose is hereby granted without fee,
* provided that the above copyright notice appear in all copies and
* that both that copyright notice and this permission notice appear
* in supporting documentation. Hewlett-Packard Company makes no
* representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*
*
* Copyright (c) 1996,1997
* Silicon Graphics Computer Systems, Inc.
*
* Permission to use, copy, modify, distribute and sell this software
* and its documentation for any purpose is hereby granted without fee,
* provided that the above copyright notice appear in all copies and
* that both that copyright notice and this permission notice appear
* in supporting documentation. Silicon Graphics makes no
* representations about the suitability of this software for any
* purpose. It is provided "as is" without express or implied warranty.
*/
/** #file list
* This is a Standard C++ Library header. You should #c #include this header
* in your programs, rather than any of the "st[dl]_*.h" implementation files.
*/
#ifndef _GLIBCXX_LIST
#define _GLIBCXX_LIST 1
#pragma GCC system_header
#include <bits/functexcept.h>
#include <bits/stl_algobase.h>
#include <bits/allocator.h>
#include <bits/stl_construct.h>
#include <bits/stl_uninitialized.h>
#include <bits/stl_list.h>
#ifndef _GLIBCXX_EXPORT_TEMPLATE
# include <bits/list.tcc>
#endif
#ifdef _GLIBCXX_DEBUG
# include <debug/list>
#endif
#endif /* _GLIBCXX_LIST */
While it's not necessarily a custom or requirement, standards tend to dictate that comments should proceed any code definition. Take a look at NDOC notation as an example.
In the case of a copyright you generally want people to read it before they proceed with using your code (EULAs are always displayed at the beginning of an installer). If a copyright notice is placed at the bottom of the code definition there's a good chance it will be overlooked.
If you put the copyright comment at the beginning of a file, the copyright statements are visible when somebody opens the file (if who opens the file doesn't use an editor that automatically goes to the last visited line). If the copyright comment would be placed at the bottom of the file, people would need to scroll until the end to see the copyright, which is the first thing somebody should be interested to see.
Related
/* xxx/xxx.c
*
* This file is part of xxx.
*
* xxx is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* xxx is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with xxx. If not, see <https://www.gnu.org/licenses/>
*/
this comment is at the beginning of my code, but clang-format will trail space at the end of each line. how to make clang-format ignore comments?
You can disable formatting on a piece of code using // clang-format off and then using // clang-format on to turn it on again.
// clang-format off
/* xxx/xxx.c
*
* This file is part of xxx.
*
* tripl is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* tripl is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with xxx. If not, see <https://www.gnu.org/licenses/>
*/
// clang-format on
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
There is an elisp project on github I have forked. Some of the source files and functions I don't want to change, some I want to change drastically, and others only slightly. The original copyright at the top of each source file mentions the project that it came from.
1) Should I rename all functions or only those that have code changed (no matter how minor)?
2) If I modify some functions within a file but not all/most should I rename the file and change the copyright at the top to reflect my project instead of the original?
3) If many/all of the files get renamed how should I give credit to the original authors (other than their commits showing up in git log)?
notes
I'm forking due to wanting to take the code in a very different direction from the original's stated purpose and my fork would not be pulled in by the original authors.
The original project and my fork both use GPLv3
Elisp code by convention prefixes the name of functions/variables with the project name to avoid namespace collisions.
** Edit **
Found some additional information after posting...
How to rebrand/copyright a forked project (GNU/GPL)?
1) Sure. In fact, not changing it at least a little would imply it's the original project, which is a bad idea.
2) You can't remove copyright notices. Add yours on top.
3) Why do you want to remove the reference to the old project? It's a suggestion, but removing it would be impolite and potentially misleading. The Open Source/Free Software communities value correct attribution.
Need advice on attribution/copyright of heavily modified OSS code (BSD, Apache, etc) in source headers
If you copy even a single function out of a file, unless you could convince a court that the function was too trivial for copyright to apply, then the license of the source file stays with the function
Between Stefan's answer and these stackoverflow posts I've decided to:
1) Rename all files and functions even if unchanged to use my project's name.
2) Keep the original copyright as is in all existing files (and a few new files resulting from moving the old code into more logical subdivisions)
3) Add my copyright to all files new and old.
4) Make a note just above the old copyright to check git history before a certain commit id to see the original project at the time of fork as well as a reference to the url of the original project to see the most up to date version.
I think these changes should make clear that this is a separate project while maintaining credit where due to the original and avoiding any namespace conflicts or copyright violations.
Copyright is cumulative (i.e. as long as you keep using some of the original code in the new code, the original's author still applies to that part of the code). So don't replace his copyright with yours, but just add yours next to his instead.
I'm curious if someone can point me in the right direction here. I'm learning about computer systems programming (the basics) and I'm trying to trace code through different levels to see how each interacts with the other. An example would be calling the fgets() function in C or getline() in C++ or similar. Both of those would make calls to the system right? Is there an easy way to look at the code that is called?
I'm working on Unix (Ubuntu). Is this something that is proprietary with Windows and Apple? Any good resources out there for this kind of thing? As always, thanks guys!
At least in the UNIX world, the answer is fairly easy: "Use the Source, Luke".
In your example, you would look at the sources for, say, fgetc(). That's in the C standard library, and the easiest way to find the source is google something like "C libraary fgets() source".
When you get that source, you'll see a bunch of code handling buffers etc, and a system call, probably to read(2). The "2" there tells you it is documented in Chapter 2 of the manual (eg, you can find it with man 2 read).
The system call is implemented in the kernel, so then you need to read the kernel source. Proceed from there.
Now, what you need to find this all without having to read randomly about in the sources (although that's the way a lot of people have learned it, it's not very efficient) is to get hold of a book on Linux like Kerrisk's The Linux Programming Interface, which explains some of these things at a somewhat higher level than just the source.
Something fgets is located within libc. That is, it's a userland library linked with most C binaries. Check out glibc, which is currently the most common implementation.
Eventually, libc will start making system calls to the kernel. You can get the source at kernel.org. Check out KGDB for kernel debugging. The simplest way to to do kernel debugging is to use a second machine connected via null model cable.
On Windows, you could get some insight with a few things. First you'd need something called symbol files that correspond to the binaries you'd like to investigate. Symbol files associate textual names with the global/stack/heap variables floating around a program. So to map the address in memory to the function fgets, and see fgets in certain programs you'd need to have the symobls for the version of Microsoft's implementation of the C std library. Lucky for you MS makes their symbols freely available
Second you would need to capture a callstack that dove deeper than fgets. The most obvious way to do this would be to be a Microsoft developer and introduce a crash into a deep MS dll, then analyse the crash dump with a debugger and symbols, but unfortunately we can't do that. What you can do is use whats called a sampling profiler, as in this one freely available from Microsoft. A sampling profiler profiles your code by taking periodic snapshots of the callstack of your program. Using symbol files from Microsoft, we can digest that callstack into something meaningful.
Given those 2 pieces of info, it wouldn't be hard to construct a program and get some insight into what fgets calls. You can then use the sampling profiler with Microsoft's symbols to get an idea of whats going on during your program.
Along these lines I constructed the following program to try this out:
int FgetSTest()
{
FILE* fp;
fp = fopen("C:/test.txt", "w");
char data[100];
int sum = 0;
for (int i = 0; i < 100; ++i)
{
fgets(data, 100, fp);
sum += data[0];
}
fclose(fp);
return sum;
}
int _tmain(int argc, _TCHAR* argv[])
{
int sum = 0;
for (int i = 0; i < 100; ++i)
{
sum += FgetSTest();
}
std::cout << sum;
return 0;
}
Assuming you've compiled this into a program (I've compiled it into one called perfPlay.exe) you can run MS's sampling profiler on the exe as follows:
C:\path\to\exe>vsperfcmd /start:sample /output:perfPlay.vsp
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
C:\path\to\exe\>vsperfcmd /launch:perfPlay.exe
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
Successfully launched process ID:3700 perfPlay.exe
sum is:40000
C:\path\to\exe>vsperfcmd /shutdown
Microsoft (R) VSPerf Command Version 9.0.30729 x86
Copyright (C) Microsoft Corp. All rights reserved.
Shutting down the Profile Monitor
------------------------------------------------------------
Get profiler output, notice the "symbolpath" switch to point the command to Microsoft's symbol server:
C:\path\to\exe>vsperfreport perfplay.vsp /summary:all /symbolpath:srv*c:\symbols*htt
p://msdl.microsoft.com/download/symbols
You can examine the csv directly of the caller-callee report, or find a good viewer, like the one I've been working on, and you can get an idea of where fgets spends most of its time:
Sadly, not terribly insightful. Unfortunately, one of the problems you'll run into with this approach is that many of the functions fgets calls in release mode could very well be inlined -- that is they are pretty much removed as functions from the final program and their contents directly "pasted" in to where they're used.
You could try repeat the above in debug mode to see what you get, as there's less chance of inlining.
First things first; this task will require good tools. I find etags, cscope, and gid (from GNU idutils) indispensable tools when navigating source. Figure out how to integrate one or more of these into your favorite editor or IDE. Switch editor or IDE to get these features, there's no excuse for poor tools. If you're looking for advice on one, I love vim, a vast many people argue for emacs, and there's some folks who love their Eclipse.
You'll want the sources locally; lxr is an amazing tool, but the latency involved in repeated web requests gets tiring for any serious work. On Debian-derived systems, this is pretty easy; change directory to wherever you wish to store the source and run apt-get source eglibc to download the glibc sources. I suggest getting the kernel sources via a tarball from http://www.kernel.org or cloning the master git repository (a better choice if you want to read changelogs or easily get updates -- though it does expand to 2.7 gigabytes as of June 2012, so it obviously isn't for everyone).
Once you've built tags files for the C library, you can just run: vim -t fgets and it will open libio/bits/stdio2.h directly to the source for the fgets() routine. (It is much less readable than you may hope.) Follow these around until you eventually get to a read() system call. (It may take a while.)
Now switch to the kernel sources. Look in fs/read_write.c for this this:
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
One downside to the way the kernel uses macros to define system calls is that it complicates searching for functions. vim -t can't find this directly. The easiest thing to do when looking for system calls is to run gid -s SYSCALL_DEFINE | grep read. (If you find a better tool, let me know.) Once you've found the system call entry point, it'll be far easier to read the rest of the kernel source. (I generally find it more legible than glibc sources, too -- though the days of being five or six function calls away from the block-level bread() call are long gone.)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I ported some code from C to C# and I also added some new features into the ported code. Original code is under MPL license.
This is original source code license terms:
/*
* file name
* Version .....
*
* Copyright (c) 2004-2012 by XXX YYY
*
* The contents of this file are subject to the Mozilla Public License Version
* 1.1 (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
* http://www.mozilla.org/MPL/
*
* Software distributed under the License is distributed on an "AS IS" basis,
* WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
* for the specific language governing rights and limitations under the
* License.
*
* The Original Code is file.c
*
* The Initial Developer of the Original Code is XXX YYY.
*
* Portions created by XXX YYY are Copyright (C) 2004-2012
* XXX YYY. All Rights Reserved.
*
*/
Can i change the license for the ported code and include original source code license terms of the original source code this way:
//
// test.cs
//
// Author:
// "My Name" (my#email.com)
//
// Copyright (c) 2012 My Name
//
// Permission is hereby granted, free of charge, to any person obtaining
// a copy of this software and associated documentation files (the
// "Software"), to deal in the Software without restriction, including
// without limitation the rights to use, copy, modify, merge, publish,
// distribute, sublicense, and/or sell copies of the Software, and to
// permit persons to whom the Software is furnished to do so, subject to
// the following conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
// MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
// LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
// OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
// WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
//
// Parts of this source code are ported from C to C# by "My Name".
//
// The Original Code is file.c (http://original-source-code-link.com);
// and under Mozilla Public License Version 1.1 (http://www.mozilla.org/MPL/)
// The Initial Developer of the Original Code is XXX YYY (xxxyyy#email.com).
Porting some code is translating some code (compare that with translating a book of somebody else) and therefore subject to copyright. You are creating a derivative work.
And btw. never ever change author credits and copyright notes. That's a no-go, you are asking for trouble legally doing so. So copy the originally statement verbatim, do not cripple it.
Also you normally can't put a file under a MIT-like license while parts of it are under MPL AFAIK but IANAL JASD.
Why no just license the file under MPL as well? That is probabyl the best suggestion one can give you. For everything else you should go straight to your lawyer.
http://en.wikipedia.org/wiki/Mozilla_Public_License
If you seriously want to put that part of the work that is your work under your license, you have to make very visible where your work is, and where the original work is.
I find it extremely hard for a port/translation to make that visible and I doubt that this is possible.
And that's only technically, because even if you are able to, this says nothing about license compatibility. Sure you need to have license compatibility as well.
So because of these two reasons, you should really consider to release it under the same license as MPL has copyleft.
A port is simply a modification of code.
You ARE in violation of section 3.1 and 3.4 of the MPL, which state respectively:
All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. You must inform recipients that the Source Code Form of the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License. You may not attempt to alter or restrict the recipients’ rights in the Source Code Form.
...
You may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies.
So the answer is no, your code must keep the terms of the MPL, and keep the original comment block.
By saying that you are porting the code you are clearly making a derivative work, in which case you need to comply to the original code's license.
However, it is possible to make a "clean room reimplementation" of an API, where you can use whatever license you wish. It basically means you print the Doxygen documentation, and code only based on this. If anybody questions your approach you will need to prove how you proceeded, ie. using SCM commit records, etc.
Usually it's not worth the case to do that, as it demands as much work as developing the original software.
Porting is only a fraction of the effort of developing; you don't have to design, and very little chance of introducing bugs. So why do you want to take all the credit ? I bet XXX YYY would be pissed off. I would !
From the MPL FAQ:
Q9: I want to distribute (outside my organization) MPL-licensed source
code that I have modified. What do I have to do?
To see the complete set of requirements, read the license. However,
generally:
You must inform the recipients that the source code is made available
to them under the terms of the MPL (Section 3.1), including any
Modifications (as defined in Section 1.10) that you have created.
You must make the grants described in Section 2 of the license.
You must respect the restrictions on removing or altering notices in
the source code (Section 3.4).
Seeing as you first ported the source and then altered it, you need permission of the original author for the port. Once you have that, you'd need to follow the guidelines in the answer above because you modified the code.
You might also want to take a look at this question.
So, I'm trying to stuff some default text into a user input using readline, and having trouble getting it to work on OSX 10.5:
// rl_insert_text_ex.c
// gcc -o rl_insert_text_ex rl_insert_text_ex.c -lreadline
#include <stdio.h>
#include <readline/readline.h>
int my_startup_hook(void) {
return rl_insert_text("ponycorns");
}
int main(int argc, char *argv[]) {
char *line;
rl_startup_hook = (Function*) my_startup_hook;
line = readline("What's your favorite mythical animal? ");
if (NULL == line || '\0' == *line) {
printf("Nothing given... :(\n");
}
else {
printf("That's funny, I love %s too!\n", line);
}
return 0;
}
This code doesn't even compile on 10.4 (no definition for _rl_insert_text on 10.4, which is a bit of a bummer), but does compile on 10.5. However, the rl_insert_text()'d text is never shown to screen, nor returned as user input. The callback is being used and rl_insert_text() returns the proper value, (thank you, printf), so I'm not sure what's going on here.
I checked /usr/include/readline/readline.h, and rl_insert_text() is under:
/* supported functions */
which is confusingly under:
/*
* The following is not implemented
*/
So am I SOL, or am I just doing it wrong?
Unfortunately, you may be out of luck, at least with the readline library included in OS X. Due to license compatibility issues, Apple uses libedit, which (apparently) provides incomplete readline emulation. (This library is documented with the name "editline" in the readline.h included with OS X.)
GNU Readline Library (the "one true" readline library) is under GPL, which (being a copyleft license) does not play well with code that is not entirely open-source. If it comes down to (A) open-sourcing all of Xcode, OS X, etc. or (B) using a knock-off of what you're really like to use, Apple (like most companies) is always going to choose B. It's a bummer, but that's life.
Personally, I think this is one reason that GPL'd code is somewhat of a blight on the land, since in the act of "sticking it to the man", it often also withholds the code from the masses who purchase software. The {BSD,MIT,Apache}-style licenses are much more conducive to use in closed-source systems, and still allow commercial entities to contribute back patches, etc. My guess is that libedit hasn't received enough attention to be fixed properly. Community patches would certainly be welcome, although it's so much nicer if we can use code without having to hack on it ourselves... ;-)
BTW, the same thing applies to other GPL projects — as long as {git,mercurial,bazaar} remains under GPL, don't hold your breath for Apple to ship integration for them in Xcode. :-(
UPDATE: The new Xcode 4 offers git support. Huzzah! My understanding is that this is due to the new plugin architecture which isolates GPL'd code from the main Xcode codebase. However, I emphasize that copyleft licenses are still the wrong solution for code that should benefit everyone. Obviously some people don't agree (you're a pal, anonymous downvoter) but the fact is that GPL can restrict freedoms too — usually its different ones than closed-source/proprietary software generally does, but GPL is also quite effective at preventing illegal use of source code... The difference is a feeling of moral superiority.