Hot answers tagged

22

Most version control systems (like git) don't allow to split the repository into "visible" and "invisible" parts. What you can do with git is to have the public part in one repository, publicly accessible, and the private part in another one. The second, closed, one can then include the first, public, one as a submodule (see git-submodule(...


20

GPLv3 directly addresses your question, so no speculation is required. Conveying unmodified code is covered in s4, and conveying other forms than source code in s6. s6 says that You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of ...


7

A common solution I've seen is to design the core for extensibility and put the closed-source elements into extensions. Since the closed-source portions of the product interact only through the extension interface, the source code for them doesn't need to be stored anywhere near the core's source code. For example, an open-core web application might come ...


4

No, you cannot "just" change the license to GPLv3. The MPL2.0 is a per-file strong copyleft license, with an opt-out provision to incorporate MPL-licensed files into a larger project that is under the GPL license. This means that if you only made changes to files containing MPL-licensed code, then you cannot change the license. Also, if the author ...


4

The fundamental problem with all copyleft licences is that they have to have a fair amount of legal boilerplate in them. GPLv2 puts it rather well, to my mind, when it says in the preamble To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to ...


4

The EPL is not compatible with the GPL. The MPL is compatible with the GPL. For that reason I would recommend the MPL if you could choose between the EPL or MPL.


3

I'd say the specific act of removing git history is unlikely to be copyright infringement; the restriction in the MPL (section 3.4) is against removing or altering copyright notices, and a git commit username/e-mail/etc is definitely not a copyright notice. However this case is messy because (as far as I can see) you haven't followed the MPL closely. In ...


3

Allow me to share a fragment from my book Entreprenerd: Building a Multi-Million-Dollar Business with Open Source Software as an introduction to my answer: I developed two PDF libraries. I started writing the first one ("rugPdf") in 1998 and I chose the LGPL when I released it. The MPL was written in the same year, but I wasn't aware of its ...


3

The principle is universal, in the sense that any licence that tries to place restrictions on how you can use what copyright law defines as a derivative work will be limited by how copyright law defines derivative work, and the reach of such licences will therefore be co-extensive. The FSF FAQ admits that it uses the legal boundary when it writes "This ...


3

If I got it right, I can ship my "larger work" under proprietory license without giving the source code away. But I must inform my customers that the software they receive contains MPLed dependencies and the links to their source codes. Is that correct? Yes, that is correct, in so far that the MPL requires you to inform your users where/how they ...


3

From Open Source Initiative website FAQs: https://opensource.org/faq#copying-and-identity Does Open Source mean anybody else can use my name and logo? No, at least not any more than they could otherwise. Open Source is about software source code, not about identity. That is, letting people use your code under an Open Source license is not the same as ...


3

Am I still the legal "owner" of the code I wrote back then although it was published in an MPL 2.0 codebase first? Yes. It is actually quite hard to lose your copyrights. You have to explicitly and knowingly sign them away and just contributing to a project is not enough to lose your rights. If you are the sole copyright holder to some code, then ...


2

The whole can only be distributed under the intersection of the rights granted, i.e., the most restrictive licence of the pieces. That would be GPL. Make sure you include all licenses, and state where each piece of your chimaera comes from (so any would-be enhancer/user of the code knows the provenances and attached restrictions).


2

According to the MPL 2.0 FAQ in Q14, Yes, with three requirements The MPL software isn't incompatible with GPL, either because the original author specifically mark it as such, or it was originally released on MPL 1.1 without dual/tri-license with GPL It's actually combined with GPL software, instead of merely switching the license. The MPL-licensed part of ...


2

Desktop applications does access have to be provided through the user interface (GUI), or can it just be through program files? There is no requirement that the source code can be obtained from within the application or even that it gets installed on the end-user's system together with the application. If the application is typically downloaded from a ...


2

Effectively yes, although I suggest you are much more explicit about exactly which material you intend to place under each license than just throwing some license files in some directories. In particular, there is no real concept of an "MPL 2.0 repository" - copyright (and thus open source licensing) exists at a more granular level than that of a ...


2

This situation is common at large software companies which contribute to open source projects, so there are some tools you can find specifically to migrate between open and closed repositories. I have used these tools. They generally work like this: You have your internal repository. This could be a monorepo containing an open-source subproject, or it could ...


2

I strongly suggest that you do not alter or modify any license language to create your own, like you suggested above ("I'm also considering modifying MPL 2.0"). That should only be done by lawyers. And any proprietary license has negative impact on the re-use of your code by others. CPAL is in a niche, not many are using it. You need to be very ...


1

I suggest you add the MIT license in that directory and in addition add proper SPDX identifiers in each of the files in order to create an unambiguous situation.


1

No, you cannot assume that the definitions and examples that have been published in relation to GPL are universal and also applicable to other licenses. If that was the case then you would see respective wording on the webpage of these other licenses. The answer to Q11 in the MPL 2.0 FAQ is pretty clear is pretty clear about your second question. The answer ...


1

Reading through both licenses, I found several minor differences. As stated by JNic, the Mozilla Public License Version 2.0 is compatible with the GPL by default unless provided with the notice described in MPL Exhibit B (see MPL section 1.4), while the Eclipse Public License - v 2.0 is by default incompatible with the GPL unless provided with the notice ...


Only top voted, non community-wiki answers of a minimum length are eligible