opinionated inputbuilders licensing

0 views
Skip to first unread message

chrismcv

unread,
Dec 21, 2009, 4:40:49 AM12/21/09
to mvccontrib-discuss
Hi,
I've recently been working on a prototype using Input Builders in a
commercial project. We've made a few changes to the core engine, to
support a few more attributes and started using the spark view
engine. Overall I don't think our efforts are of use or benefit to
the project itself, so I don't want to submit a patch. However, I'm
worried that this is violating the Apache license it is released
under. I have a couple of questions that I'd like to ask about
licensing - specifically for this project.

1. Does the project fall under the standard Apache model of the rest
of the project?
2. Is changing one of the ascx files considered a change of the core,
and therefore should users "re-apply" the license?
3. The original c# files for the InputBuilders didn't include an
apache copyright notice. Should we add one to our modified ones so
that it's clear where our source code came from?

I also have one general question about general open source licensing:

4. How do we "give appropriate credit" to open source projects? As
our project is commercial, source code will not be released, however,
I do feel that it is essential to do something? What are others in
this situation doing?

Thanks,
Chris

Jeremy Skinner

unread,
Dec 21, 2009, 5:12:02 AM12/21/09
to mvccontri...@googlegroups.com
Hi Chris,


> However, I'm  worried that this is violating the Apache license it is released
> under.

This shouldn't be an issue - the Apache 2 license does not require you to re-release any derived works as open source or submit them back to the original project.


> Does the project fall under the standard Apache model of the rest
> of the project?

All of the code in MvcContrib is Apache 2 licensed. With the exception of the NVelocity and Brail view engines (which belong to the Castle Project) I believe it is the case that everything else is (c) MvcContrib & Contributors.

> Is changing one of the ascx files considered a change of the core,
> and therefore should users "re-apply" the license?

I believe this would be considered a derived work. Not quite sure what you mean about "re-applying" the license?

> The original c# files for the InputBuilders didn't include an
> apache copyright notice.  Should we add one to our modified ones so
> that it's clear where our source code came from?

That's probably a good idea. I think it would be a good idea if the MvcContrib source code included the relevant copyright notices anyway....I'll go through it and add one at some point this week.

> How do we "give appropriate credit" to open source projects?

So long as you're abiding by the license there's no real requirement to do this. Personally, I tend to add some sort of Acknowledgements.txt to the application but for a closed-source project I'm not sure that brings much benefit.

Hope this helps,

Jeremy

2009/12/21 chrismcv <bik...@gmail.com>

--
Contact Jeffrey Palermo or Eric Hexter with specific questions about the MvcContrib project.  Or go to http://mvccontrib.org

To unsubscribe from this group, send email to mvccontrib-disc...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mvccontrib-discuss?hl=en

Eric Hexter

unread,
Dec 21, 2009, 9:30:54 AM12/21/09
to mvccontri...@googlegroups.com
I agree with what Jeremy said.  This license is pretty liberal.
 
 
I do have a question about your comment the original source code.   Are you talking about the input builders from my blog?  The license was not declared for that source code so it does not necessarily fall under the Apache licences.  Once I committed the source to the contrib project, that changed.  The input builders that are part of the MvcContrib project are part of mvccontrib and its default licence.
 
If all of our changed are to the .aspx files than you do not need to fork the code.  You can include the .aspx files in your views/shared folder and they will override the views that are embedded in mvccontrib, that is the recommended way to extend the input builders. 
 
I have added a number of extensibility points to the input builders that are part of the current Trunk/Master, this includes the conventions for extending and modifying which builders are selected, the AdditionalData dictionary so that your conventions can store data that can be passed to the views, as well as the ability to override any of the default partial views or their master pages.  I would be shocked if you really needed a fork of the contrib project to do what you need. I am supporting a number of projects right now and we are not running custom builds of mvccontrib, for any of them. They all define their own conventions and partial views using the existing convention interfaces as a way to extend what is in mvccontrib.  I would be more than willing to spend an hour with you over live meeting if you would like me to help guide you to use a non forked version of mvccontrib. 
 
If you are constrained on time, I totally understand, but I would encourage you to use the extensibility points so that you can continue to easily upgrade mvccontrib as we add more features. I see a number of interesting things coming in on top of MVC2.
 
Thanks,
Eric

Reply all
Reply to author
Forward
0 new messages