Open Source Monday - is the license important?

[former_member188959]

I'm not a lawyer, but I play one on TV...

Is the License important?

Oh, yes, I'm definitely trying to put you to sleep.  License?  Really?  Just how boring would that be?

Well, I want to start talking about another of our great projects, called cla-assistant.  It's part of an entire suite of software I deal with pretty frequently, that helps maintain our Open Source repository.  Before I do that, however, I think I need to give a little bit of an overview of the problems that cla-assistant solves, and why some of those tools are required.

For good, not evil

Take the time to talk to a commercial developer, and the light bulb can come on pretty quickly.  After all, the license is the one thing between the work that they do (and getting paid!) and just giving away the code.  Which means it's pretty important in commercial software.

And, as many Open Source developers have discovered, it's pretty important in the FOSS community as well.  The license is the one thing that allows them to decide just how that code they wrote can be used, who can use it, and why.  For some people, there is pride in knowing that code they produced isn't used for evil...

But, if you are a commercial company - with deep pockets - like SAP, there is much more to it.  After all, now that there is someone who could "pay" for a problem, if our name appears on it somewhere it leaves open the question "what if they cause harm"?  Consider, for example, the breach by the US credit reporting agency Equifax.  That breach was blamed (in part) on the Struts package, which may have had a bug that allowed access....  In that case, and knowing that Equifax has a major Public Relations problem, could they go after Apache?

This is one of the many challenges we face when publishing Open Source here at SAP.

Oh, and the great part?  Well, I can't discuss our internal details, but I can outline the general problems.  And I'm not a lawyer, which means this is all based on my understanding from the real experts.  Which means I'm just giving background, and can discuss it knowing I'm not an expert - legally that is.  (See what kind of legal issues I have to worry about?  Crazy...)

The things you can't live without

Let's take a quick dive in to the details.  First, there are two major things that every project needs to have:  a copyright, and then a license.

(Are the two the same?  No...)

Copyright

A copyright safeguards the ownership of intellectual property.  In other words, if you wrote something, the copyright gives you several regarding that property (in this case, code).  It also the allows you to assign those rights to others.

So, the copyright is the first line of defense.  By claiming the copyright on your code, you are saying "this is mine".  Only then can you give others the permissions to use it, in the license file.

What if you don't claim copyright?  Don't worry, you have it anyway.  Or that's the theory.  International law states that copyright automatically exists on a work, even if you don't say so.  But, then, it can get a little murky.  Every time I ask this question the response is "you don't need it, but it's better to have it".  Stating that you do have copyright is clear and unambiguous.

License

So, now that you have these rights, now what?  That's where the license kicks in.  A license grants the users of your code permission to use that code because you are waiving part (or all) of your copyright privileges to do so.

In return, the license may also make specific demands of any derivative work.  For example, you might say that anything that uses your code can't be sold for profit.  Or, a usual provision is that anyone using your code must acknowledge your work.

So, with me so far?  Copyright is the ownership, license is how you give it away.   Now, it gets interesting...

The many kinds of licenses

And then, if you look around, you will find there are lots of licenses available.  And I mean, LOTS.

Parsing through the licenses is a difficult task.  The best way to start that process is to understand what you are willing to accept, and what is out of bounds.  Once you have a general idea, you can use tools to help you decide.  For example, the TL;DR Legal website is great at explaining (in plain English) what a license allows and doesn't allow.

There are several interesting things about licenses that have caught people in the past.  For example, the GPL license (which was very popular for a while) isn't used as much anymore.  That's because it requires that all derivative work (anything that uses your code) be published as open-source.  That's a real problem for the commercial software vendors (like SAP).  But, if that's important to you, then head that direction.

(Oh, it also says you can't change licenses, so once you start, you are stuck with it for your own code as well.  Just FYI.)

This is where I get involved with licenses a lot.  When we are using software, I often get asked "but can I use this?"  The first thing I have to look at is the license for the FOSS in question.  If I haven't seen it before, I then have to send it to my friends in legal, who take a closer look.  So, yes, we look at all of that very carefully.

That's not everything

Once you start to think about the ability to use software, you start to think about two other problems.  First, what if someone else contributes to your existing Open Source?  And second, how do we track all of this stuff?

The first opens up a new set of problems.  If the contributor is inside SAP, the problem is "easy" (I say that, because nothing legal is ever easy.)  SAP owns all the code produced by it's employees, and so the primary problem is getting permission, internally, to use the new contribution.

But, if the contributor is an external person, what then?  Well, obviously, we want that person to agree to use our license.  And, we also want to make sure that the contributor is allowed to give us the contribution (remember, SAP owns our code, so maybe their employer owns thier code as well?)  And then we have to worry about potential malicious contributions, and code which maybe shouldn't be published in the first place.

This is where cla-assistant comes in.  We have created a whole FOSS package to handle this (and I'll talk more about it next week).

How about the tracking?  This is getting increasingly more complex.  We have a bunch of systems we created internally, and those aren't of much interest to you (ouside of SAP).  But we have recently been asked to participate in a new OSF project called ClearlyDefined, and I am hoping this project makes our job easier.  It's certainly about time for some standards on licenses, where they live in a project, and how to catalog them effectively.

There is even more.  I haven't touched on CopyLeft, or the difference between active license agreement and passive (often called Browse-over licenses).  Those deserve their own posts, so I'll get back to those soon.

 

That's enough to get started towards cla-assistant.  Look for that next week!