Apache 2.0 License + Runtime Library Exception + copyright owned by the contributor (i.e. no assignment or CLA) + good community structure and documentation + code of conduct... well done, Apple!
Anybody knows what effects of the "copyright owned by the contributor" are in the context of Swift's Apache license?
I guess the "good side" is that the lawyers of other companies probably like when the code made by their programmers keeps being copyrighted by the company. But it is still an Apache license, so they can't demand too much from the users of the code.
Still, are there any negative aspects? Any imaginable danger?
Can the standard library have problems with (once in the future) having different copyright holders for its different parts?
What it means from a legal standpoint is that Apple is bound by the same terms as everybody else.
The way it works is this: Apple is making Swift available to you (and others) under Apache 2.0. You send in some changes, which you make available to Apple (and others) under Apache 2.0. Everyone is on equal footing, and Apple can't relicense it to someone else on terms of their choosing that involve, for example, neutering the patent grant's self-destruct clause.
This was the default way that open source worked for years, before people started cargo-culting the (totally unnecessary) CLA process into their projects.
What it means from a practical standpoint, though, is that the project is easier to contribute to, what with the impedance imposed by a CLA process being, you know, non-existent.
That ridiculous: "started cargo-culting the(totally unnecessary) CLA process"
It's so they can re-license in the future. There are some projects with so many authors that it is impossible to re-license because you need sign-off by every single person, even if it makes sense to re-license.
From a contributer's point of view, the inability to re-license practically is often a feature, not a bug. CLAs make the worst case scenario touted by GPL advocates about non-GPL licenses practical: They can profit directly and exclusively from your work without your direct consent.
Also the ability to relicense an Apache License 2.0 work is relatively unimportant (compared to, say, the ability to relicense something under a more restrictive license like the GPL).
"copyright owned by the contributor" means that as the project matures there will be way too many contributors. To change the license for the project to something that is not Apache-compatible Apple would have to ask every contributor to re-license their code, and if the code author disagrees re-implement corresponding parts. In practice that's a signal to every one that the licensing terms are very unlikely to ever change.
Aside from the hilarious description of Oracle [t=2107], it's worth watching "The Rise and Development of illumos" [1] as it discusses some consequences of signing away copyright on your contributions to an open source project.
Sun Microsystems released the Solaris operating system source code, but required all contributors to handle the copyright ownership on their code to Sun.
Then, shortly after Sun acquisition, Oracle closed the Solaris code and got away with all contributors' copyrights.
I find his speaking style extremely irritating. I can't take more than a few minutes of this. I'm sure it's full of substance, though. Perhaps there's a transcript somewhere?
I hope Bryan once publishes the annotated presentation? I'm also one of those who have problems following the narration in the video. Until then, I've posted a link to the slides here (see my other post).
Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.
One important question they'll ask is: "Who can enforce the copyright and licence?" (Which is when the subtle difference between joint and collective copyright matters.)
Non-trivial contributions are made under the terms of the Apache 2.0 Licence, so regardless of who owns the copyright, everyone operates under those same terms.
One common rationalisation for copyright assignment is ease of relicensing, should it be necessary. That's much less important when operating under the terms of a permissive license.
The answer is only the owner of an exclusive right of copyright has standing to sue. So any of these open source projects that have no copyright assignments would have trouble suing. But in practice, who cares. Unless you want to sue people, it literally doesn't matter.
The only folks who often care about suing are those who are trying to enforce certain types of share-alike licenses (GPL, etc) because they are ideological.
If you are using Apache or BSD, you probably aren't suing folks because you are fine with them commercializing it or doing whatever with it (and if you are using these liceneses and aren't okay with that, you may want to reevaluate your life choices)
Joint holders can also enforce copyright, though open source codebases work more like collective copyright. That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)...
"Joint holders can also enforce copyright, though open source codebases work more like collective copyright."
Joint copyright is basically non-existent in the US. For example, you must intend to create a joint work at the time of creation. You can't make it joint later on by signing a document saying it's joint with someone. There are other issues too.
This is deliberate, as joint owners each own a 100% enforceable set of rights, and the law doesn't really want tons of people running around claiming to own the same work.
"That said, non-exclusive Linux kernel copyright holders have performed enforcement activities (quietly or noisily)..."
Not in the US. It's not possible in the US. It'll get dismissed immediately.
> Your typical corporate IP lawyer might feel queasy about the collective copyright aspect, but so much of the open source world works this way now... they can suffer in their jocks.
This is a bad attitude if you want buy-in from large organizations. If you're not worried about that, no problem, but if buy-in is your goal (and I'm sure it's Apple's goal here) you can't just tell potential contributors to "suffer in their jocks."
Sure, it's flippant, but do recall that the entire concept of open source absolutely terrified IP lawyers not that long ago (and in some cases, still does).
Lawyers who are too conservative to allow their company's developers to contribute to open source projects (that they don't own) have a problem. Open source is way beyond pussy-footing around just to make corporate lawyers feel comfortable.
And seriously, if Apple can do it, why can't they?
This comment doesn't make a lot of sense. The "corporate IP lawyers" being referred to would be Apple's own counsel, not those of "potential contributors".
