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.
Related
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 6 months ago.
Improve this question
Why does the standard C library need to feature multiple header files? Would it not be more user friendly to consolidate it into one header file?
I understand that it is unnecessary to include function prototypes / global variables that go unused, however, won't the compiler eventually remove all of these references if they're unused?
Maybe I'm underestimating the size of contents spanning all of the header files. But it seems like I'm always googling to figure out what header I need to #include.
Edit: The top comment references a size of 50MB which appears to be untrue. The C library is relatively concise compared to other language's standard libraries hence the question.
// sarcasm ON
Build your own #include "monster.h" that includes all you want from the collection.
People write obfuscated code all the time. But, you won't be popular with your cohort.
// sarcasm OFF
The real reason? C was developed when storage was barely beyond punch card technology. A multi-user system might have 1/2Mb of (magnetic) core memory and a cycle time that is now laughable.
Yet, reams of C code was developed (and the story of the popularity of UNIX well known.)
Although new standards could change the details (and C++ has), there is an ocean of code that might/would no longer be able to be compiled.
Look up "Legacy".
There are (too many) examples of code in the world where the usual collection of, say, stdio.h, stdlib.h, etc. have been "hidden" inside #include "myApp.h". Doing so forces the reader to hunt-down a second file to verify what the &^%&%& is going on.
Get used to it. If it was a bad practice, it would not have survived for ~50 years.
EDIT: It is for a similar reason that "functions" have been "grouped together" into different libraries. By extension, pooling those libraries might make things a tiny bit "less cluttered", but the process of linking may require a supercomputer to finish the job before knock-off time.
EDIT2: Brace yourself. Cleanly written C++ code often has a .h and a .cpp for every class used in the app. Sometimes "families" (hierarchies) might live together in a single pair of files, although that can lead to boo-boo's when the coder is having a bad day...
Somewhat annoyingly, I keep getting this warning (for some oh 20 modules or so, polluting the build output I'd otherwise see without scrolling such as actual ghc warnings etc):
"The following modules should be added to exposed-modules or other-modules in proj-name.cabal
with:
a freshly created (via stack new proj-name simple) project,
with its .cabal set to only contain an executable proj-name (no library),
where I then right after stack new .. copied the src files/sub-dirs over from a non-stack/cabal project.
What's the supposed workflow here, am I seriously to manually keep those modules listings in the .cabal in sync with my module files?
In this thread someone suggests "the modern answer is Stack (and hpack)" but I was really hoping stack alone would somehow suffice here or could be set up to. If I am to set up yet-another (3rd after stack and thus implicitly cabal) tool just for builds, might as well go back to build scripts invoking ghc..
So the question: how can the overall very flexible powerful and robust stack help overcome also this cabal abomination, too? =)
Does prolog have built-in predicates, which can import and export complete files during runtime?
I need predicates like "assert" and "retract". The problem is that "assert" and "retract" only manipulates a dynamic list, not a complete file.
I know two ways of how to include a file into another:
:- include('file.pl').
:- consult('file.pl').
This mostly happens at the beginning of a code.
Can I use these predicates in the middle of my code? (I think the consult predicate worked, but I had problems with the include predicate...)
And is there any chance how to exclude/"delete" the included file again? (the more important question)
I found the built-in predicate "delete_file/1", which literally deletes the file (from your memory) - this is not what I wanted. But the file still was not deleted from the current program, only from the memory, which was really strange...
I hope someone can help me, because I could not find anything else than the predicates explained above. Thanks!!
Not all prologs recognize consult (e.g., GNU Prolog doesn't). But include/1 and consult/1 does seem to work mid-file with SWI Prolog, and include/1 in GNU Prolog.
Undoing a file consult is another question. Prolog consults the file, hauling in all the facts and predicates, and the fact that it was all from a particular file is forgotten when the operation is done. It's as if you typed them all in by hand. It has no record that any particular set of predicates or facts were from a particular consulted file. To "undo" any such facts or predicates, you would have to do a retract/1 or retractall/1 on the items asserted as a result of the include or consult. That might be simple if the functors you are consulting are unique, because then you might get away with retractall(my_unique_functor(_,_)). or retract(foo(_)).. But if you have a mix of them (existing and newly asserted) and want to be selected, you'll have to sort them out.
Logtalk includes a programming example, "named_databases", that supports the functionality you're looking for:
https://github.com/LogtalkDotOrg/logtalk3/tree/master/examples/named_databases
This example supports ECLiPSe, Lean Prolog, SICStus Prolog, SWI-Prolog, and YAP and it uses in its implementation the module system (except in Lean Prolog, which provides natively most of the functionality) for the actual databases and Logtalk's term-expansion mechanism for optimizing the usage of named database predicates.
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.
How can I extract just the required functions from a pile of C source files? Is there a tool which can be used on GNU/Linux?
Preferably FOSS, but the GNU/Linux is a hard requirement.
Basically I got about 10 .h files; I'd like to grab part of the code and get the required variables from the header files. Then I can make a single small .h file corresponding to the code I'm using in another project.
My terms might not be 100% correct.
One tool that you may or may not be aware of is cscope. It can be used to help you.
For a given set of files (more on what that means shortly), it gives you these options:
Find this C symbol:
Find this global definition:
Find functions called by this function:
Find functions calling this function:
Find this text string:
Change this text string:
Find this egrep pattern:
Find this file:
Find files #including this file:
Thus, if you know you want to use a function humungous_frogmondifier(), you can find where it is declared or defined by typing its name (or pasting its name) after 'Find this global definition'. If you then want to know what functions it calls, you use the next line. Once you've hit return after specifying the name, you will be given a list of the relevant lines in the source files above this menu on the screen. You can page through the list (if there are more entries than will fit on the screen), and at any time select one of the shown entries by number or letter, in which case cscope launches your editor on the file.
How about that list of files? If you run cscope in a directory without any setup, it will scan the source files in the directory and build its cross-reference. However, if you prefer, you can set up a list of files names in cscope.files and it will analyze those files instead. You can also include -I /path/to/directory on the cscope command line and it will find referenced headers in those directories too.
I'm using cscope 15.7a on some sizeable projects - depending on which version of the project, between about 21,000 and 25,000 files (and some smaller ones with only 10-15 thousand files). It takes about half an hour to set up this project (so I carefully rebuild the indexes once per night, and use the files for the day, accepting that they are a little less accurate at the end of the day). It allows me to track down unused stuff, and find out where stuff is used, and so on.
If you're used to an IDE, it will be primitive. If you're used to curses-mode programs (vim, etc), then it is tolerably friendly.
You suggest (in comments to the main question) that you will be doing this more than once, possibly on different (non-library) code bases. I'm not sure I see the big value in this; I've been coding C on an off for 30+ years and don't feel the need to do this very often.
But given the assumption you will, what you really want is a tool that can, for a given identifier in a system of C files and headers, find the definition of that identifier in those files, and compute the transitive closure of all the dependencies which it has. This defines a partial order over the definitions based on the depends-on relationship. Finally you want to emit the code for those definitions to an output file, in a linear order that honors the partial order determined. (You can simplify this a bit by insisting that the identifier you want is in a particular C compilation unit, but the rest of it stays the same).
Our DMS Software Reengineering Toolkit with its C Front End can be used to do this. DMS is a general purpose program transformation system, capable of parsing source files into ASTs, perform full name resolution (e.g., building symbol tables), [do flow analysis but this isn't needed for your task]. Given those ASTs and the symbol tables, it can be configured to compute this transitive dependency using the symbol table information which record where symbols are defined in the ASTs. Finally, it can be configured to assemble the ASTs of interest into a linear order honoring the partial order.
We have done all this with DMS in the past, where the problem was to generate SOA-like interfaces based on other criteria; after generating the SOA code, the tool picked out all the dependencies for the SOA code and did exactly what was required. The dependency extraction machinery is part of the C front end.
A complication for the C world is that the preprocessor may get in the way; for the particular task we accomplished, the extraction was done over a specific configuration of the application and so the preprocessor directives were all expanded away. If you want this done and retain the C preprocessor directives, you'll need something beyond what DMS can do today. (We do have experimental work that captures macros and preprocessor conditionals in the AST but that's not ready for release to production).
You'd think this problem would be harder with C++ but it is not, because the prepreprocessor is used far more lightly in C++ programs. While we have not done extraction for C++, it would follow exactly the same approach as for C.
So that's the good part with respect to your question.
The not so good part from your point of view, perhaps, is that DMS isn't FOSS; it is a commercial tool designed to be used by my company and our customers to build custom analysis and transformation tools for all those tasks you can't get off the shelf, that make economic sense. Nor does DMS run natively on Linux, rather it is a Windows based tool. It can reach across the network using NFS to access files on other systems including Linux. DMS does run under Wine on Linux.