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.
Related
"Rule 2.3: A project shall not contains unused typedef declarations: If a type is declared but not used, then it is unclear to a reviewer if the type is redundant or it has been left unused by mistake."
After generating code in matlab simulink via AUTOSAR, I use Misra rule check and Polyspace code prover to check the generated code. Is there a way for Misra to remove the RTE .h file from its list and check the rest of the libraries and code? (I do not want to MISRA check the RTE.h file. but how ??)
This is typically a tool-specific activity...
Depending on the tool, you can specify that file to be not checked, or include appropriate annotations in the file to switch off specific guideline checks.
Also, as Rule 2.3 is Advisory, in accordance with MISRA Compliance, you can Disapply it (with justification) either for a single file or more generally. Again, that would be implemented within your tool.
I can give guidance on one particular tool (see profile), but you're better talking with your vendor, if the manual is not helpful.
As an aside:
MISRA is due to release a Guideline Reclassification Plan for automatically generated code - this proposes that users Disapply Rule 2.3 for auto-code.
If you want to claim MISRA Compliance, the analysis needs to include all files (including your RTE.H) although some relaxation is permitted for adopted code (including auto-generated code).
See profile for affiliation.
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.
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 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.
I know that the password field in /etc/shadow is prefixed with ${number}$ if it is not simply DES encrypted. What I am not able to find is a table that correlates the type of encryption to a given number.
For instance, $1$ would indicate MD5. Its the rest that escape me (i.e. SHA1, SHA256, Twofish, Blowfish, etc)
I've gone through the source to passwd and chpasswd as well as glib, but I'm not finding what I'm looking for.
Would someone mind sharing a link to a web page, or even a clue as to where In glib I might find such a table? I need to progmatically update passwords from within a program without using system() or exec*() calls. I'd like to write original code because I want to keep a uniform 3 clause BSD license and full copyright over my code.
Forgive me if this is a duplicate. I found lots of questions regarding how to parse /etc/shadow, but none that specifically ask how to identify the encryption type of the second field.
Edit:
For reference, here is the announcement from the discussion group that moved forward implementing SHA (over DES) with support for BSD Blowfish.
The crypt(3) man page describes it in the NOTES section.