I've always heard about this possibility but I wonder how one would rewrite code, should the need arise. Wouldn't it be hard to do without effectively making a derivative work?
Suppose that you remove the code, reimplement it but end up with something that's extremely similar to the original (which is very likely since after all you're doing the same thing). Couldn't the original author argue that it's still their code? How do you prove that you did the work and just happened with the same code because that's just the most straightforward way to do it?
It seems like the only way to avoid the problem altogether would be to have some sort of clean room design:
- Dev A reads the code to be removed, writes a spec for the functionality.
- Dev A removes the code.
- Dev B takes the truncated code and the spec and implements the feature.
But that seems very painful to do cleanly, in particular one could argue that B should be a third party who is not intimately familiar with the codebase, otherwise it could be argued that they knew the previous code.
This is an issue GNU has faced, they recommend optimizing for different things:
> If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can’t write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results.
> For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). — https://www.gnu.org/prep/standards/standards.html#Reading-No...
In fact RMS had experience from his competition with Symbolics: http://www.gnu.org/gnu/rms-lisp.en.html#foot-6
> The Symbolics source code was available at MIT, where I was entitled to read it, and at first that's how I found out about their changes.
> But that meant I had to make a special effort to solve each problem differently, in order to avoid copying Symbolics code. After a while, I concluded it was better not to even look. That way I could write code in whatever way was best, without concern for what might be in Symbolics' code.
(of course, this applies more to larger utilities, inopinatus’ comment https://news.ycombinator.com/item?id=24955918 should come in handy for smaller code snippets)
This was a factor in Intel's case with NEC over the microcode of their 8086 clone, and the judge ruled in NEC's favour, finding that similarities dictated by functional constraints were (subjectively) not creative expressions i.e. copyright did not apply.⁽¹⁾
Note this relates to copyright, does not extinguish patents, and actually relying on this precedent may require bottomless legal resources.
⁽¹⁾ NEC v. Intel: Breaking New Ground in the Law of Copyright. Contreras, Handley, & Yang; Harvard Journal of Law & Technology vol. 3, page 213 (1990). http://jolt.law.harvard.edu/articles/pdf/v03/03HarvJLTech209...
1. A commit to plainly remove the functionality (or lines of code)
2. A developer would rewrite the code with a set of variables they cannot use, but I suppose they'd also code without the original implementation as reference.
Each individual developer's implementation should be different enough that it would be easy to tell that it was independent crafted, although something like this hasn't been tested in court (at least to my knowledge!)
If the developer who does the rewrite uses the original as a reference, it will be likely that enough of the structure will creep through that the project will be at legal risk.
If you give me a sequence of integers from 1 to 1000 (which is not a creative work and therefore not copyrightable), and I selectively delete some of the integers such that the differences between adjacent numbers contains a fun message in ASCII, and publish that sequence, the result is copyright because those particular deletions add a creative element.
But if I just deleted every alternate number in the sequence, that wouldn't be copyrightable because it's not creative. (Although you can imagine some scenario when doing so might be creative, it would need some reason why it was.)
Basically, if Dev B does a change that passes some threshold of creativity, then they have a claim. If they just go through and delete all the blank lines and reformat in a standard way, they probably don't.
In your example, I think it would depend on which 20 lines and whether they were trivial changes to figure out.
ETA: discussed here, with a more in-depth link: https://news.ycombinator.com/item?id=24051655
> For context, when NodeBB faced this possibility, we simply contacted every single contributor and asked nicely if they'd assign over their ownership of their contribution to us (note the use of the word "assign", not "license", a license is revocable, an assignment is not).
This is certainly the correct way to do hit. However, in this specific case, it appears that as of the current code, not many external contributions remain.
The author of the original issue in the meantime forked the repo and continued to document the issue there [1] as it was being constantly closed, but as is evident from his own `git blame` analysis, most of the contributions are from staff, and the external contributions are basically negligible.
There's one author with 30 LOC, one with 10 LOC, and the remaining 12 contributors average less then 4 LOC each.
[1] https://github.com/christianbundy/octotree/issues/1#issuecom...
Could anyone comment here? What's the threshold for this?
We almost had to do this once for our own proprietary codebase as we discovered during due diligence that we didn't have a proper copyright transfer agreement from several of our interns. Fortunately we were able to resolve this with them (by paying them some extra money to sign a CLA), if it wouldn't have worked we would've removed and rewritten the code instead. It's silly but legally it's doable.
Of course this strategy doesn't work if a large part of your codebase originates from third-party contributors, but from my experience Github projects receive mostly small/cosmetic PRs from non-core developers (not saying that those contributions are not valuable btw).
One contributor decided to fork straight away and then link to it in an issue rather than adding a pull request. Eh, whatever, I didn't like it so much at the time but we came to an agreement, and the person who forked did a great job maintaining the theme.
It became popular enough that some more prolific emacsers caught wind, and the project became more integrated. As you might know, emacs is hardcore GPL, so this basically demanded a relicense. This was a few years after I started the project back in 2013 (I think), but I got pinged on the issue and messaged privately, and that was enough.
Turns out it wasn't necessary at the end of it all, but the process was quick and easy. Everything was cordial and I still have my name attached to it, which I guess is nice.
Not: Gratuitous (not contract) licenses are, by strong legal precedent, revocable by notice at will by the licensor. The content and context of the license (including the statement that it is irrevocable) may impact the effect given to revocation due to other legal principles, particularly promissory estoppel, but those are separate from revocability.
I'm not aware of any substantive distinction in the words "revocation", "termination", or the like, except with specific reference to 203. The question is whether you can show license if they plead infringement. In practice, they'll often plead breach, too.
Bare copyright licenses are largely theoretical here. If the terms of a unilateral grant include assurance of irrevocability, thats a strong fact for reliance and estoppel. If there's any question what the terms meant, it will be resolved by rules of contract construction, because it's not a public statute, and contract rules are the rules we have. There is a default rule, when the terms are silent, but it's just a default.
I have not been able to figure out why so few major ones do. Of the OSI approved licenses, I think the only ones that say so are AFL-3.0, AGPL-3.0, APL-1.0, APSL-2.0, Apache-2.0, CATOSL-1.1, ECL-2.0, EUDatagrid, EUPL-1.1, GPL-3.0, LiLiQ-P-1.1, LiLiQ-R-1.1, LiLiQ-Rplus-1.1, MulanPSL-2.0, NPOSL-3.0, OCLC-2.0, OSL-1.0, OSL-2.1, OSL-3.0, RPSL-1.0, SimPL-2.0, Simple-2.0, UCL-1.0, osl-1.0, osl-2.1, and the Unlicense.
Only AGPL, GPLv3, and Apache 2 from that list are really widely used.
Much less talked about than whether or not you can revoke a license, but probably as important for most open source licenses, is what happens if rather than trying to revoke the license you try to stop issuing new licenses?
Take GPLv2. Suppose I license some code I own to Alice under GPLv2. Later Alice gives a copy to Bob. Where does Bob's license come from?
GPLv2 says, "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions". GPLv3 has similar language.
If I say that I'm no longer going to issue licenses, and sue Bob for copyright infringement, what will his defense be?
He could argue that my license to Alice obligates me to issue a license to him. That falls under an area of law called the law of third party beneficiaries. Commonly you run into that in situations such as life insurance. I enter into a contract with a life insurance company to benefit specific third parties named in the contract, and that gives them some rights to sue to enforce the contract even though they are not a party to it.
I haven't seen much analysis of how the law of third party beneficiaries would work when applied to an open source license, but I'm not optimistic it would do much. Third party beneficiary rights tend to be weak at best if the third party is not a specific entity that the contract was made specifically to benefit. Someone downstream from Alice might be too vague to be a third party beneficiary, and it probably gets worse the farther downstream they are.
How about Alice? She could probably intervene to force me to honor my license to her and issue Bob a license. That's still going to put a damper on downstream redistribution. If you want to use the code without much legal worry, you'd need to make sure you got it from someone who would be willing to intervene if you got sued by me.
As with the revocation question, this too could be avoided be better drafting of the licenses. It's not a problem for Apache 2, for example, because the Apache 2 license grant is "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form".
The key in there is "sublicense". When Alice gives Bob a copy, Bob can get his license directly from Alice via her use of the sublicensing right I gave her.
I think that the only widely used open source licenses that do this are Apache 2 and MIT.
The GPL family specifically says that you cannot sublicense. I think they did this because they did not want people using sublicensing to give out licenses that did not include all of the GPL rights. Better would have been to allow sublicensing but to explicitly say that when you sublicense you must include all the rights that were in the license you received from upstream.
There is some case law around that in France. A software company makes GPL software or library, a contracting firm uses/modifies it, reselling the result to some clients.
In 2 cases I am aware of, the final client was the government and sued the contracting firm for breach of contract (the GPL is a contract) and won. (Winning is relative of course because the client can't use the software they paid for anymore and years are passing by in court).
The contract creates a chain of contractual responsibility, which I am not an expert in, but as far as I understand it opens any party to being sued by any other party.
Yes it means that GPL developers, by giving an open contract to anybody who is willing to take it, are pretty much opening themselves to be sued by the entire world.
In practice you sue for a purpose (maximizing damages :D) so the purpose guides whom to pursue on which grounds.
Now to answer your question... what happens if you decide to cancel the license? Well, you can't unilaterally cancel a contract on a whim.
Since the entire issue is that gratuitous licenses are, as a matter of law, revocable by notice regardless of their surface conditions, no, it wouldn't.
Such terms may make downstream licensees more secure that, in the event of revocation, courts will limit the effect of that revocation to avoid them incurring undue loss based on their reasonable reliance on the promises in the licenses while it was being offered under principles like promissory estoppel, though.
Edit: it just occurred to me that even if that is true, its salience here might depend on what "gratuitous" means and whether it applies to the license in question. (I reiterate that IANAL, so usual cautions). Proponents of copyleft licenses would claim that licensor and -ee are both receiving value. The licensor receives the value of improvements and enhancements to their original work while the licensee gets access to the base system and permission to modify it to their needs as well as sharing the licensor's protections and value on their own contributions. There seems to be a plausible argument (reminder: IANAL!) that an exchange of value has occured.
The Blue Oak Model License takes reliability a step beyond even Apache 2 and GPLs, with an express statement of irrevocability (in plain terms) and an express statement that terms are both conditions and contractual obligations. https://blueoakcouncil.org/license/1.0.0
If you're really down in the weeds, probably best to send me up an e-mail.
That would be the implication only if Linus was the sole copyright owner.
As it is, no one is asked to assign their copyright when contributing code to the Linux kernel, and the amount of code still remaining in the kernel that Linus has personally written himself is a rather small portion.
So if Linus were to "take his ball and go home" as it were, the affected code could be replaced.
That said, the multiplicity of contributors that retain their copyright to their contributions is also why relicensing the kernel to GPL 3 is largely a non-starter, even if Linus weren't opposed to it (and he is).
Note that "license" is a US concept that does not exist in Europe. Licenses here are systematically interpreted as full fledged contracts and fall under contract law.
Have to point out how this seemingly minor point in parenthesis really highlights how the comment is wrong and misplaced for a good chunk of the world.
P.S. Not trying to criticize here, just pointing out that copyright is vast and complex.
Well, English, long predating the US.
> that does not exist in Europe.
Well, it exists in the UK and, I'm fairly certain, Ireland.
> Licenses here are systematically interpreted as full fledged contracts and fall under contract law.
Do contracts in your jurisdictions not require mutual consideration or are licenses without mutual consideration facially defective? And is this gratuitous licenses in general don't exist or just in copyright?
European contracts (civil law) don't require consideration. Thus there's no need for a separate concept of license. (Allow me to skip the Europe vs UK debate for brevity ^^)
You can have a read at this article on a recent GPL court case in France, see section "French Law" that explains how some of the major differences https://thehftguy.com/2020/09/15/french-judge-rules-gpl-lice...
Guess I should write a dedicated article on licenses vs contracts so I can just point people to it. Is it something you would be interested in?
We do have rules for unilateral contracts and induced reliance, but they don't seem to come up much.
Artifex v Hancom also doesn't seem to offer much, since that there was a contract doesn't appear to be a point in dispute.
> ... The District Court found that Jacobsen had a cause of action only for breach of contract, rather than an action for copyright infringement based on breach of the conditions of the Artistic License. Because a breach of contract creates no presumption of irreparable harm, the District Court denied the motion for a preliminary injunction. > > Jacobsen appeals the finding that he does not have a cause of action for copyright infringement. ...
The appellate court vacated and remanded.
In its analysis:
> Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder. The Eleventh Circuit has recognized the economic motives inherent in public lenses, even where profit is not immediate. See Planetary Motion, Inc. v. Techsplosion, Inc., 261 F.3d 1188, 1200 (11th Cir.2001) (...).
Summing up the issue at bar:
> The heart of the argument on appeal concerns whether the terms of the Artistic License are conditions of, or merely covenants to, the copyright license.
In construing the terms of the license, the Federal Circuit explicitly references state contract law:
> Under California contract law, "provided that" typically denotes a condition.
Artifex v. Hancom is important in part because there wasn't any real dispute on contract enforcement. But the license at issue was GPLv2, whose author, the FSF, had long insisted it was just a license. From the terms:
> You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
In the order on motion for partial summary judgment, the court notes:
> The license was not free in the sense that there was no consideration owed under the agreement.
It then cites Jacobsen on "lack of money changing hands".
Later:
> Plaintiff gave away its Ghostscript program in consideration for the user making its software open source, which Defendant does not dispute it did not do. The record supports a finding that Defendant received a benefit (the use of Ghostscript) at Plaintiff's expense by depriving Plaintiff of the value of having Defendant's software open source.
> You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
There was activist fear about the dark power of contract law, as opposed to just copyright. And some political lobbying about the kinds of rules copyright owners should be able to impose and enforce under copyright law. They wanted to distinguish EULAs and NDAs—contract, bad—from licenses—good. Arguably, Moglen and friends were overtaken by legal decisions on both fronts.
Nimmer, our go-to treatise on copyright law, more openly acknowledges the deep links between copyright and contract law. Despite the fact that in the US, copyright law is federal (national) law and contract law is primarily state law.
For the vast majority of people and firms, all of this is political trivia.
Hypothetically if all the contributions were public domain code included in an AGPL project, then wouldn't the maintainer be within their rights to include those contributions in a closed-source version of the project?
Much of the discussion is assuming that because the project was AGPL, then the various contributions were AGPL as well. Whether or not that's the case is my question.
Note that the project currently doesn't state any license (there's no license.md). No idea if there was a license specified before when the contributions were made.
That a point of copyleft licenses. It's not a point of permissive licenses. Providing a certain degree of freedom to the direct licensee is the common shared point of open source licenses, permissive and copyleft.
Even very popular permissive licenses have been written with contribution front-and-center in mind. See, for example, the contribution-related terms of Apache 2. The definition of contribution. The built-in CLA. The compromise on scope of the patent grant.
1. Could you expand on how you asked the contributors and what reasons (and justifications) you gave them for it?
2. Didn’t they feel like their work was being “stolen” (sorry for using such an extreme word) for proprietary use?
IANAL, but this doesn't make much sense. Changing all lines that come from a single author can still result in a derivative work. In fact that even seems like a probable outcome, assuming that author's contributions were copyrightable in the first place.
If there are merge conflicts, it can be a lot of work for small (== no) gain, but it would put you in clear.
Barring something like a `git revert` (which depending on age of the commit might not even be possible), I would imagine a manual revert done to the best of your ability (followed by a rewrite) would be considered a good faith attempt.
Whether or not this would get you into legal trouble is left as an exercise to the reader. IA(also)NAL.
https://github.com/cregit/cregit https://lwn.net/Articles/698425/ https://cregit.linuxsources.org/
A copyright assignment gives power to the project owner to end up relicensing all those contributions as proprietary, effectively extracting free labor from contributions that were originally written under the implicit social contract of being part of the OSS community and all the Good Things that come with it.
I can't recall who it was now, but I remember reading about an open source project that makes considerable money from selling these licences, even though they weren't necessary (the licence was MIT). The licence even had an explanation around it stating (paraphrasing) "Hey, this isn't required, but if it makes you feel better, you can pay for it".
> The core SQLite database software is in the public domain. No license is necessary to use SQLite or to build SQLite into your products. However, licenses are available to satisfy the following needs:
> - You want indemnity against claims of copyright infringement.
> - You are using SQLite in a jurisdiction that does not recognize the public domain.
> - You are using SQLite in a jurisdiction that does not recognize the right of a authors to dedicate their work to the public domain.
> - You want to hold a tangible legal document as evidence that you have the legal right to use and distribute SQLite. Your legal department tells you that you have to purchase a license.
To be more specific. Public domain is intended to mean "after copyrights have expired". It is not a sort of license that can be put on a creation.
With the MIT licence they can distribute proprietary software based on your work and not have the source available, as this is not required with the MIT licence. So you have no way to get the changes or improvements other parties have made if they choose not to give them to you.
Take what I am saying with a pinch of salt, others can give a better explanation. I'd suggest looking it up yourself.
In the end, if they have opposition to the CAA, they don't sign it, and we make sure that we don't merge pull requests whose contributors have not signed the CAA.
You have a moral opposition to the concept of the CAA or a CLA, and that's perfectly fine, it just means you will not be able to contribute to NodeBB. Unfortunate, but our butts are protected and your rights are not potentially infringed upon.
To be clear though, the context was that you found your own work had included the work of others and THEN went out and sought their copyright assignment. This isn’t someone seeking contribution. I fail to see why they would agree to that.
Why wouldn't you rewrite all lines of code instead?
Imagine a person A worked on a project together with persons B, C..., and over time they all have dependence on each other code. If B, C etc. at some moment changed licensing of their code, but person A didn't, 1) A's work will become at least partially meaningless, as it depends on B, C... work 2) B, C... would be in violation of previous agreement with A (as at least some of their code depends on A's code).
Even worse, assume A doesn't want to significantly modify the project structure, and starts talking with B, C... asking them not to change the license. While it's formally possible to find last modifier for each line, it doesn't usually make much sense from programming logic point of view. So, NodeBB seem to get quite lucky getting everybody - at least everybody with complex contribution - simultaneously changing their license terms in accord. I'd assume in general it could be easier to rewrite all code.
Because we value the work our contributors have made to NodeBB. To rewrite to code would be (besides being hard) essentially to replace the attribution of the code from the original owner to a company employee, etc.
When a contributor assigns their contribution to us, we own it in a legal sense but we still very much want to let others know that they did it.
For context, when NodeBB faced this possibility, we simply contacted every single contributor and asked nicely if they'd assign over their ownership of their contribution to us (note the use of the word "assign", not "license", a license is revocable, an assignment is not).
Future contributions by new parties required signing of the same Contributor Assignment Agreement.
Here's the CAA if you're interested in reading legalese: https://cla-assistant.io/NodeBB/NodeBB
All in all it took us under a week to secure the assignments, and any who did not sign we simply rewrote their lines of code, or we would have, but everybody signed.
The bar of effort to clear is so low to avoid this kind of controversy!
Reason we went this route: we wanted the flexibility to deliver a proprietary version of NodeBB for those clients that needed it. We get asked often whether there's a difference between the proprietary version and the open source version, but there isn't, it's just for legal reasons.