| 1 |
On Thu, Oct 27, 2016 at 8:08 PM, Daniel Campbell <zlg@g.o> wrote: |
| 2 |
> |
| 3 |
> With a DCO, it greatly complicates things. Would my right to keep my |
| 4 |
> contributions in an overlay be infringed upon? What would change if we |
| 5 |
> switch to this? |
| 6 |
> |
| 7 |
|
| 8 |
The DCO doesn't change your rights at all, or change the status of the |
| 9 |
copyright. It is simply a declaration that the code is |
| 10 |
redistributable under the appropriate license. While we don't have a |
| 11 |
DCO in place currently, it is already policy that devs are supposed to |
| 12 |
check the license. |
| 13 |
|
| 14 |
The FLA does change the status of the copyright/licensing situation. |
| 15 |
However, this will be voluntary, so if it concerns anybody they simply |
| 16 |
can choose to sign it. However, under the FLA if you do assign |
| 17 |
copyright to Gentoo then in accordance with the agreement Gentoo will |
| 18 |
give you the right to redistribute your code in perpetuity without |
| 19 |
restriction (if I'm reading it correctly). Essentially you'd be |
| 20 |
giving Gentoo the right to re-license the code under another FOSS |
| 21 |
license or pursue copyright claims, but you still will be able to do |
| 22 |
most of the things you could do if you had retained copyright. |
| 23 |
|
| 24 |
Both practices are actually very standard in the FOSS world. The DCO |
| 25 |
is used by Linux and numerous other projects and is generally |
| 26 |
considered a best practice for any project. The FLA is less commonly |
| 27 |
used, but I know that KDE uses it. It is probably more common in |
| 28 |
community products especially in Europe, since it is designed to |
| 29 |
handle the German case. I'd say that a CLA is a more common practice, |
| 30 |
especially in projects that are dual-licensed with a commercial |
| 31 |
backer. The CLA is a much stronger transfer of the rights of the |
| 32 |
contributor to the project and usually gives the project a blank check |
| 33 |
to do whatever they want with the code, such as making it exclusively |
| 34 |
closed-source in the future. This is obviously desirable to |
| 35 |
corporate-backed projects as it gives them more options to extract |
| 36 |
money from the code. |
| 37 |
|
| 38 |
The DCO basically is an extra assurance that our copyrights are sound. |
| 39 |
The FLA is a way to give Gentoo more options for relicensing code and |
| 40 |
such, but in a way that is more compatible with our social contract |
| 41 |
and which probably also makes us a less attractive hostile takeover |
| 42 |
target (since the FLA would limit the sorts of bad things somebody |
| 43 |
could do with our copyrights if they managed to seize them). |
| 44 |
|
| 45 |
Honestly, I think the policy actually does simplify things for the |
| 46 |
most part by making a lot of things explicit where currently they are |
| 47 |
vague and where a variety of opinions prevail. However, |
| 48 |
simplification was never really the main goal of the policy. It is |
| 49 |
more about not getting sued and being more flexible the next time |
| 50 |
somebody decides to fork something like udev without starting a |
| 51 |
fiasco. |
| 52 |
|
| 53 |
Since she hasn't promoted it herself, I'll point out that alicef has |
| 54 |
wikified the policy here: |
| 55 |
https://wiki.gentoo.org/wiki/User:Aliceinwire/CopyrightPolicy |
| 56 |
|
| 57 |
I'll go ahead and make some of the tweaks mentioned in the thread, and |
| 58 |
maybe try to improve the attribution overhead which I think is the |
| 59 |
only real downside. I think if it were implemented the contents of |
| 60 |
that page would probably be split up a bit as it combines very static |
| 61 |
information (the policy) with things like the table of licenses which |
| 62 |
obviously will be updated frequently. |
| 63 |
|
| 64 |
-- |
| 65 |
Rich |
Archives