Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Generally you license the code so competitors have a disadvantage e.g. with GNU licenses, they may have to open source any changes they make. As the copyright holder, you can do things with the code that they cannot (since you don't have to follow license restrictions), i.e. create premium features.


Thats a common situation, but we explicitly refuse to do that. I have a strong opinion that it doesn't represent what open source should be, and thats absolutely free software. I do understand that some things are considered necessary, but we're trying to prove thats not the case.

It's also something that can limit the adoption of your product. I've worked with companies in the past have either refused to use allow GPL software, or would have a significant audit process you'd have to go through to be able to use it.


What do you think about using a license that forces freeing any changes to what you shared but doesn't affect anything linking to it dynamically or statically? As in:

http://zeromq.org/area:licensing

Additionally, patent license provisions for using the shared code seem almost mandatory given the patent trolling we're seeing of both suppliers and users of whatever they manage to get through a patent clerk. All the FOSS licenses should try to include some protection there against beneficiaries suing derivatives.


Definitely not a license expert here. Lots of legal folk I trust would stand by "Apache and only Apache" for releasing FOSS, and I think one of the core reasons is patent protection. We may re-license Sentry at some point to Apache just because its a more understood model and as a growing business that may one day be important. It's also nice that it provides good out of the box tools that are widely supported (e.g. the CLA).


You should definitely check out MPL too. I was told it's like LGPL for static linking. As in, commercial integrators can use it without releasing their source. Only have to release improvements to sentry itself in that model.


> with GNU licenses, [competitors] may have to open source any changes they make.

Only with AGPL, and only if the competitors expose APGL-licensed software for interaction directly.


How can you possibly know they've made changes to the software?

Suppose they've started offering Sentry-with-a-twist, how can you know they modified Sentry code? They may as well have written a separate software running in a different stack, but interfacing with Sentry and with the users and providing the twist.


How can I know? The same way as I know the vendor based their firmware on Linux, so I am entitled to receive a copy of source code. Meaning, I can't, technically.


That's one way to do it but we (Sentry) don't do that. Our server software is BSD licensed.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: