[beyond-licensing] Legal topics that FOSS projects could use more information on

[Deb Nicholson]

I think we may be avoiding an elephant here which is that a lot of the
opposition to CLA's comes from the fear that a codebase that was once free
or open source software will be re-licensed by a corporate entity to
something proprietary. There is concern that without a "free software/open
source always clause" that a situation will arise where a corporate entity
that has hired many of the key developers, is the owner of the trademark or
has otherwise become the most important distributor of the code will then
thwart the intention of the original developers.

Perhaps, we could disentangle the two potential upsides of copyright
assignment; 1) avoiding a bureaucratic nightmare later on and 2) making
sure a FOSS codebase stays FOSS, and make recommendations for projects with
one or both of those goals?


On a separate note, I think we might also want to discuss how we suggest
projects address the current patent landscape. If they don't get advice
from us, they're likely to get it from VC's and lawyers that aren't
familiar with FOSS.

Deb

On Wed, Jun 15, 2016 at 2:19 PM, Mike Dolan <email at michaeldolan.com> wrote:

> Copyright aggregation without limiting the community's ability to fork
> under the existing license is innocuous to me and in certain cases could
> solve long term problems I don't believe many pay attention to. E.g. look
> at any core project that is decades old that has some crufty underpinning
> with odd licenses they can't get away from (e.g. scan OpenSSL).
> Particularly on the death of key copyright owners, the aggregation of
> copyright is an interesting path forward for the community to be able to
> continue evolving its own future. I get that it can be abused by some bad
> actors and I have a list of projects/companies I could cite but won't.
> However, it could also be a helpful tool in certain circumstances. In
> conjunction with Richard's point that most relicensing happens by agreement
> of the past authors/copyright owners anyway, the ability to secure
> agreement from the copyright owners/authors that the future community will
> make the right choice after they've passed away would remove a key issue
> that comes up in most relicensing discussions. Try tracking down the will
> of a dead author to a project to see who inherited their copyrights in an
> open source project...
>
> I'm not sure how this relates to what this group is working on though.
> IMO, licensing is a decision owned by the copyright owners involved now and
> in the future. I'm certain that not every developer agrees with the FSF's
> CLA requirements, but does that mean anyone would say a particular FSF
> project is not "open source" in addition to being "free software"? The FSF
> has a reason for requiring copyright assignment (
> https://www.gnu.org/licenses/why-assign.en.html) and given their purpose,
> I can't see how anyone could call their aggregation a "con" or "not open
> source". Back to my first point, so long as the community can fork under
> the current license, should anyone care?
>
>
> On Wed, Jun 15, 2016 at 11:29 AM, Richard Fontana <fontana at opensource.org>
> wrote:
>
>> On 06/15/2016 11:20 AM, Danese Cooper wrote:
>>
>> > Surely there is no upside in initiating copyright aggregation for
>> contributions submitted after the majority of the code has been written?
>>
>> I think there is an upside, since until that happens you don't know if
>> it ever will happen - I would assert that the vast majority of open
>> source projects do not relicense during their active lifetime. So until
>> that possibly-nonexistent future event the project arguably benefits
>> from the absence of copyright aggregation.
>>
>> There may be less of an upside if you think there is a high likelihood
>> that some project will experience such a future copyright
>> aggregation-requiring event.
>>
>> ("Initiating copyright aggregation" may be the wrong concept here -- I
>> believe what would be more typical, not that these things happen very
>> often, is that a relicensing effort would involve getting past
>> contributors to agree to the new license, rather than granting a broad
>> license or assigning copyright to whatever entity was managing legal
>> matters for the project.)
>>
>> _______________________________________________
>> beyond-licensing mailing list
>> beyond-licensing at opensource.org
>> https://lists.opensource.org/cgi-bin/mailman/listinfo/beyond-licensing
>>
>
>
> _______________________________________________
> beyond-licensing mailing list
> beyond-licensing at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/beyond-licensing
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/beyond-licensing_lists.opensource.org/attachments/20160712/bb4c7296/attachment.html>