Re: [Non-DoD Source] Re: Which is better, assignment of rights, or licensing rights? (Tentacles of Evil Test)
* Cem F. Karan: > When I use the term "assignment", I mean that the original > copyright/IP owner gives the ownership of the IP to some other > entity. The problem is that the new owner can choose new licensing > terms as they fit, as the IP is now their property. Choosing > licensing means that there are many, many different actors working > together; if one arbitrarily changes the license terms for what they > own, it has no effect on the parts that they don't own. For > example, if you and I are working on a project together, I can > choose to change the license on the portions of the code that I > own[1], but this has no effect on your property, which makes it > pointless for me to try to change the license as I can't take over > what you own. However, if you had assigned the IP rights in what > you developed to me, I could choose the license that material is > redistributed under[2], potentially sending you a cease & desist > letter when you try to redistribute material you generated. The flip side is that without effective assignment, the copyright situation becomes so murky that you are seriously limited in what you can do with a work. We have enough experience today that suggests that is generally not the case with free software licensing, despite the highly informal nature of the arrangements. That outcome must not have been obvious 20, 30 years ago, which may have prompted some people to go after assignments historically. > [1] Good OSS licenses ensure that it is impossible to retroactively > revoke any permissions granted, so material that is already out > there should stay out there. OSS licenses cannot circumvent applicable law. The EU is working on giving authors new inalienable rights in this area, allowing them to claim additional compensation. > [2] Unless you were clever, and assigned the rights to using some contract > clauses that stipulated how the material could be distributed, etc. The FSF has such provisions in many of their assignment contracts.
RE: [Non-DoD Source] Re: Which is better, assignment of rights, or licensing rights? (Tentacles of Evil Test)
On Wednesday, October 17, 2018 3:23 PM, Florian Weimer wrote: >* Cem F. Karan: > >> In my personal view, I think that Debian should lean towards licenses, >> and discourage assignments where possible; that ensures that if >> someone is a bad actor, then there will still be a chance to fork the >> code and continue open development as all the good actors will still >> have the necessary ownership over the parts that they contributed. > >I think what you call “assignments” is about contributions to >upstream. This does not directly affect what Debian ships (unless a >software license stipulates that any change is automatically licensed >(assigned?) to the original developer). It is a personal decision of >each Debian/upstream contributor. I assume that this is the reason >why it rarely comes up on debian-legal. > >In practice, I see zero benefit from assignment. One of the largest >holders of assignments uses different licenses for programs and >documentation, so you cannot generate API documentation from doctext >strings, and they do not respond at all to relicensing requests when >there's an obvious mistake and the wrong license is used for a source >file. That's two cases where assignments should greately simplify >matters, but that's not what happens in my experience. When I use the term "assignment", I mean that the original copyright/IP owner gives the ownership of the IP to some other entity. The problem is that the new owner can choose new licensing terms as they fit, as the IP is now their property. Choosing licensing means that there are many, many different actors working together; if one arbitrarily changes the license terms for what they own, it has no effect on the parts that they don't own. For example, if you and I are working on a project together, I can choose to change the license on the portions of the code that I own[1], but this has no effect on your property, which makes it pointless for me to try to change the license as I can't take over what you own. However, if you had assigned the IP rights in what you developed to me, I could choose the license that material is redistributed under[2], potentially sending you a cease & desist letter when you try to redistribute material you generated. The big advantage of licensing is that it requires the collusion of all of the owners to change the license; if there is only one owner (Evil Corp), they can change the license arbitrarily. Thanks, Cem Karan [1] Good OSS licenses ensure that it is impossible to retroactively revoke any permissions granted, so material that is already out there should stay out there. [2] Unless you were clever, and assigned the rights to using some contract clauses that stipulated how the material could be distributed, etc.
Re: Which is better, assignment of rights, or licensing rights? (Tentacles of Evil Test)
* Cem F. Karan: > In my personal view, I think that Debian should lean towards licenses, > and discourage assignments where possible; that ensures that if > someone is a bad actor, then there will still be a chance to fork the > code and continue open development as all the good actors will still > have the necessary ownership over the parts that they contributed. I think what you call “assignments” is about contributions to upstream. This does not directly affect what Debian ships (unless a software license stipulates that any change is automatically licensed (assigned?) to the original developer). It is a personal decision of each Debian/upstream contributor. I assume that this is the reason why it rarely comes up on debian-legal. In practice, I see zero benefit from assignment. One of the largest holders of assignments uses different licenses for programs and documentation, so you cannot generate API documentation from doctext strings, and they do not respond at all to relicensing requests when there's an obvious mistake and the wrong license is used for a source file. That's two cases where assignments should greately simplify matters, but that's not what happens in my experience.
Which is better, assignment of rights, or licensing rights? (Tentacles of Evil Test)
I was reviewing the tests that Paul Tagliamonte pointed me to in the "RE: What are the tests? was: RE: [Non-DoD Source] Re: MongoDB Server Side Public License, Version 1 (SSPL v1)" thread, and it got me to thinking about the IP rights, and the Tentacles of Evil Test. All of the Free licenses I know of are exactly that; licenses of rights. However, I know that some companies really want assignments of rights. I can see arguments going both ways. The upside of assigning rights means that if there are conflicting licenses, then lawyers can normalize the entire package to a single license. It is also possible to change the license if a hole is found in one. The downside is that Evil Corp. can arbitrarily change the terms of the license for the complete package, rather than just the portions that they own, potentially preventing contributors from continuing work on material that they developed and contributed. In my personal view, I think that Debian should lean towards licenses, and discourage assignments where possible; that ensures that if someone is a bad actor, then there will still be a chance to fork the code and continue open development as all the good actors will still have the necessary ownership over the parts that they contributed. Thoughts? Thanks, Cem Karan
Assign or license rights? was: RE: What are the tests? was: RE: [Non-DoD Source] Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
Thank you! I especially like the Tentacles of Evil test. :) Thanks, Cem Karan From: Paul R. Tagliamonte [paul...@gmail.com] Sent: Wednesday, October 17, 2018 8:51 AM To: Karan, Cem F CIV USARMY RDECOM ARL (US) Cc: Xavier; debian-legal Subject: Re: What are the tests? was: RE: [Non-DoD Source] Re: MongoDB Server Side Public License, Version 1 (SSPL v1) All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. Caution-https://people.debian.org/~bap/dfsg-faq.html < Caution-https://people.debian.org/~bap/dfsg-faq.html > Beware these are proxy cases for dfsg criteria and not criteria themselves. Paul On Wed, Oct 17, 2018, 8:48 AM Karan, Cem F CIV USARMY RDECOM ARL (US) mailto:cem.f.karan@mail.mil > > wrote: On Tuesday, October 16, 2018 5:47 PM, Xavier wrote: >Le 16/10/2018 à 22:44, Florian Weimer a écrit : >> * Xavier: >> From: Eliot Horowitz mailto:el...@mongodb.com > > Date: Tue Oct 16 13:03:02 UTC 2018 Subject: [License-review] Approval: Server Side Public License, Version 1 (SSPL v1) ... “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version. >>> >>> I feel this part fails against the dissident test but I could be wrong. >> >> I think you are right, but the test >> https://wiki.debian.org/DissidentTest < >> Caution-https://wiki.debian.org/DissidentTest > > >> is not formally part of the Debian Free Software Guidelines. > >Right but as DFSG is just a guideline, my opinion is that: > - formal success to DFSG is not enough (else we would have to change > them more often, which would create detrimental instability), > - if one of the 3 tests fails, we leave with an unfavorable opinion to > start the discussion here. > >In this case, I feel that upstream team wants to limit freedom of their >software while remaining just at the limit of the rules. > >So for now, my feeling> is that it's not in the spirit of DFSG, while >respecting the words. Forgive me for sidetracking this conversation, but what are the 3 tests? I found the Desert Island Test, but not the third one. Thanks, Cem Karan
Re: What are the tests? was: RE: [Non-DoD Source] Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
https://people.debian.org/~bap/dfsg-faq.html Beware these are proxy cases for dfsg criteria and not criteria themselves. Paul On Wed, Oct 17, 2018, 8:48 AM Karan, Cem F CIV USARMY RDECOM ARL (US) < cem.f.karan@mail.mil> wrote: > On Tuesday, October 16, 2018 5:47 PM, Xavier wrote: > >Le 16/10/2018 à 22:44, Florian Weimer a écrit : > >> * Xavier: > >> > From: Eliot Horowitz > Date: Tue Oct 16 13:03:02 UTC 2018 > Subject: [License-review] Approval: Server Side Public License, > Version 1 (SSPL v1) > ... > “If you make the functionality of the Program or a modified version > available to third parties as a service, you must make the Service > Source Code available via network download to everyone at no charge, > under the terms of this License. Making the functionality of the > Program or modified version available to third parties as a service > includes, without limitation, enabling third parties to interact with > the functionality of the Program or modified version remotely through > a computer network, offering a service the value of which entirely or > primarily derives from the value of the Program or modified version, > or offering a service that accomplishes for users the primary purpose > of the Software or modified version. > >>> > >>> I feel this part fails against the dissident test but I could be wrong. > >> > >> I think you are right, but the test https://wiki.debian.org/DissidentTest> > >> is not formally part of the Debian Free Software Guidelines. > > > >Right but as DFSG is just a guideline, my opinion is that: > > - formal success to DFSG is not enough (else we would have to change > > them more often, which would create detrimental instability), > > - if one of the 3 tests fails, we leave with an unfavorable opinion to > > start the discussion here. > > > >In this case, I feel that upstream team wants to limit freedom of their > >software while remaining just at the limit of the rules. > > > >So for now, my feeling> is that it's not in the spirit of DFSG, while > >respecting the words. > > Forgive me for sidetracking this conversation, but what are the 3 tests? I > found the Desert Island Test, but not the third one. > > Thanks, > Cem Karan > >
What are the tests? was: RE: [Non-DoD Source] Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
On Tuesday, October 16, 2018 5:47 PM, Xavier wrote: >Le 16/10/2018 à 22:44, Florian Weimer a écrit : >> * Xavier: >> From: Eliot Horowitz Date: Tue Oct 16 13:03:02 UTC 2018 Subject: [License-review] Approval: Server Side Public License, Version 1 (SSPL v1) ... “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version. >>> >>> I feel this part fails against the dissident test but I could be wrong. >> >> I think you are right, but the test >> https://wiki.debian.org/DissidentTest> >> is not formally part of the Debian Free Software Guidelines. > >Right but as DFSG is just a guideline, my opinion is that: > - formal success to DFSG is not enough (else we would have to change > them more often, which would create detrimental instability), > - if one of the 3 tests fails, we leave with an unfavorable opinion to > start the discussion here. > >In this case, I feel that upstream team wants to limit freedom of their >software while remaining just at the limit of the rules. > >So for now, my feeling> is that it's not in the spirit of DFSG, while >respecting the words. Forgive me for sidetracking this conversation, but what are the 3 tests? I found the Desert Island Test, but not the third one. Thanks, Cem Karan
